Initialisation collision occuring when using IFrame in dev mode

We've encountered an issue where we have multiple IFrames issuing
ColdBox requests that in development mode appear to collide with each
other. Each IFrame is supposed to execute the same event handler but
with different params. Sometimes no errors will result, other times
one or more of the IFrames will return a ColdBox error. These errors
tend to be:

key [ROOT] doesn't exist in struct (keys:) which refers to the
"<cfreturn instance.loggerRegistry["ROOT"]>" line in
coldbox.system.logging.LogBox.cfc getRootLoggermethod,

another

The setting RegisteredHandlers does not exist. FWSetting flag is false
which is from
getUtil().throwit(message="The setting #arguments.name# does not
exist.",detail="FWSetting flag is #arguments.FWSetting#",
type="Controller.SettingNotFoundException"); from
coldbox.system.web.Controller.cfc getSetting method,

and others. Putting the app into production mode appears to eliminate
the problem, and returning to development mode does not cause the
problem to manifest again until a fwreinit=1 is performed.

The logger error is a known error, I am not sure Luis has fixed that as yet.
This also occurs from time to time outside of an IFrame on a single page/hit
request as well.

Also I still can't get my head around why people are still using iframes
these days.

Regards,
Andrew Scott
http://www.andyscott.id.au/

From: coldbox@googlegroups.com [mailto:coldbox@googlegroups.com] On
Behalf Of mgara
Sent: Tuesday, 14 December 2010 3:00 PM
To: ColdBox Platform
Cc: mgara@fi.net.au; ccarey@fi.net.au
Subject: [coldbox:7197] Initialisation collision occuring when using

IFrame in

dev mode

We've encountered an issue where we have multiple IFrames issuing
ColdBox requests that in development mode appear to collide with each
other. Each IFrame is supposed to execute the same event handler but with
different params. Sometimes no errors will result, other times one or

more

of the IFrames will return a ColdBox error. These errors tend to be:

key [ROOT] doesn't exist in struct (keys:) which refers to the "<cfreturn
instance.loggerRegistry["ROOT"]>" line in

coldbox.system.logging.LogBox.cfc

getRootLoggermethod,

another

The setting RegisteredHandlers does not exist. FWSetting flag is false

which is

Perhaps the reinit is not threadsafe?

@andrew: Plenty of good reasons to use iframes -- richtext editors are
the most obvious, but any time you need to display externally sourced
content inside your layout (for example a CMS preview function) and
don't want your styles and scripts to clash, then frames are the
easiest way through.

I have oft-ran into the "The setting RegisteredHandlers does not exist" on dev when multiple requests hit while reinitting. I would say it is a concurrency issue. I've always just worked around it by not reinitting on pages with iframes or ajax calls. I don't remember if I've gotten the error since upgrading to 3 or not.

~Brad

This is because config auto reload is not meant to be a development mode flag. It is designed to test 1st request scenarios in your applications. If not, you are reiniting everything and I mean everything on each request. Some weird issues can happen with this flag on.

Luis F. Majano
President
Ortus Solutions, Corp

ColdBox Platform: http://www.coldbox.org
Linked In: http://www.linkedin.com/pub/3/731/483
Blog: http://www.luismajano.com
IECFUG Manager: http://www.iecfug.com

@Luis: we have found that we have to use config auto reload when
making a lot of model changes, as setting "model caching" to false
results in a stack overflow when using autowiring (at least in our
app)

I reported this here with a stack trace/debug log:
http://groups.google.com/group/coldbox/msg/15c43da10fd22e8e

Something similar was noted here (but no resolution one way or the
other yet)
http://groups.google.com/group/coldbox/browse_thread/thread/13777bc0f236db/ed821456010dd6e8?lnk=gst&q=stack+overflow#ed821456010dd6e8

I couldn't identify anything that looked like a circular dependency.
It'd be really great to get to the bottom of it!

One setting I have noticed, but not used is something like "stop
recursion" which is applied to a specific class -- is that something
that *must* be used in order for Wirebox to function correctly or is
it supposed to work this out itself?

Kevin Smith shared a solution to single thread the fwreinit process a while back. You can learn about it in this thread: https://groups.google.com/forum/#searchin/coldbox/maintenanceflag/coldbox/FLAW6BW-AHo/esvCr_mXPKwJ

I have since introduced this into my applications and find it works very well under heavy load.

Thanks,

Aaron Greenlee

if you use model caching false and you get stacktrace issues, we need to solve those. It might be something of how you are wiring your models, I 100% of the time have model caching off on development with no issues. So we need to clarify this use case.

Luis F. Majano
President
Ortus Solutions, Corp

ColdBox Platform: http://www.coldbox.org
Linked In: http://www.linkedin.com/pub/3/731/483
Blog: http://www.luismajano.com
IECFUG Manager: http://www.iecfug.com

My class structure looks like this:

inheritance tree:

grr - ok having now looked at it again there is a circular reference

AbstractGateway injects the SecurityService (which in turn injects
another Gateway which extends AbstractGateway)

If I remove the service injection from the AbstractGateway the thing
works (or at least doesn't stack overflow). Now my question becomes --
is there a mechanism or a technique to resolve this sort of circular
reference? I'm using the SecurityService to retrieve details about the
current user (which is used in a lot of places for updating a 'who
modified me' field in various tables).

The services/gateways are all singletons which is why everything works
fine if modelcaching is set to true

Yes, of course. Circular dependencies will happen if you are using them in the constructor, are you using them in the constructor or passing them via constructor arguments?

If so, I recommend NOT doing constructor arguments but the annotation approach via cfproperty or if you like writting setters, then setter injection. This way, the injection is done after the objects are created so no recursive endless loops occurr.

Luis F. Majano
President
Ortus Solutions, Corp

ColdBox Platform: http://www.coldbox.org
Linked In: http://www.linkedin.com/pub/3/731/483
Blog: http://www.luismajano.com
IECFUG Manager: http://www.iecfug.com

nope - it's *all* <cfproperty> injection. Nothing is used in the
constructor/constructor args. I don't make use of anything that's
being injected until onDIComplete()

Can you help me out here please, can you send me a sample of the models with the injection as you have it that makes errors so I can try it out. I don’t need the full code of the CFCs just enough to wire them and test it out.

Luis F. Majano
President
Ortus Solutions, Corp

ColdBox Platform: http://www.coldbox.org
Linked In: http://www.linkedin.com/pub/3/731/483
Blog: http://www.luismajano.com
IECFUG Manager: http://www.iecfug.com

no probs -- I used the "SuperSimple" template and chucked in just
enough model to make it fail in the manner described above
http://www.filedump.net/dumped/supersimple1292453037.zip

I experimented a little with it and it turns out that the
AbstractGateway is an unnecessary step to make it overflow:

this is enough (using cfproperty injection):
Gateway injects Service
Service injects Gateway

What I'm not 100% clear on is whether Coldbox/Wirebox is capable of
(or even intended to be capable of) resolving this sort of circular
definition or whether I need to find another way of expressing it?

It should allow circular dependencies via cfproperty and setter injection, not constructor arguments. I will check this.
Luis F. Majano
President
Ortus Solutions, Corp

ColdBox Platform: http://www.coldbox.org
Linked In: http://www.linkedin.com/pub/3/731/483
Blog: http://www.luismajano.com
IECFUG Manager: http://www.iecfug.com

Hi - any update on this? Did the problem present itself for you in that sample I sent through?

Ok, I see the issue. The issue is that the recursive circular dependency does work but it needs persistence. Since models object caching is off, then no persistence can ever be maintained and thus the system will always ask for a new service no matter what since persistence is mute.

Therefore, I can say that when you use circular dependencies you cannot use model object caching = false, because you need persistence in order to do this.

I have a ticket for wirebox, where object caching is no longer available, but a reload mode, where it reloads, in order to avoid this.

Luis F. Majano
President
Ortus Solutions, Corp

ColdBox Platform: http://www.coldbox.org
Linked In: http://www.linkedin.com/pub/3/731/483
Blog: http://www.luismajano.com
IECFUG Manager: http://www.iecfug.com

Yes, it would be moot :slight_smile:

This is just a suggestion, (and it may not be easy to implement) but what if when model caching was off, models were still cached somehow, but only for the duration of the request? Each new request would still be reloading from scratch, so from a development standpoint, you just have to make a change to your model and hit refresh to see that change. But keeping the models for that request would allow things like circular dependencies to work as expected.

Thanks!

~Brad

Well, the issue with that, is what about transient objects that you request more than once? Well, I guess you can just cache in request scope the ones that need persistence. Anyways, not sure if this is worth tackling since wirebox is different and you will reload the injector itself.

So I think I might just skip this and rely on the new approach.

Luis F. Majano
President
Ortus Solutions, Corp

ColdBox Platform: http://www.coldbox.org
Linked In: http://www.linkedin.com/pub/3/731/483
Blog: http://www.luismajano.com
IECFUG Manager: http://www.iecfug.com