Thank you Johann for chiming in. I appreciate you stating clearly what I intuited that WODynamicElements are “stateless” and I was right to remove all the instance variables that it was using.
Love this group of WOrriors - lots of knowledge and friendly folk willing to share and learn together. AARON ROSENZWEIG / Chat 'n Bike <http://www.chatnbike.com/> e: aa...@chatnbike.com <mailto:aa...@chatnbike.com> t: (301) 956-2319 > On Aug 8, 2020, at 5:36 AM, Johann Werner <johann.wer...@posteo.de> wrote: > > Hi Aaron, > > as you mentioned WODynamicElements and documentation about them is very > sparse as well being a special beast, let me say some words about them: > > WOComponent components being the easiest to grasp (and probably most used) > represent a WO tag within your HTML templates i.e. every time a page is > generated for the client its template will be parsed, for every WO tag an > instance of the WOComponent will be created, bindings will be synchronized, > the output generated, and finally—as you stated when that page drops out of > the backtrack cache—gc’ed. This will happen every time that page is called. > If you never requested that page or if it is not present in the backtrack > cache anymore, no instance (read memory) will be present. But that means if > you do request that page WO has first to create a lot of objects which has on > the one hand a performance penalty and on the other hand can lead to memory > peaks as for every request a full instance tree has to be generated. This is > especially important if you are running a high traffic site. > > On the contrary WODynamicElements are special components which are meant to > optimize that use case. Instead of WO creating an instance for every > occurence during output generation, dynamic elements are used as a sort of > output factory. So first time WO encounters a dynamic element it will be > created once (some simplification applied of course ;-) and used for every > page where it appears in the template. This instance is then cached, waiting > to be reused. By this you will have way less instances (did I say way less?) > resulting in less memory consumption and less performance overhead as you > don’t need to create lots of Java objects. > > So from this perspective your application will have a slightly higher minimum > memory consumption as you will keep one instance per dynamic element around > but have less memory peaks as well serving your pages faster. > > One implication of this is that you must not—read you will get into real big > trouble—use internal state / instance variables within a dynamic component. > That kind of component has to be thread safe because WO will reuse the same > object again and again for every component using it. Different users > requesting pages with that component in it means concurrent usage of the > dynamic component. So if you use instance variables: BOOOM, probably even > without you noticing anything but producing wrong output. If you used them > for access checks, that is a dangerous game… To circumvent that you already > mentioned WOAssociations, those will get/set values you need within your > current RR-loop and prevent a mix-match. > > TLDR: use WODynamicElements to optimize your application but know what you > are doing ;-) besides that those kind of components give you many more > features you cannot achieve with normal components. But that is another story. > > And back to the original question: I do not bounce apps either, had even an > application that ran without problems > 2 years in one go. > > Johann > > >> Am 08.08.2020 um 04:27 schrieb Aaron Rosenzweig via Webobjects-dev >> <webobjects-dev@lists.apple.com <mailto:webobjects-dev@lists.apple.com>>: >> >> Thanks everyone, >> >> It seems like a pretty even split between those who cycle daily and those >> who don’t. >> >> Perhaps it depends on the app and what minor leaks it might have tend to >> skew people to cycling daily… or maybe they are old farts, like me, who >> still remember the Objective-C days. It was a bit easier to leak then. >> >> I debugged something this week that was new to me, in this realm, so I >> thought I’d share. >> >> 1. WODynamicElement >> >> It appears that WODynamicElements, or anything that “is a,” don’t fall out >> of memory. Looks like an instance is created for every WOComponent class it >> is used in and never goes away for the life of the app. As users visit pages >> in a large app it creates a lot of WODynamicElements. These are things like >> WOString and WOConditional. We had our own child of WOConditional that did >> some processing based on user access permissions. Internally it was saving >> state including making its own sandboxed EOEditingContext. Because of this, >> that EC had legs and filled up quite a bit of memory in the app. I rewrote >> this WODynamicElement to not have any instance variables with the only >> exception being WOAssociations. >> >> WOComponents do fall out of memory when they fall out of the backtrack >> cache, WODynamicElements do not. Their are strange beasts who don’t have a >> “parent()” and don’t have a “context()” — It’s as if WO decides to cache >> them in memory for future use if they’ve ever been used on a page. Kind of >> like when you do “Integer.valueOf(10)” Java gives you the same instance of >> ten whereas “new Integer(10)” makes a new place in memory for another ten. >> Because ten is always ten, you might argue it’s better to use valueOf and >> get the same object to possibly save time. Others would argue to not do that >> so you can reclaim more. Perhaps a sucky analogy but it helped me think of >> why WODynamicElement doesn’t get reclaimed but WOComponents do. >> >> There are certainly other gotchas… if you have a “previous page” notion and >> don’t use weak references and don’t trim the length of the chain… you’ll >> have a very long lived chain of pages that goes further than the backtrack >> cache. >> >> 2. Full GC occurrences and object histogram >> >> You can dump a histogram of all the objects presently in memory using >> techniques listed here: >> https://medium.com/@jerolba/measuring-actual-memory-consumption-in-java-jmnemohistosyne-5eed2c1edd65 >> >> <https://medium.com/@jerolba/measuring-actual-memory-consumption-in-java-jmnemohistosyne-5eed2c1edd65> >> >> You can register to do something after every GC, such as logging, by using >> techniques listed here: >> http://www.fasterj.com/articles/gcnotifs.shtml >> <http://www.fasterj.com/articles/gcnotifs.shtml> >> >> AARON ROSENZWEIG / Chat 'n Bike <http://www.chatnbike.com/> >> e: aa...@chatnbike.com <mailto:aa...@chatnbike.com> t: (301) 956-2319 >> >> >>> On Aug 6, 2020, at 4:28 AM, Hugi Thordarson via Webobjects-dev >>> <webobjects-dev@lists.apple.com <mailto:webobjects-dev@lists.apple.com>> >>> wrote: >>> >>> I'd like to add a disclaimer to my EOF comment; I now recall I was invoking >>> a method as a workaround for something. Can't for the life of me remember >>> what it was or why (snapshots were getting GCd too early or something so I >>> had to invoke snapshotReferenceCountingSomethingElseOrOther()) but if >>> memory serves me right it might as well have been called >>> "beAwareYouAreNowExplicitlyLeakingMemory()". >>> >>> So—I was being unfair and my leaky EOF was probably because of me doing >>> something stupid :). >>> >>> - hugi >>> >>> >>> >>>> On 6 Aug 2020, at 05:33, Stefan Gärtner via Webobjects-dev >>>> <webobjects-dev@lists.apple.com <mailto:webobjects-dev@lists.apple.com>> >>>> wrote: >>>> >>>> We never bounce, but every few weeks we have an update, which certainly >>>> starts a new instance. >>>> We heavily use EOF. I never had the feeling that there is any memory leak, >>>> at least in our scenario. >>>> >>>> >>>>> Am 06.08.2020 um 00:56 schrieb D Tim Cummings via Webobjects-dev >>>>> <webobjects-dev@lists.apple.com <mailto:webobjects-dev@lists.apple.com>>: >>>>> >>>>> Daily for us. Once every few months we get an instance hanging and it is >>>>> clear at the start of the day that it has hung because it hasn’t >>>>> restarted overnight. >>>>> >>>>> Tim >>>>> >>>>>> On 6 Aug 2020, at 05:37, Lon Varscsak via Webobjects-dev >>>>>> <webobjects-dev@lists.apple.com <mailto:webobjects-dev@lists.apple.com>> >>>>>> wrote: >>>>>> >>>>>> We don't bounce our apps unless we do a release or if there's an >>>>>> instance that hangs. >>>>>> >>>>>> -Lon >>>>>> >>>>>> On Wed, Aug 5, 2020 at 9:09 AM Theodore Petrosky via Webobjects-dev >>>>>> <webobjects-dev@lists.apple.com <mailto:webobjects-dev@lists.apple.com>> >>>>>> wrote: >>>>>> My apps upload pdfs. As Java keeps the temp file that was uploaded until >>>>>> the app that did the upload quits, I bounce my apps every night to clean >>>>>> things up. >>>>>> >>>>>> Ted >>>>>> >>>>>>> On Aug 5, 2020, at 10:37 AM, Ken Anderson via Webobjects-dev >>>>>>> <webobjects-dev@lists.apple.com >>>>>>> <mailto:webobjects-dev@lists.apple.com>> wrote: >>>>>>> >>>>>>> I never bounce them - even with EOF ;) >>>>>>> >>>>>>>> On Aug 5, 2020, at 07:07, Jesse Tayler via Webobjects-dev >>>>>>>> <webobjects-dev@lists.apple.com >>>>>>>> <mailto:webobjects-dev@lists.apple.com>> wrote: >>>>>>>> >>>>>>>> What do you use to keep an eye on memory? JAVA has such an old-school >>>>>>>> approach with the VM I use AWS and really don’t have any good >>>>>>>> automated visualizing report on how instances or JAVA is running under >>>>>>>> the hood. >>>>>>>> >>>>>>>> My apps seem to run for a long time as a few times my scheduler has >>>>>>>> failed and they racked up 10X or even 100X normal sessions, but who >>>>>>>> knows what the user patterns were really — I have had to increase my >>>>>>>> JAVA VM and set memory stuff from JavaMonitor to keep things sane. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> On Aug 5, 2020, at 3:35 AM, Jérémy DE ROYER via Webobjects-dev >>>>>>>>> <webobjects-dev@lists.apple.com >>>>>>>>> <mailto:webobjects-dev@lists.apple.com>> wrote: >>>>>>>>> >>>>>>>>> Hi Aaron, >>>>>>>>> >>>>>>>>> (I’m still using EOF) and, for the main apps, I bounce every morning. >>>>>>>>> >>>>>>>>> After updates I sometimes forget to activate the schedules without >>>>>>>>> any problems… but I’m used to do it in the pasts where I had a lot of >>>>>>>>> meomry leaks so I still do it. >>>>>>>>> >>>>>>>>> Jérémy >>>>>>>>> >>>>>>>>>> Le 5 août 2020 à 00:04, Hugi Thordarson via Webobjects-dev >>>>>>>>>> <webobjects-dev@lists.apple.com >>>>>>>>>> <mailto:webobjects-dev@lists.apple.com>> a écrit : >>>>>>>>>> >>>>>>>>>> Never. Uptime on my apps is usually weeks or months. >>>>>>>>>> >>>>>>>>>> Cycled regularly when I used EOF though. That thing leaks. >>>>>>>>>> >>>>>>>>>> - hugi >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On 4 Aug 2020, at 21:31, Aaron Rosenzweig via Webobjects-dev >>>>>>>>>>> <webobjects-dev@lists.apple.com >>>>>>>>>>> <mailto:webobjects-dev@lists.apple.com>> wrote: >>>>>>>>>>> >>>>>>>>>>> Personally I feel better bouncing my .woa instances daily. Even if >>>>>>>>>>> it is a small site I have at least two instances and I gracefully >>>>>>>>>>> cycle them on a daily schedule. I feel better knowing that it is >>>>>>>>>>> fresh every morning for the new day. >>>>>>>>>>> >>>>>>>>>>> On the other hand, I could see an argument that a java app >>>>>>>>>>> shouldn’t have any memory leaks. The garbage collector should get >>>>>>>>>>> everything. If it cannot do so, then you’ve got something messed up >>>>>>>>>>> in your app that you should track down and rectify. So maybe it’s >>>>>>>>>>> better to just leave your .woa instances running forever until the >>>>>>>>>>> next redeployment to get new features. >>>>>>>>>>> >>>>>>>>>>> What does the community do? Do you cycle often (daily, twice per >>>>>>>>>>> day, or once per week) or do you leaving your instances running >>>>>>>>>>> without a scheduled restart? >>>>>>>>>>> >>>>>>>>>>> Thanks to all those who chime in :-) >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Do not post admin requests to the list. They will be ignored. >>>>>>>>>>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com >>>>>>>>>>> <mailto:Webobjects-dev@lists.apple.com>) >>>>>>>>>>> Help/Unsubscribe/Update your Subscription: >>>>>>>>>>> https://lists.apple.com/mailman/options/webobjects-dev/hugi%40karlmenn.is >>>>>>>>>>> >>>>>>>>>>> <https://lists.apple.com/mailman/options/webobjects-dev/hugi%40karlmenn.is> >>>>>>>>>>> >>>>>>>>>>> This email sent to h...@karlmenn.is <mailto:h...@karlmenn.is> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Do not post admin requests to the list. They will be ignored. >>>>>>>>>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com >>>>>>>>>> <mailto:Webobjects-dev@lists.apple.com>) >>>>>>>>>> Help/Unsubscribe/Update your Subscription: >>>>>>>>>> https://lists.apple.com/mailman/options/webobjects-dev/jeremy.deroyer%40ingencys.net >>>>>>>>>> >>>>>>>>>> <https://lists.apple.com/mailman/options/webobjects-dev/jeremy.deroyer%40ingencys.net> >>>>>>>>>> >>>>>>>>>> This email sent to jeremy.dero...@ingencys.net >>>>>>>>>> <mailto:jeremy.dero...@ingencys.net> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Do not post admin requests to the list. They will be ignored. >>>>>>>>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com >>>>>>>>> <mailto:Webobjects-dev@lists.apple.com>) >>>>>>>>> Help/Unsubscribe/Update your Subscription: >>>>>>>>> https://lists.apple.com/mailman/options/webobjects-dev/jtayler%40oeinc.com >>>>>>>>> >>>>>>>>> <https://lists.apple.com/mailman/options/webobjects-dev/jtayler%40oeinc.com> >>>>>>>>> >>>>>>>>> This email sent to jtay...@oeinc.com <mailto:jtay...@oeinc.com> >>>>>>>> _______________________________________________ >>>>>>>> Do not post admin requests to the list. They will be ignored. >>>>>>>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com >>>>>>>> <mailto:Webobjects-dev@lists.apple.com>) >>>>>>>> Help/Unsubscribe/Update your Subscription: >>>>>>>> https://lists.apple.com/mailman/options/webobjects-dev/kenlists%40anderhome.com >>>>>>>> >>>>>>>> <https://lists.apple.com/mailman/options/webobjects-dev/kenlists%40anderhome.com> >>>>>>>> >>>>>>>> This email sent to kenli...@anderhome.com >>>>>>>> <mailto:kenli...@anderhome.com> >>>>>>> _______________________________________________ >>>>>>> Do not post admin requests to the list. They will be ignored. >>>>>>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com >>>>>>> <mailto:Webobjects-dev@lists.apple.com>) >>>>>>> Help/Unsubscribe/Update your Subscription: >>>>>>> https://lists.apple.com/mailman/options/webobjects-dev/tedpet5%40yahoo.com >>>>>>> >>>>>>> <https://lists.apple.com/mailman/options/webobjects-dev/tedpet5%40yahoo.com> >>>>>>> >>>>>>> This email sent to tedp...@yahoo.com <mailto:tedp...@yahoo.com> >>>>>> _______________________________________________ >>>>>> Do not post admin requests to the list. They will be ignored. >>>>>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com >>>>>> <mailto:Webobjects-dev@lists.apple.com>) >>>>>> Help/Unsubscribe/Update your Subscription: >>>>>> https://lists.apple.com/mailman/options/webobjects-dev/lon.varscsak%40gmail.com >>>>>> >>>>>> <https://lists.apple.com/mailman/options/webobjects-dev/lon.varscsak%40gmail.com> >>>>>> >>>>>> This email sent to lon.varsc...@gmail.com <mailto:lon.varsc...@gmail.com> >>>>>> _______________________________________________ >>>>>> Do not post admin requests to the list. They will be ignored. >>>>>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com >>>>>> <mailto:Webobjects-dev@lists.apple.com>) >>>>>> Help/Unsubscribe/Update your Subscription: >>>>>> https://lists.apple.com/mailman/options/webobjects-dev/tim%40triptera.com.au >>>>>> >>>>>> <https://lists.apple.com/mailman/options/webobjects-dev/tim%40triptera.com.au> >>>>>> >>>>>> This email sent to t...@triptera.com.au <mailto:t...@triptera.com.au> >>>>> >>>>> _______________________________________________ >>>>> Do not post admin requests to the list. They will be ignored. >>>>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com >>>>> <mailto:Webobjects-dev@lists.apple.com>) >>>>> Help/Unsubscribe/Update your Subscription: >>>>> https://lists.apple.com/mailman/options/webobjects-dev/stefan.gaertner%40nureg.de >>>>> >>>>> <https://lists.apple.com/mailman/options/webobjects-dev/stefan.gaertner%40nureg.de> >>>>> >>>>> This email sent to stefan.gaert...@nureg.de >>>>> <mailto:stefan.gaert...@nureg.de> >>>> >>>> >>>> >>>> -- >>>> Mit freundlichen Grüßen >>>> >>>> Stefan Gärtner >>>> /// IT/Software-Entwicklung /// >>>> >>>> NUREG GmbH /// >>>> Dorfäckerstraße 31 | 90427 Nürnberg | Germany >>>> Tel.: +49-911-32002-183 | Fax: +49-911-32002-299 >>>> Nürnberg HRB 22653 | USt.ID DE 814 685 653 >>>> Geschäftsführer: Michael Schmidt, Stefan Boas >>>> www.nureg.de <http://www.nureg.de/> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Do not post admin requests to the list. They will be ignored. >>>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com >>>> <mailto:Webobjects-dev@lists.apple.com>) >>>> Help/Unsubscribe/Update your Subscription: >>>> https://lists.apple.com/mailman/options/webobjects-dev/hugi%40karlmenn.is >>>> <https://lists.apple.com/mailman/options/webobjects-dev/hugi%40karlmenn.is> >>>> >>>> This email sent to h...@karlmenn.is <mailto:h...@karlmenn.is> >>> >>> _______________________________________________ >>> Do not post admin requests to the list. They will be ignored. >>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com >>> <mailto:Webobjects-dev@lists.apple.com>) >>> Help/Unsubscribe/Update your Subscription: >>> https://lists.apple.com/mailman/options/webobjects-dev/aaron%40chatnbike.com >>> >>> <https://lists.apple.com/mailman/options/webobjects-dev/aaron%40chatnbike.com> >>> >>> This email sent to aa...@chatnbike.com <mailto:aa...@chatnbike.com> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com >> <mailto:Webobjects-dev@lists.apple.com>) >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/webobjects-dev/johann.werner%40posteo.de >> >> <https://lists.apple.com/mailman/options/webobjects-dev/johann.werner%40posteo.de> >> >> This email sent to johann.wer...@posteo.de <mailto:johann.wer...@posteo.de>
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
