reloadBeanFactory and parent bean factories

[Brian G]

Quick Q - if I have a parent bean factory, will reloadBeanFactory set to false really do much for me?

My read of the code is that, reloadBeanFactory=false will save the full instantiation of ModelGlue.gesture.loading.ColdSpringBootstrapper and instead call application[modelglue_app_key].reset() but I'm not clear how different that is.  Just recreating the bean factory for Model Glue happens pretty quickly; it's my parent bean factory (application.cs) that has 100 singletons in it which takes a long time.

.reset() runs:

    <cfset structClear(this.messageListeners) />
    <cfset structClear(this.controllers) />
    <cfset structClear(this.eventHandlers) />
    <cfset structClear(this.eventTypes) />

Does this force pretty much the same reinit process as in Unity if you are using a parent bean factory?


Brian

[Dan Wilson]

I wonder if you might be best served creating the parent bean factory in it's own process, then hooking back up to it when it's created?

Am I right in rephrasing the problem you are having, is the portion of time when the parent bean factory is gone, and current requests are trying to access objects in the bean factory?

100 objects isn't that many to create, especially on CF9 and above. The better question is what is required internally to instantiate all of those objects? Do you have complex init() depenencies?

DW

--
Model-Glue Sites:
Home Page: http://www.model-glue.com
Documentation: http://docs.model-glue.com
Bug Tracker: http://bugs.model-glue.com
Blog: http://www.model-glue.com/blog
 
You received this message because you are subscribed to the Google
Groups "model-glue" group.
To post to this group, send email to model...@googlegroups.com
To unsubscribe from this group, send email to
model-glue+...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/model-glue?hl=en

--
Plutarch - "The mind is not a vessel to be filled but a fire to be kindled."

[Brian G]

I don't know exactly...  I believe the issue is that in one request, I'm calling ?reinit=true.   Let's say it takes a total of 30-60s to redo everything (I'm on CF8 FWIW but other than performance I don't think that's relevant).

While it's reiniting in my request, other people are hitting the site.  I *think* what's happening is that any request from another user that has already begun before the new BeanFactory is in place but keeps running AFTER it's assigned is getting indeterminate state. 

Basically, if an MG request starts off and somewhere through the process the BeanFactory changes in the middle of code executing a request, things get "weird".


Brian

[Dan Wilson]

Isn't that because the bean factory is, in essence, gone?

While we have a feature intended to not reload the bean factory, and just reload MG Configs, I do not believe we have a feature to make the bean factory disappear in the middle of a request. Isn't this what you are doing?

In short, I think what you may need to try, is reload your parent bean factory, then reload MG through the built in mechanism provided. It is locked and handles the reloading in a specific order.

If I'm not understanding correctly,maybe try explaining again.

DW

[Brian G]

Let's say you have application.cs which is your PARENT_BEAN_FACTORY.

You have 10 other users hitting the site, they are in the middle of a request to index.cfm which is using an already-initialized Model-Glue and they are happily processing requests.

Now, I start the process of ?reinit=true which in my OnRequestStart, first calls onApplicationStart() (or just recreates application.cs) and then subsequently re-initializes Model Glue.

But, the nanosecond application.cs is reassigned, the other 10 users with in-progress requests piped through Model-Glue to the service layer begin acting crazy because, as you correctly point out, the beanfactory to which MG has a reference no longer exists.

We need some way of locking model-glue from performing a request while we recreate the bean factory and assign it.


Brian

[Dan Wilson]

I believe that takes place in ModelGlue.cfm

The lock is exclusive and is double checked as is best practice.

However, I don't believe your parent bean factory is under that same lock. So when you remove that bean factory, it's out of the protected zone, thus problems arise, no?

Dw

--

[Brian G]

On Wednesday, November 7, 2012 5:48:24 PM UTC-8, Dan Wilson - sipa...@gmail.com wrote:

I believe that takes place in ModelGlue.cfm

The lock is exclusive and is double checked as is best practice.

However, I don't believe your parent bean factory is under that same lock. So when you remove that bean factory, it's out of the protected zone, thus problems arise, no?

Correct - the exclusive named lock only prevents duplicate initializations; it doesn't do anything related to non-reinit MG requests from accessing values/objects that are changing during the initialization like the parent bean factory. 

We need a method of telling MG to lock/unlock access to the parent bean factory while we reinit it.  An exclusive lock on the app scope might do it?  I don't know if that would be hard to obtain in practice in production or if it would just cause a lot of timeouts?

Brian
 

[Dan Wilson]

One way to look at this is the parent bean factory is not controlled by ModelGlue. It's expected this will be instantiated and passed to Model Glue. (Look in ModelGlue.cfm)

Reloading the Parent Bean Factory is the responsibility of the parent bean factory control mechanism. So, if you need to restrict access to this, you need to do it in the location where you reload your parent bean factory.
You may consider creating your new beanfactory in a separate application variable, then switch it over when it is instantiated. But as it stands, I don't see how MG can get involved with this process, because the parent bean factory lives inside a different context.


DW


Brian G wrote:

On Wednesday, November 7, 2012 5:48:24 PM UTC-8, Dan Wilson -
sipa...@gmail.com wrote:

    I believe that ta kes place in ModelGlue.cfm

    The lock is exclusive and is double checked as is best practice.

    However, I don't believe your parent bean factory is under that
    same lock. So when you remove that bean factory, it's out of the
    protected zone, thus problems arise, no?


Correct - the exclusive named lock only prevents duplicate
initializations; it doesn't do anything related to non-reinit MG
requests from accessing values/objects that are changing during the
initialization like the parent bean factory.

We need a method of telling MG to lock/unlock access to the parent
bean factory while we reinit it. An exclusive lock on the app scope
might do it? I don't know if that would be hard to obtain in practice
in production or if it would just cause a lot of timeouts?

Brian

[Brian G]

On Thursday, November 8, 2012 9:19:56 AM UTC-8, Dan Wilson - sipa...@gmail.com wrote:

One way to look at this is the parent bean factory is not controlled by ModelGlue. It's expected this will be instantiated and passed to Model Glue. (Look in ModelGlue.cfm)

Reloading the Parent Bean Factory is the responsibility of the parent bean factory control mechanism. So, if you need to restrict access to this, you need to do it in the location where you reload your parent bean factory.
You may consider creating your new beanfactory in a separate application variable, then switch it over when it is instantiated. But as it stands, I don't see how MG can get involved with this process, because the parent bean factory lives inside a different context.

I don't disagree per se, but since this is the general design paradigm of a parent bean factory and continuous deployment and/or code pushes without interrupting users is a significantly valuable goal, I think we should look at it.

I think the problem is that MG's setParent() for the parent_bean_factory is not thread-safe.

I'm trying alternative approaches today using onApplicationStop() but that results in even more weirdness.  Request scope variables set in a controller don't exist when I get to a view template... I'm going to try to start at the beginning, load testing each step, and see where I can get to.  Also might see if I can setup a basic MG app and demonstrate it there too.


Brian

[Dan Wilson]

Well, let's think about this.

Set Parent, expects a fully hydrated bean factory to be in place and get handed to MG. Which makes sense, because ParentBeanFactories may/usually service more than one MG application instance. So MG couldn't reload the bean factory on it's own, without screwing over other (potential) MG instances.


So, I'd say it is thread safe as long as your reload functionality for the parent bean factory is thread safe.



Would it be possible to do something like this?

if( reloadBeanFactory){

--Lock--
var newBeanFactory = createNewParentBeanFactory;
application.parent_bean_factory_for_model_glue = newBeanFactory;
--Unlock

}


That would minimize the time the parent bean factory is stale. When you have it fully hydrated, then replace the application instance with the newly instantiated one.


Thoughts?

   

DW

Brian G

Thursday, November 08, 2012 2:23 PM

--
Model-Glue Sites:
Home Page: http://www.model-glue.com
Documentation: http://docs.model-glue.com
Bug Tracker: http://bugs.model-glue.com
Blog: http://www.model-glue.com/blog
 
You received this message because you are subscribed to the Google
Groups "model-glue" group.
To post to this group, send email to model...@googlegroups.com
To unsubscribe from this group, send email to
model-glue+...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/model-glue?hl=en

Dan Wilson

Thursday, November 08, 2012 12:19 PM

One way to look at this is the parent bean factory is not controlled by ModelGlue. It's expected this will be instantiated and passed to Model Glue. (Look in ModelGlue.cfm)

Reloading the Parent Bean Factory is the responsibility of the parent bean factory control mechanism. So, if you need to restrict access to this, you need to do it in the location where you reload your parent bean factory.
You may consider creating your new beanfactory in a separate application variable, then switch it over when it is instantiated. But as it stands, I don't see how MG can get involved with this process, because the parent bean factory lives inside a different context.

DW


Brian G wrote:

Brian G

Thursday, November 08, 2012 9:57 AM

On Wednesday, November 7, 2012 5:48:24 PM UTC-8, Dan Wilson - sipa...@gmail.com wrote:

Correct - the exclusive named lock only prevents duplicate initializations; it doesn't do anything related to non-reinit MG requests from accessing values/objects that are changing during the initialization like the parent bean factory. 

We need a method of telling MG to lock/unlock access to the parent bean factory while we reinit it.  An exclusive lock on the app scope might do it?  I don't know if that would be hard to obtain in practice in production or if it would just cause a lot of timeouts?

Brian
 

--
Model-Glue Sites:
Home Page: http://www.model-glue.com
Documentation: http://docs.model-glue.com
Bug Tracker: http://bugs.model-glue.com
Blog: http://www.model-glue.com/blog
 
You received this message because you are subscribed to the Google
Groups "model-glue" group.
To post to this group, send email to model...@googlegroups.com
To unsubscribe from this group, send email to
model-glue+...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/model-glue?hl=en

Dan Wilson

Wednesday, November 07, 2012 8:48 PM

I believe that takes place in ModelGlue.cfm

The lock is exclusive and is double checked as is best practice.

However, I don't believe your parent bean factory is under that same lock. So when you remove that bean factory, it's out of the protected zone, thus problems arise, no?

Dw

Brian G

Wednesday, November 07, 2012 8:31 PM

Let's say you have application.cs which is your PARENT_BEAN_FACTORY.

You have 10 other users hitting the site, they are in the middle of a request to index.cfm which is using an already-initialized Model-Glue and they are happily processing requests.

Now, I start the process of ?reinit=true which in my OnRequestStart, first calls onApplicationStart() (or just recreates application.cs) and then subsequently re-initializes Model Glue.

But, the nanosecond application.cs is reassigned, the other 10 users with in-progress requests piped through Model-Glue to the service layer begin acting crazy because, as you correctly point out, the beanfactory to which MG has a reference no longer exists.

We need some way of locking model-glue from performing a request while we recreate the bean factory and assign it.


Brian

On Monday, November 5, 2012 4:45:46 PM UTC-8, Dan Wilson - sipa...@gmail.com wrote: --

[Brian G]

That's what I'm doing:

<cfif NOT structKeyExists(application, "cs") OR structKeyExists(URL, "reinit")>
   <cflock name="applicationReinit" type="exclusive" timeout="60">
      <cfif NOT structKeyExists(application, "cs") OR structKeyExists(URL, "reinit")>
        ....

        <cfset bf = createObject("component", "coldspring.beans.DefaultXmlBeanFactory").init() />
        <cfset bf.loadBeansFromXmlFile(expandPath("/PUKKA_MAIN_MAP/config/globalbeans.xml"), true) />
        <cfset application.cs = bf />

      </cfif>
    </cflock>
</cfif>

I think the problem is... this code runs, and it gets down to index.cfm which sets:

<cfset ModelGlue_PARENT_BEAN_FACTORY = application.cs />
...
<cfinclude template="/ModelGlue/gesture/ModelGlue.cfm" />

I think this is the part that's not thread safe.  Imagine that I have a request that's taking 5 seconds to run, so the code is already down to index.cfm and running a model glue request.

Now, in another window, I reinit the beanfactory using the above code and it gets down to this line of code.  When ModelGlue.cfm runs, it's going to update the Parent Beanfactory in the Model Glue object cached in the application scope.

As soon as that happens, the next line of code in my 5s running thread now hits a new version of the parent beanfactory (and presumably ORM/Transfer or whatever your service layer abstracts).  Things then begin blowing up.


Brian

[Dan Wilson]

Yeah, I can see what you mean. However, I have no idea how to make that threadsafe, since multiple threads are accessing it.

I'm open to ideas.

DW

[Dan Wilson]

I think you just aren't going to be able to reload the parent bean factory without screwing up your child applications. While both initialization processes are locked, they aren't the same lock. Thus, when you change the parent bean factory and the lock releases, the other applications are going to get mid-stream changes.

Remember, your parent bean factory is OUTSIDE the scope of ModelGlue, so I don't really know what ModelGlue can do about it. You are essentially pulling the rug out from running requests.

Where MG gets involved is when the ModelGlue_PARENT_BEAN_FACTORY variable is set in ModelGlue.cfm. That is then pushed through an exclusive lock and the internal ColdSpring factory is created, with the ModelGlue_PARENT_BEAN_FACTORY attached in the parent spot. Since this is locked exclusively, it seems like this wouldn't be an issue.

Have you possibly tried some way to put the new ParentBeanFactory in a different key in the application scope? Then passing the new key to the MG child apps for reload?


DW

[Brian G]

On Monday, November 12, 2012 5:41:47 PM UTC-8, Dan Wilson - sipa...@gmail.com wrote:

Have you possibly tried some way to put the new ParentBeanFactory in a different key in the application scope? Then passing the new key to the MG child apps for reload?

I haven't tried that yet but I did consider it.  I think it's something worth looking at.  We would need to change index.cfm so that <cfset ModelGlue_PARENT_BEAN_FACTORY = application.cs /> happened in onRequestStart based upon some simple tracking.  I do like this as it would facilitate cleanly shutting down the existing Transfer/ORM caches too.

I had a "cooldown" approach that I tried and which did not reduce errors that I can adapt for this I think.  I'll give it a go.


Brian

[Brian G]

On Tuesday, November 13, 2012 2:59:17 PM UTC-8, Brian G wrote:

On Monday, November 12, 2012 5:41:47 PM UTC-8, Dan Wilson - sipa...@gmail.com wrote:

Have you possibly tried some way to put the new ParentBeanFactory in a different key in the application scope? Then passing the new key to the MG child apps for reload?

I have good news and bad news.  The good news is that it turns out this issue is unrelated (or at least not dependent on) parent bean factories.  The bad news is that something fundamental in MG 3.2 (dunno about earlier) is broken in the init process.

After several hours of trying to manipulate the startup process in my application and getting nowhere, I decided to try it against the MG 3 Hello World application.  Sadly, with just rudimentary code and a tiny bit of load (10 users), I can reliably get MG to throw an error while reinitializing itself.  Here's the steps:

1. Fire up Jmeter against the home page for my Hello, World app
2. After traffic stabilizes, in a separate browser window, trigger ?init=true
3. Watch errors fly

This is with the version of MG 3.2 that you sent me Dan. There is something amiss with the locking or init in MG.  Simultaneous access while loading consistently throws errors where objects that should be in the event bucket are not populated.  There is something resetting or emptying the contents of the event bucket/viewstate during the initialization process.  When you try to execute a method on one of these objects, it blows up with an error like this:

The getID method was not found.

Either there are no methods with the specified method name and argument types, or the getID method is overloaded with argument types that ColdFusion cannot decipher reliably. ColdFusion found 0 methods that matched the provided arguments. If this is a Java object and you verified that the method exists, you may need to use the javacast function to reduce ambiguity.

The error occurred inC:\Users\brian\Documents\web\mg\modelgluesamples\helloworld\views\pages\index.cfm: line 32 Called from C:\Users\brian\Documents\web\trunk-shared\ModelGlue\gesture\view\ViewRenderer.cfm: line 33 Called from C:\Users\brian\Documents\web\trunk-shared\ModelGlue\gesture\view\ViewRenderer.cfc: line 84 Called from C:\Users\brian\Documents\web\trunk-shared\ModelGlue\gesture\eventrequest\EventContext.cfc: line 687 Called from C:\Users\brian\Documents\web\trunk-shared\ModelGlue\gesture\eventrequest\EventContext.cfc: line 285 Called from C:\Users\brian\Documents\web\trunk-shared\ModelGlue\gesture\eventrequest\phase\Invocation.cfc: line 96 Called from C:\Users\brian\Documents\web\trunk-shared\ModelGlue\gesture\eventrequest\EventContext.cfc: line 189 Called from C:\Users\brian\Documents\web\trunk-shared\ModelGlue\gesture\ModelGlue.cfc: line 297 Called from C:\Users\brian\Documents\web\trunk-shared\ModelGlue\gesture\ModelGlue.cfm: line 110 Called from C:\Users\brian\Documents\web\mg\modelgluesamples\helloworld\index.cfm: line 78

30 : 31 : <cfset obj = viewState.getValue("testObject") /> 32 : <cfoutput>#obj.getID()#</cfoutput> 33 : 34 : <p>

Resources: Check the ColdFusion documentation to verify that you are using the correct syntax. Search the Knowledge Base to find a solution to your problem.

Browser   Apache-HttpClient/4.2.1 (java 1.5) Remote Address   127.0.0.1 Referrer   Date/Time   13-Dec-12 07:39 PM

Stack Trace

at cfindex2ecfm1701861048.runPage(C:\Users\brian\Documents\web\mg\modelgluesamples\helloworld\views\pages\index.cfm:32) at cfViewRenderer2ecfm1037665257.runPage(C:\Users\brian\Documents\web\trunk-shared\ModelGlue\gesture\view\ViewRenderer.cfm:33) at cfViewRenderer2ecfc1037665043$funcRENDERVIEW.runFunction(C:\Users\brian\Documents\web\trunk-shared\ModelGlue\gesture\view\ViewRenderer.cfc:84) at cfEventContext2ecfc516297268$funcRENDERVIEW.runFunction(C:\Users\brian\Documents\web\trunk-shared\ModelGlue\gesture\eventrequest\EventContext.cfc:687) at cfEventContext2ecfc516297268$funcEXECUTEEVENTQUEUE.runFunction(C:\Users\brian\Documents\web\trunk-shared\ModelGlue\gesture\eventrequest\EventContext.cfc:285) at cfInvocation2ecfc905915655$funcEXECUTE.runFunction(C:\Users\brian\Documents\web\trunk-shared\ModelGlue\gesture\eventrequest\phase\Invocation.cfc:96) at cfEventContext2ecfc516297268$funcEXECUTE.runFunction(C:\Users\brian\Documents\web\trunk-shared\ModelGlue\gesture\eventrequest\EventContext.cfc:189) at cfModelGlue2ecfc217417458$funcHANDLEREQUEST.runFunction(C:\Users\brian\Documents\web\trunk-shared\ModelGlue\gesture\ModelGlue.cfc:297) at cfModelGlue2ecfm217417416.runPage(C:\Users\brian\Documents\web\trunk-shared\ModelGlue\gesture\ModelGlue.cfm:110) at cfindex2ecfm1265377074.runPage(C:\Users\brian\Documents\web\mg\modelgluesamples\helloworld\index.cfm:78)  coldfusion.runtime.java.MethodSelectionException: The getID method was not found. at coldfusion.runtime.java.ObjectHandler.findMethodUsingCFMLRules(ObjectHandler.java:322) at coldfusion.runtime.StructBean.invoke(StructBean.java:527) at coldfusion.runtime.CfJspPage._invoke(CfJspPage.java:2300) at cfindex2ecfm1701861048.runPage(C:\Users\brian\Documents\web\mg\modelgluesamples\helloworld\views\pages\index.cfm:32) at coldfusion.runtime.CfJspPage.invoke(CfJspPage.java:196) at coldfusion.tagext.lang.IncludeTag.doStartTag(IncludeTag.java:370) at coldfusion.runtime.CfJspPage._emptyTcfTag(CfJspPage.java:2661) at cfViewRenderer2ecfm1037665257.runPage(C:\Users\brian\Documents\web\trunk-shared\ModelGlue\gesture\view\ViewRenderer.cfm:33) at coldfusion.runtime.CfJspPage.invoke(CfJspPage.java:196) at coldfusion.filter.CFVariablesScopeFilter.invoke(CFVariablesScopeFilter.java:63) at coldfusion.tagext.lang.ModuleTag.doStartTag(ModuleTag.java:280) at coldfusion.runtime.CfJspPage._emptyTcfTag(CfJspPage.java:2661) at cfViewRenderer2ecfc1037665043$funcRENDERVIEW.runFunction(C:\Users\brian\Documents\web\trunk-shared\ModelGlue\gesture\view\ViewRenderer.cfc:84) at coldfusion.runtime.UDFMethod.invoke(UDFMethod.java:418) at coldfusion.filter.SilentFilter.invoke(SilentFilter.java:47) at coldfusion.runtime.UDFMethod$ArgumentCollectionFilter.invoke(UDFMethod.java:324) at coldfusion.filter.FunctionAccessFilter.invoke(FunctionAccessFilter.java:59) at coldfusion.runtime.UDFMethod.runFilterChain(UDFMethod.java:277) at coldfusion.runtime.UDFMethod.invoke(UDFMethod.java:192) at coldfusion.runtime.TemplateProxy.invoke(TemplateProxy.java:448) at coldfusion.runtime.TemplateProxy.invoke(TemplateProxy.java:308) at coldfusion.runtime.CfJspPage._invoke(CfJspPage.java:2272) at cfEventContext2ecfc516297268$funcRENDERVIEW.runFunction(C:\Users\brian\Documents\web\trunk-shared\ModelGlue\gesture\eventrequest\EventContext.cfc:687) at coldfusion.runtime.UDFMethod.invoke(UDFMethod.java:418) at coldfusion.filter.SilentFilter.invoke(SilentFilter.java:47) at coldfusion.runtime.UDFMethod$ArgumentCollectionFilter.invoke(UDFMethod.java:324) at coldfusion.filter.FunctionAccessFilter.invoke(FunctionAccessFilter.java:59) at coldfusion.runtime.UDFMethod.runFilterChain(UDFMethod.java:277) at coldfusion.runtime.UDFMethod.invoke(UDFMethod.java:192) at coldfusion.runtime.CfJspPage._invokeUDF(CfJspPage.java:2471) at cfEventContext2ecfc516297268$funcEXECUTEEVENTQUEUE.runFunction(C:\Users\brian\Documents\web\trunk-shared\ModelGlue\gesture\eventrequest\EventContext.cfc:285) at coldfusion.runtime.UDFMethod.invoke(UDFMethod.java:418) at coldfusion.filter.SilentFilter.invoke(SilentFilter.java:47) at coldfusion.runtime.UDFMethod$ArgumentCollectionFilter.invoke(UDFMethod.java:324) at coldfusion.filter.FunctionAccessFilter.invoke(FunctionAccessFilter.java:59) at coldfusion.runtime.UDFMethod.runFilterChain(UDFMethod.java:277) at coldfusion.runtime.UDFMethod.invoke(UDFMethod.java:192) at coldfusion.runtime.TemplateProxy.invoke(TemplateProxy.java:448) at coldfusion.runtime.TemplateProxy.invoke(TemplateProxy.java:308) at coldfusion.runtime.CfJspPage._invoke(CfJspPage.java:2272) at cfInvocation2ecfc905915655$funcEXECUTE.runFunction(C:\Users\brian\Documents\web\trunk-shared\ModelGlue\gesture\eventrequest\phase\Invocation.cfc:96) at coldfusion.runtime.UDFMethod.invoke(UDFMethod.java:418) at coldfusion.filter.SilentFilter.invoke(SilentFilter.java:47) at coldfusion.runtime.UDFMethod$ReturnTypeFilter.invoke(UDFMethod.java:360) at coldfusion.runtime.UDFMethod$ArgumentCollectionFilter.invoke(UDFMethod.java:324) at coldfusion.filter.FunctionAccessFilter.invoke(FunctionAccessFilter.java:59) at coldfusion.runtime.UDFMethod.runFilterChain(UDFMethod.java:277) at coldfusion.runtime.UDFMethod.invoke(UDFMethod.java:192) at coldfusion.runtime.TemplateProxy.invoke(TemplateProxy.java:448) at coldfusion.runtime.TemplateProxy.invoke(TemplateProxy.java:308) at coldfusion.runtime.CfJspPage._invoke(CfJspPage.java:2272) at cfEventContext2ecfc516297268$funcEXECUTE.runFunction(C:\Users\brian\Documents\web\trunk-shared\ModelGlue\gesture\eventrequest\EventContext.cfc:189) at coldfusion.runtime.UDFMethod.invoke(UDFMethod.java:418) at coldfusion.filter.SilentFilter.invoke(SilentFilter.java:47) at coldfusion.runtime.UDFMethod$ArgumentCollectionFilter.invoke(UDFMethod.java:324) at coldfusion.filter.FunctionAccessFilter.invoke(FunctionAccessFilter.java:59) at coldfusion.runtime.UDFMethod.runFilterChain(UDFMethod.java:277) at coldfusion.runtime.UDFMethod.invoke(UDFMethod.java:192) at coldfusion.runtime.TemplateProxy.invoke(TemplateProxy.java:448) at coldfusion.runtime.TemplateProxy.invoke(TemplateProxy.java:308) at coldfusion.runtime.CfJspPage._invoke(CfJspPage.java:2272) at cfModelGlue2ecfc217417458$funcHANDLEREQUEST.runFunction(C:\Users\brian\Documents\web\trunk-shared\ModelGlue\gesture\ModelGlue.cfc:297) at coldfusion.runtime.UDFMethod.invoke(UDFMethod.java:418) at coldfusion.filter.SilentFilter.invoke(SilentFilter.java:47) at coldfusion.runtime.UDFMethod$ArgumentCollectionFilter.invoke(UDFMethod.java:324) at coldfusion.filter.FunctionAccessFilter.invoke(FunctionAccessFilter.java:59) at coldfusion.runtime.UDFMethod.runFilterChain(UDFMethod.java:277) at coldfusion.runtime.UDFMethod.invoke(UDFMethod.java:192) at coldfusion.runtime.TemplateProxy.invoke(TemplateProxy.java:448) at coldfusion.runtime.TemplateProxy.invoke(TemplateProxy.java:308) at coldfusion.runtime.CfJspPage._invoke(CfJspPage.java:2272) at cfModelGlue2ecfm217417416.runPage(C:\Users\brian\Documents\web\trunk-shared\ModelGlue\gesture\ModelGlue.cfm:110) at coldfusion.runtime.CfJspPage.invoke(CfJspPage.java:196) at coldfusion.tagext.lang.IncludeTag.doStartTag(IncludeTag.java:370) at coldfusion.runtime.CfJspPage._emptyTcfTag(CfJspPage.java:2661) at cfindex2ecfm1265377074.runPage(C:\Users\brian\Documents\web\mg\modelgluesamples\helloworld\index.cfm:78) at coldfusion.runtime.CfJspPage.invoke(CfJspPage.java:196) at coldfusion.tagext.lang.IncludeTag.doStartTag(IncludeTag.java:370) at coldfusion.filter.CfincludeFilter.invoke(CfincludeFilter.java:65) at coldfusion.filter.ApplicationFilter.invoke(ApplicationFilter.java:273) at coldfusion.filter.RequestMonitorFilter.invoke(RequestMonitorFilter.java:48) at coldfusion.filter.MonitoringFilter.invoke(MonitoringFilter.java:40) at coldfusion.filter.PathFilter.invoke(PathFilter.java:86) at coldfusion.filter.LicenseFilter.invoke(LicenseFilter.java:27) at coldfusion.filter.ExceptionFilter.invoke(ExceptionFilter.java:70) at coldfusion.filter.ClientScopePersistenceFilter.invoke(ClientScopePersistenceFilter.java:28) at coldfusion.filter.BrowserFilter.invoke(BrowserFilter.java:38) at coldfusion.filter.NoCacheFilter.invoke(NoCacheFilter.java:46) at coldfusion.filter.GlobalsFilter.invoke(GlobalsFilter.java:38) at coldfusion.filter.DatasourceFilter.invoke(DatasourceFilter.java:22) at coldfusion.CfmServlet.service(CfmServlet.java:175) at coldfusion.bootstrap.BootstrapServlet.service(BootstrapServlet.java:89) at jrun.servlet.FilterChain.doFilter(FilterChain.java:86) at coldfusion.monitor.event.MonitoringServletFilter.doFilter(MonitoringServletFilter.java:42) at coldfusion.bootstrap.BootstrapFilter.doFilter(BootstrapFilter.java:46) at jrun.servlet.FilterChain.doFilter(FilterChain.java:94) at jrun.servlet.FilterChain.service(FilterChain.java:101) at jrun.servlet.ServletInvoker.invoke(ServletInvoker.java:106) at jrun.servlet.JRunInvokerChain.invokeNext(JRunInvokerChain.java:42) at jrun.servlet.JRunRequestDispatcher.invoke(JRunRequestDispatcher.java:286) at jrun.servlet.ServletEngineService.dispatch(ServletEngineService.java:543) at jrun.servlet.jrpp.JRunProxyService.invokeRunnable(JRunProxyService.java:203) at jrunx.scheduler.ThreadPool$ThreadThrottle.invokeRunnable(ThreadPool.java:428) at jrunx.scheduler.WorkerThread.run(WorkerThread.java:66)

[Dan Wilson]

Hey Brian,

I'm happy to look in to this and provide a fix. However, we are days away from having our new (2nd) child. So, I need to be efficient with my time.

I saw you sent me your sample app in a different email, thanks for that. Do me a favor and also send me your load test script, any specific steps, and any additional information you can give me so I can work on this in a targeted way. Here's what I see I need:

1 - A way to replicate your exact findings. Please be specific here with what I need to do to set this up and to recreate the exact problems you've found

2 - Any information you've uncovered as to what may be the source of the code issues.

 Keep in mind, whatever is happening is happening way deep in the core, way deep in many many layers of abstraction. So it may take me a minute, but if you can send me the things I'll need to very easily replicate the issue, I promise to look into this and provide an update to the core.

DW

--
Model-Glue Sites:
Home Page: http://www.model-glue.com
Documentation: http://docs.model-glue.com
Bug Tracker: http://bugs.model-glue.com
Blog: http://www.model-glue.com/blog
 
You received this message because you are subscribed to the Google
Groups "model-glue" group.
To post to this group, send email to model...@googlegroups.com
To unsubscribe from this group, send email to
model-glue+...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/model-glue?hl=en

[Brian G]

On Friday, December 14, 2012 4:24:41 AM UTC-8, Dan Wilson - sipa...@gmail.com wrote:

I'm happy to look in to this and provide a fix. However, we are days away from having our new (2nd) child. So, I need to be efficient with my time.

Congrats!  Totally understood.  I think what I sent you is easy to reproduce and understand.
 

I saw you sent me your sample app in a different email, thanks for that. Do me a favor and also send me your load test script, any specific steps, and any additional information you can give me so I can work on this in a targeted way. Here's what I see I need:

1 - A way to replicate your exact findings. Please be specific here with what I need to do to set this up and to recreate the exact problems you've found

2 - Any information you've uncovered as to what may be the source of the code issues.

 Keep in mind, whatever is happening is happening way deep in the core, way deep in many many layers of abstraction. So it may take me a minute, but if you can send me the things I'll need to very easily replicate the issue, I promise to look into this and provide an update to the core.

As far as I can tell in further testing, this isn't happening in 3.1 so it appears to be a Memoization branch issue.  Here's the steps to reproduce:

* Download jMeter, extract, execute
* Set up a thread group, 10 users, hit your local hostname, use the /modelgluesamples/helloworld/index.cfm (I've attached my config)
* Fire up jMeter, give it 10 seconds to stabilize, the graph will show throughput.
* While jMeter is hitting the code, in a browser window trigger a reinit: /modelgluesamples/helloworld/index.cfm?reinit=true

Do it a few times... monitor the console output and you should see errors stream out.  I was able to get it to happen basically every time I triggered a ?reinit.  Shut down jmeter and it will have error*.html files in the bin directory you can peruse.


Brian

 

[Dan Skaggs]

Brian...

Can you confirm which branch you were seeing this behavior on. Your statement that "...appears to be a Memoization branch issue" stuck out at me. The latest code is actually in the "newScaffolds" branch. We are aware that we need to do some cleanup on branches and have a better naming convention coming that we're going to move to after the 3.2 release goes final.

As I'm looking at this today I just wanted to make sure we were both testing against the same code.

Thanks

Dan

[Brian G]

Dan - I meant branch in the abstract sense and not in the subversion/git sense.  I was using the 3.2 download from the website and a version that Dan W sent me (both exhibited the behavior).  Sorry for the confusion!


Brian

[Dan Skaggs]

No worries..I've been testing against both this afternoon. Dan W sent me the files you emailed to him.

I've not been able to get any errors with the helloWorld application that ships with the latest MG from GitHub but was able to generate some errors with the helloWorld app you sent over (although it's a different error than what showed up in the error files you sent over).

I'm going to keep digging and see what we can find out.

Thanks,

Dan

[Dan Skaggs]

Brian...

Dan W and I did some testing on this last week and he has made some changes that appear to have addressed this issue in our testing.  I've created a new release candidate build in the GitHub repository with the fixes. Could you grab it when you have time and see if your findings match ours? The URLs to the repo, tags and specific archive file are below. If this RC is indeed stable, we'll likely release the final 3.2 in the next week or two.

You may notice that we've done quite a bit of rearranging the last few days. The repo below now contains only the core framework files and tests. Other things that were in the repo before (like modelgluesamples, modelglueapplicationtemplate, etc) have been migrated to their own GitHub repos. We'll be doing a wider blog post and announcement on the migration to GitHub in conjunction with the 3.2 release.

Thanks

Dan

ModelGlue GitHub repo: https://github.com/modelglue/CFML-Framework

Tags: https://github.com/modelglue/CFML-Framework/tags

RC2 zip file: https://github.com/modelglue/CFML-Framework/archive/release-3.2-rc2.zip

[Dan Skaggs]

Brian...

Just a quick note to point out that the URLs have changed slightly based on some discussions the dev team has had. I wanted to get this out to you in case you hadn't downloaded the RC2 yet so you wouldn't hit an error with the old URLs:

ModelGlue GitHub repo: https://github.com/modelglue/modelglue-framework

Tags: https://github.com/modelglue/modelglue-framework/tags

RC2 zip file: https://github.com/modelglue/modelglue-framework/archive/release-3.2-rc2.zip

[Brian G]

Thanks Dan - I'm busy preparing for a trip to the UK next week.  I will download it and take it with me and do some load testing on the airplane if I don't get a chance sooner. :)

Thanks for taking a look at this; I'm excited it may be fixed!


Brian