Re: How often do you bounce your apps?
Re: How often do you bounce your apps?
- Subject: Re: How often do you bounce your apps?
- From: Aaron Rosenzweig via Webobjects-dev <email@hidden>
- Date: Sun, 9 Aug 2020 00:31:55 -0400
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: email@hidden <mailto:email@hidden> t: (301) 956-2319
> On Aug 8, 2020, at 5:36 AM, Johann Werner <email@hidden> 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
>> <email@hidden <mailto:email@hidden>>:
>>
>> 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: email@hidden <mailto:email@hidden> t: (301) 956-2319
>>
>>
>>> On Aug 6, 2020, at 4:28 AM, Hugi Thordarson via Webobjects-dev
>>> <email@hidden <mailto:email@hidden>>
>>> 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
>>>> <email@hidden <mailto:email@hidden>>
>>>> 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
>>>>> <email@hidden <mailto:email@hidden>>:
>>>>>
>>>>> 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
>>>>>> <email@hidden <mailto:email@hidden>>
>>>>>> 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
>>>>>> <email@hidden <mailto:email@hidden>>
>>>>>> 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
>>>>>>> <email@hidden
>>>>>>> <mailto:email@hidden>> wrote:
>>>>>>>
>>>>>>> I never bounce them - even with EOF ;)
>>>>>>>
>>>>>>>> On Aug 5, 2020, at 07:07, Jesse Tayler via Webobjects-dev
>>>>>>>> <email@hidden
>>>>>>>> <mailto:email@hidden>> 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
>>>>>>>>> <email@hidden
>>>>>>>>> <mailto:email@hidden>> 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
>>>>>>>>>> <email@hidden
>>>>>>>>>> <mailto:email@hidden>> 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
>>>>>>>>>>> <email@hidden
>>>>>>>>>>> <mailto:email@hidden>> 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 (email@hidden
>>>>>>>>>>> <mailto:email@hidden>)
>>>>>>>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> This email sent to email@hidden <mailto:email@hidden>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Do not post admin requests to the list. They will be ignored.
>>>>>>>>>> Webobjects-dev mailing list (email@hidden
>>>>>>>>>> <mailto:email@hidden>)
>>>>>>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> This email sent to email@hidden
>>>>>>>>>> <mailto:email@hidden>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Do not post admin requests to the list. They will be ignored.
>>>>>>>>> Webobjects-dev mailing list (email@hidden
>>>>>>>>> <mailto:email@hidden>)
>>>>>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> This email sent to email@hidden <mailto:email@hidden>
>>>>>>>> _______________________________________________
>>>>>>>> Do not post admin requests to the list. They will be ignored.
>>>>>>>> Webobjects-dev mailing list (email@hidden
>>>>>>>> <mailto:email@hidden>)
>>>>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>>>>
>>>>>>>>
>>>>>>>> This email sent to email@hidden
>>>>>>>> <mailto:email@hidden>
>>>>>>> _______________________________________________
>>>>>>> Do not post admin requests to the list. They will be ignored.
>>>>>>> Webobjects-dev mailing list (email@hidden
>>>>>>> <mailto:email@hidden>)
>>>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>>>
>>>>>>>
>>>>>>> This email sent to email@hidden <mailto:email@hidden>
>>>>>> _______________________________________________
>>>>>> Do not post admin requests to the list. They will be ignored.
>>>>>> Webobjects-dev mailing list (email@hidden
>>>>>> <mailto:email@hidden>)
>>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>>
>>>>>>
>>>>>> This email sent to email@hidden <mailto:email@hidden>
>>>>>> _______________________________________________
>>>>>> Do not post admin requests to the list. They will be ignored.
>>>>>> Webobjects-dev mailing list (email@hidden
>>>>>> <mailto:email@hidden>)
>>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>>
>>>>>>
>>>>>> This email sent to email@hidden <mailto:email@hidden>
>>>>>
>>>>> _______________________________________________
>>>>> Do not post admin requests to the list. They will be ignored.
>>>>> Webobjects-dev mailing list (email@hidden
>>>>> <mailto:email@hidden>)
>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>
>>>>>
>>>>> This email sent to email@hidden
>>>>> <mailto:email@hidden>
>>>>
>>>>
>>>>
>>>> --
>>>> 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 (email@hidden
>>>> <mailto:email@hidden>)
>>>> Help/Unsubscribe/Update your Subscription:
>>>>
>>>> This email sent to email@hidden <mailto:email@hidden>
>>>
>>> _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Webobjects-dev mailing list (email@hidden
>>> <mailto:email@hidden>)
>>> Help/Unsubscribe/Update your Subscription:
>>>
>>>
>>> This email sent to email@hidden <mailto:email@hidden>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list (email@hidden
>> <mailto:email@hidden>)
>> Help/Unsubscribe/Update your Subscription:
>>
>>
>> This email sent to email@hidden <mailto:email@hidden>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden