[coldbox:17410] [wirebox-1.5+] Error related to system/aop/tmp files

Is this part if a ColdBox app, or WireBox standalone?
What if you run a shutdown() on WireBox when reinitting?
Also is there a chance of scope-widening injection of the injector? For instance, placing a reference to WireBox inside an application, server, or session-scoped object that might be holding a reference to an old injector after you’ve reinitted and created a new one.

Thanks!

Brad

Bras is right as wirebox needs to issue a shutdown command just in case

Luis Majano
CEO
Ortus Solutions, Corp
Toll Free/Fax: 1-888-557-8057
Direct: 909-248-3408
www.ortussolutions.com
Twitter: @lmajano, @ortussolutions

  • I am using WireBox standalone.

  • I searched the code and couldn’t find anywhere that application.wirebox was assigned to another variable.

  • I’ve added the shutdown to my reinit process. It now looks like this:

SystemCacheClear(“all”);
lock scope=“application” type=“exclusive” timeout=“20”
{
application.wirebox.shutdown();
application.wirebox = createObject(“component”,“wirebox.system.ioc.Injector”).init(“WireBox”);
}

I was getting an error with the shutdown method related to trying to shutdown cacheBox. I’m not currently using cacheBox so the instance.cacheBox variable wasn’t set in the injector which caused the instance.cacheBox.shutdown() command to fail (line 190 in wirebox-1.5). I made a small change to the shutdown method in “wirebox.system.ioc.Injector” to get it to work.

The original code was:

// standalone cachebox? Yes, then shut it down baby!
if( NOT isColdBoxLinked() ){
instance.cacheBox.shutdown();
}

I changed it to:

// standalone cachebox? Yes, then shut it down baby!
if( isCacheBoxLinked() ){
instance.cacheBox.shutdown();
}

With the change, the shutdown completes without errors, but if I should be doing something else please let me know.

I’ll try this out in our test environment as see if it resolves the issue.

Rhanks for reporting this. Can you submit an issue for the shutdown.

Luis Majano
CEO
Ortus Solutions, Corp
Toll Free/Fax: 1-888-557-8057
Direct: 909-248-3408
www.ortussolutions.com
Twitter: @lmajano, @ortussolutions

I submitted the ticket (https://www.assembla.com/spaces/coldbox/tickets/1435).

I have been doing a lot of reinit’s today after adding the shutdown() to my reinit script, and we have had a pretty decent amount of activity on the server. The error only showed up once, which is a pretty big improvement. It happened to an active user, right after I did the reinit. I did another reinit and it fixed the problem.

I’m pretty sure this error will go away once I stop doing the reinit on our testing server… it’s such a time saver though I’m having a hard time forcing myself to restart the app server.

Thanks for all the assistance, and I will let you know if anything changes.

Wade,

I would suggest something.

  1. Using a reinit is a brute force of restarting ANY container and in all reality it should be a development tool and not a production approach. With that said, using force reinits can cause side effects in ANY system.

  2. A better approach would be to leverage the ColdFusion “applicationStop()” approach.

Good points. Doing something like a reinit in a production environment would be a bad idea. My main concern with this issue is understanding what is causing it before moving my application into production. I am reasonably sure now that it only shows up after a reinit is done in a shared testing environment, so I am much relieved.

Thanks again for the assistance and for making this excellent set of tools available to the community.

No problem Wade! We are definitely trying to push the envelope and help developers :slight_smile:

I am glad!

Luis

signature0.jpg

Luis F. Majano
CEO
Ortus Solutions, Corp
www.ortussolutions.com

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

Social: twitter.com/lmajano facebook.com/lmajano

Just wanted to let you know that I was able to confirm that this error is a bug (or incompatibility) with Railo 3.3.1.

I started adding “eagerinit” annotations to some of my singleton components and as soon as I did that this error showed up every time. I ran some tests with Railo 4.0.2 and there were no errors.

There has been a bug related to flex integration in Railo since rev 3.3.1, which has been preventing me from upgrading. The fix is in progress, so hopefully I’ll be able to upgrade soon!

Wade