Re: weird locks in faultWithPrimaryKeyValue
Re: weird locks in faultWithPrimaryKeyValue
- Subject: Re: weird locks in faultWithPrimaryKeyValue
- From: Samuel Pelletier via Webobjects-dev <email@hidden>
- Date: Sat, 17 Aug 2024 08:42:00 -0400
Hi OC,
Last week, I spend some time to optimise an app after seeing strange behaviour,
the cpu usage of this app was growing with time with no logical explaination.
Your case sound similar to me so I share my experience on this.
During these high cpu usage period, the app had strange locking and No snapshot
for gid errors I did not understood. At >120% cpu usage, the app was getting
almost unusable. After a restart, everything went back to normal.
After spending some time in console, I noticed that the heap allocation was
growing and after some time, the app began to slow down. The VM was never doing
"old generation" gc probably because the heap was not used enough to trigger
it. After issuing a manual GC call (from console), the memory usage went down
and the cpu usage dropped also.
This problem was triggered by the addition of sensor logging in the system,
about 175k entries each day saved in the database by a rest controller action.
I suspect there is some weak reference usage inside EOF (probably for
snapshots) that remains until the more aggressive GC do it's job.
I solves my problem (at least it seems to works) with a periodic call to the
commands by scheduling a task every hour :
Runtime.getRuntime().gc();
Runtime.getRuntime().runFinalization();
I do not know if the second is required but it does not hurt.
Hope this can help someone,
Samuel
> Le 16 août 2024 à 12:14, ocs--- via Webobjects-dev
> <email@hidden> a écrit :
>
> Hi there,
>
> I've got a direct action, which sometimes needs to get an object with a known
> PK, for which I use faultWithPrimaryKeyValue. Works well for years, but
> lately the fetches went longer, so I decided to allow it to use a separate
> OSC not to clash with the normal database requests.
>
> The result is weird:
> - sometimes, faultWithPrimaryKeyValue in the dedicated OSC is lightning fast,
> as presumed
> - sometimes though, it never ends?!? :-O
>
> It does not lock once and then stay locked, the cases are intermittent. Also,
> it never locks when I test myself at my development machine; happens on the
> deployment site only, sigh. I have also reasons to believe that the DA does
> not deadlock with another thread (essentially since at the moment of the
> first lock, nothing at all ran in parallel).
>
> The code looks like this:
> ===
> static sharedosc
> WOActionResults someAction() {
> try {
> boolean oscpolicy=ERXProperties.booleanForKey('ActionSpecificOSC')
> def localec, osc
> ... ...
> for (... a couple of times ...) {
> ...
> if (some-condition-which-says-I-need-to-fetch) {
> if (!localec) {
> if (oscpolicy && !sharedosc) sharedosc=new
> ERXObjectStoreCoordinator(true)
>
> (localec=ERXEC.newEditingContext(sharedosc?:EOEditingContext.defaultParentObjectStore())).lock()
> // 1
> }
> log "/TEMP will fetch in $localec..." // 2
> eo=EOUtilities.faultWithPrimaryKeyValue(localec ,'DBAuction',
> Integer.valueOf(map.eoprimarykey))
> log "/TEMP ... did fetch in $localec"
> }
> ...
> }
> ... ...
> if (localec) localec.dispose()
> } catch (exc) {
> some-log-which-never-happens-thus-I-know-the-above-never-threw
> }
> }
> ===
>
> When ActionSpecificOSC is off, it never ever locks. When it is on though,
> occasionally the “will fetch” log marked // 2 is the very last thing which
> the appropriate worker thread ever does. In other (intermittent) cases it all
> works well.
>
> Aside of moving the localec.dispose to finally, which would be safer, but in
> this case irrelevant for no exception ever happens, can you perhaps see a
> possible culprit?
>
> Side question: originally, my // 1 line looked like
> (localec=ERXEC.newEditingContext(osc)).lock(). Far as I can say, should work
> precisely same way as the above, but did not: when the osc was null, I've got
> an invalid EC with a null rootObjectStore. What the H.?!?
>
> Thanks and all the best,
> OC
>
> _______________________________________________
> 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
_______________________________________________
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