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: Johann Werner via Webobjects-dev <email@hidden>
- Date: Sat, 8 Aug 2020 11:36:46 +0200
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>:
>
> 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