This is definitely great stuff. Thanks Johann! Schrag once got into the same topic area starting with the magic of WOSwitchComponent.
https://lists.apple.com/archives/webobjects-dev/2008/Oct/msg00501.html <https://lists.apple.com/archives/webobjects-dev/2008/Oct/msg00501.html> I also only bounce when deploying a new build. Tim UCLA GSE&IS > On Aug 8, 2020, at 9:31 PM, Aaron Rosenzweig via Webobjects-dev > <webobjects-dev@lists.apple.com> wrote: > > 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 >> <mailto: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/lists%40thetimmy.com > > This email sent to li...@thetimmy.com
_______________________________________________ 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
