Just an update that I've done this to my entire application in all the controllers and have not suffered any ills as far as I can tell. This still doesn't solve the beanfactory getting GC'd - there is a leak/reference somewhere that I have yet to track down - but it does make hot deploying the app easier.
Along the lines of another thread, I think I'm going to add RAM and bump the permgen waaaaaaay up so I can support more reloads before permgen gets into the danger range. Ultimately we need to eliminate sticky sessions and externalize the session scope into redis or something outside of CF and then I think we'll be all set. Brian On Wednesday, September 10, 2014 at 10:43:09 AM UTC-7, Brian G wrote: > > > On Sunday, September 7, 2014 5:04:13 AM UTC-7, Dan Wilson - > [email protected] wrote: >> >> The documentation part is important and I do prefer it to be this way >> when I write my code. However, a continuous integration scenario may rate >> higher on the priority scale for you. >> >> The caching part is negligible since ColdSpring will be serving >> references to your beans from a cached state. Thus, there is likely no >> performance advantage worth speaking about. >> >> Please share your findings >> > > > I changed a single controller from autowired set/getServiceObject() to use > getModelGlue().getBean() and was successful. I can change my service > layer, restart my beanfactory and the next reload of my MG app picks up the > changes without reinitializing the MG app. I haven't done any tests under > load, but that's very exciting. > > The next test is to verify if doing this successfully allows the > beanfactory to be garbage collected. By overwriting the original > coldspring instance in the application scope, it *should* be collectable. > However, my experience with that actually happening is less than 100%. > Otherwise what I've seen is that refreshing the beanfactory multiple times > eventually leads to a PermGen error and crashes the instance. > > The ability to restart an app without crashing during a request is > definitely worth the tradeoff of the documentation of the beans scope. > Personally I centralize the calls behind a getServiceObject() in the > Controller and that method was previously returning variables.ServiceObject > (when auto-wired by CS) and now is calling getModelGlue().getBean(). > > > 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 [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 --- You received this message because you are subscribed to the Google Groups "model-glue" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
