I’m still getting the same thing unde3r 3.5 – but it’s less common. 3.5 seemed to fix the viewpath is not defined in viewlocations, but the undefined variables issue is still there for me.
Brad has the most likely diagnosis:
“I think there might be some timing problems where a thread is being allowed to use a handler, while another thread is still initializing it (and thus all of its dependencies have not been injected yet)” (from [coldbox:13626] Re: Issue with Dependency injection in my handlers).
I haven’t seen a repost from Jeff or brad, so I’m not sure if he’s resolved it – but I get exactly the same issues as you (variables undefined when they are definitely not, etc. etc.).
I’m still getting the same thing unde3r 3.5 – but it’s less common. 3.5 seemed to fix the viewpath is not defined in viewlocations, but the undefined variables issue is still there for me.
Brad has the most likely diagnosis:
“I think there might be some timing problems where a thread is being allowed to use a handler, while another thread is still initializing it (and thus all of its dependencies have not been injected yet)” (from [coldbox:13626] Re: Issue with Dependency injection in my handlers).
I haven’t seen a repost from Jeff or brad, so I’m not sure if he’s resolved it – but I get exactly the same issues as you (variables undefined when they are definitely not, etc. etc.).
I am having the same issues and the explanation on the last post from Tom Miller here makes a lot of sense to me. After the handlers are cached everything works smooth. Does anyone have an idea how to avoid this?
Take a look at this post by my friend Ken Smith. It is how to reinit a production app and avoid some of these issues that come from people hitting your partially reinited application.
thanks for your answer, but at least for me that is not the problem. I face these problems even if i am the only user and after reinitting is done. It occurs when first hitting an event handler. It gets constructed and alle dependencies will be injected, but if i hit this handler with 2 or more parallel requests from the same browser the error occurs randomly that some dependencies are undefined and it doesn’t matter what is injected, even injection of settings that are strings fails.
And another problem i noticed, if handler caching is enabled and the injection went wrong in of the parallel requests, the broken instance is cached and it will fail always until i reinitted the framework.
here again the quote from Tom Miller in his last post with a possible explanation:
Brad has the most likely diagnosis:
“I think there might be some timing problems where a thread is being allowed to use a handler, while another thread is still initializing it (and thus all of its dependencies have not been injected yet)” (from [coldbox:13626] Re: Issue with Dependency injection in my handlers).
Phal: “It occurs when first hitting an event handler”.
You’re exactly right; it doesn’t really have anything to do with the reinit, only for the fact that the event handlers are cleared from the cache when a reinit occurs. Once a request comes to an un-cached handler, if you get two simultaneous requests, it’s highly likely one will bork – and, as you say, it gets cached in its borked state.
I was tempted to write an interceptor along the lines of the one alluded to in Curts link – but add in cfhttp requests for every single handler I have, and then “unlock” the application again once they were complete.
That, however, is a bodge of the highest order in my opinion!
Furthermore, my issue is compounded by the fact my app runs on 4 load balanced servers, so I never really know which server is going to receive the request (i’m currently using the deploy interceptor to “sync” my reinits). So that bodge wouldn’t even work for me unless I created dns entries for each individual server and hit all four of them (server1.myapp, server2.myapp etc. etc.)
Also, my app runs 5 modules, so in total (including the modules) there are probably about 90 handlers, so that would be 360 cfhttp calls before my app was “ready”. In addition, I have 5 sites using the same app, so in theory all 5 sites would need to get cfhttp’d, making 1800 cfhttp requests.
All in all, it’s pretty stinky situation that I’d be very happy to get a solution to.
but i want to make it a little bit clearer. The problem is the dependency injection when first constructing an event handler and having simultaneously requests on that handler. It’s not about heavy load, because for me that problem occurs even when i am the only one talking to the server. These errors are quite randomly and can appear on everything i inject… model instances, plugins or settings
like tom said if there is once a problem with DI, it can only be fixed by reconstructing the handler (fwreinit)
i tried to block the execution of the other threads with a flag that is set to true in the onDIComplete function and setting the thread to sleep in the preHandler method until that flag is true, but it didn’t work out for me.
public any function validateUser(string userID, string password) output=false{
var user = dsUser.getUser(arguments.userid);
So dsUser is an injected reference to an existing model component.
Occasionally, the last line above with throw:
coldfusion.runtime.UndefinedVariableException: Variable DSUSER is undefined.
It works 99.99% of the time. I'll try to track down more details but
I'm chasing other demons at the moment.
Luis, if I could replicated it, I could probably fix it myself.
Sorry, I do understand the frustration of getting problem reports that
begin with "I have this problem that I can't reproduce on demand".
If I could replicate it, I'd probably be closer to fixing it. Like Bob,
99.9% of the time it's fine!
I'm not sure on the situation with Bob and Phal, but I'm pretty sure it has
something to do with the size of my application - it has a lot of DI
(models, settings, plugins) all injecting each other (and 5 modules too).
I re-wrote part of my application to use cacheTimeout=0 (instead of 30
mins), and that reduced the amount of errors considerably....
hm my App is much smaller… no modules and only about 6 handlers and models… so from my point of view the size of the app should not be the problem.
one way for me to produce the error with propability about 50% is to reinit the framework and send 10 simultaneously request to the same handler… in my case these are 10 associated models from an extJS 4.1 store
like bob and tom said, it is really hard to give you more clues, because the error message is variable foo or bar undefined and it happens randomly. if it may help you, i can post the stacktrace of the error tomorrow (ok, already today ^^)