For the record, I don't mind if we have this discussion on this list. It seems some of the members are finding it interesting.
As far as MG's use of scope caching, all scope caching is flushed when the reloadKey=reloadPassword are present. There is no need, from MG's perspective anyways, of doing anything further to get a clean, up to date version of your application in memory. Doing this, at most, takes 30-60 seconds. This, of course, depends on the complexity of your model, MG application and the needs of each during instantiation. Furthermore, this process is blocked for other users until the application is loaded, so as not to overwhelm the server with multiple requests to load the framework. DW On Fri, Oct 1, 2010 at 5:47 PM, Roy Martin <[email protected]> wrote: > @Dan - In general you are correct, this is a ColdFusion deployment issue. > What I was curious about is to see if other people that deploy MG > applications came-up with an elegant solution to this problem. Specifically > because the MG apps cache the controller code / MG application code by > default so you are forced to deal with this issue when deploying updates to > the application in MG in a cluster. But in general, you would be forced to > do this with anything that caches objects in the application scope, etc. > > @Chris - Each instance does have an internal webserver port. However, when > I tried to access the site with this port it simply returns to the > ColdFusion root. For instance www.sitename.com:8301, www.sitename.com:8302 > , www.sitename.com:8303, etc all just return the CFIDE directory and not > the site itself. This would be the ideal option, but I just can't figure out > how to point the server to that specific port. > > @Allen - Pulling each instance out, verifying the result and then adding it > back to the cluster has been the recommendation from another CF engineer I > talked too as well. But from what we could determine this remained a manual > process. We are trying to reduce as much manual overhead as possible. We > have a integration machine that matches production 100%, so in theory all of > our functional / unit test run against the build before it's launched. We're > trying to hook the last point of the process into the automated deployment > which would deploy the update, initialize the application and then do a > verification on the server. > > The only other alternative we've come-up with here is to make this > automated would be to write a script on the server that slowly cycles each > instance, allow the users from that instance to fail-over and then continue > down the process. Overall, we're just trying to find a solution that doesn't > cause the server to have to do a query or file read on EVERY request just to > see if it should restart. Also, this would be problematic as if we deployed > the update and all instances reloaded at the same time it could bring the > cluster down as they are all refreshing at the same time. > > However, since this discussion is slightly off topic I'll take this > discussion off-list for now, and post back the results once we find a good > solution. If anyone has another forum they would suggest I take the > discussion to or would like to continue it with me off-list please contact > me directly. > > Thanks for your help, > Roy > > -- > 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 [email protected] > To unsubscribe from this group, send email to > [email protected]<model-glue%[email protected]> > For more options, visit this group at > http://groups.google.com/group/model-glue?hl=en > -- William Osler - "We are here to add what we can to life, not to get what we can from life." -- 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/model-glue?hl=en
