Re: Looks like an OSC must be disposed manually?!? (was: background tasks locked, workers run all right)
Re: Looks like an OSC must be disposed manually?!? (was: background tasks locked, workers run all right)
- Subject: Re: Looks like an OSC must be disposed manually?!? (was: background tasks locked, workers run all right)
- From: Aaron Rosenzweig via Webobjects-dev <email@hidden>
- Date: Mon, 29 Jun 2020 10:17:00 -0400
OSC is a cursor to the DB. They aren’t particularly cheap to acquire. As far as
I know, they live until you dispose of them. They don’t automatically dispose.
They are not cheap like an editingContext. One OSC can service a plethora of
editingContexts. Simple WOApps have two OSC for the life of the WOApp:
#1 made for the JDBCInfo, kind of dumb to keep around, Wonder has calls to
close this one.
#2 stays around and used for any new editing context you make where you don’t
specifically give it a new OSC.
AARON ROSENZWEIG / Chat 'n Bike <http://www.chatnbike.com/>
e: email@hidden <mailto:email@hidden> t: (301) 956-2319
> On Jun 29, 2020, at 10:12 AM, ocs--- via Webobjects-dev
> <email@hidden> wrote:
>
> Hi there,
>
> it seems finally I succeeded to find the culprit of the problem described
> below. Far as my testing shows, it seems an ObjectStoreCoordinator is never
> garbage collected (presumed it has been used at least once for a fetch).
> Since the OSC opens a socket to the database, this leads to the problem with
> a number of open sockets for a process. Far as my testing shows, the only way
> to make it to do poof is to call dispose manually, which seems a bit at the
> unexpected side, at least for me.
>
> My current test code looks like this:
>
> ===
> class MainPage extends OCSComponent {
> def test {
> def osc=new OCSOSC(),ec=new OCSEC(osc)
> println "created $osc and $ec"
> def obj=EOUtilities.objectWithPrimaryKeyValue(ec,'DBAuction',1000001)
> //[FETCH]
> println "got obj $obj and dying..."
> ec=nil
> osc.dispose() //[WHATTHE]
> osc=nil
> System.gc()
> nil
> }
> }
> class OCSOSC extends EOObjectStoreCoordinator {
> void finalize() {
> println "### $this about to die"
> }
> }
> @InheritConstructors class OCSEC extends ERXEC {
> void finalize() {
> println "### $this about to die"
> }
> }
> ===
>
> If both the lines marked [FETCH] and [WHATTHE] above are commented out, i.e.,
> if the OSC never fetches, both the osc and ec objects report finalizing
> without a need to dispose.
>
> Nevertheless, once the fetch happens as above, [WHATTHE] must be active too —
> otherwise only ec gets garbage collected; osc never ever does (and
> subsequently also never releases its DB socket).
>
> Well the explicit dispose seems to be the fix for my problem, so far it seems
> to work properly; but since I did not find any mention of calling dispose
> manually nor using a dispose registry in the documentation (otherwise than
> those two registries related to archivation and D2JClient), I wonder whether
> this is the proper approach, or whether I am doing something wrong and sooner
> or later I am in for an ugly surprise? Any insight here?
>
> Thanks a lot,
> OC
>
>> On 21. 5. 2020, at 1:13 PM, OCsite <email@hidden <mailto:email@hidden>> wrote:
>>
>> Hi there,
>>
>> bumped lately into another weird problem. We import some data into DB in
>> background tasks. Up to yesterday, it worked normally; today six import
>> tasks were launched, and each of them seemingly hang in its first DB
>> operation. Restart did help; alas, the site admins did not try to ask JVM to
>> detect deadlocks when they restarted the application.
>>
>> The background task looks like this:
>>
>> ===
>> class ImportCSVTask extends ERXLongResponseTask.DefaultImplementation {
>> def performAction {
>> _thread.priority=Thread.MIN_PRIORITY
>> try {
>> try {
>> editingContext=ERXEC.newEditingContext(objectStore=new
>> EOObjectStoreCoordinator())
>> editingContext.lock()
>> lognow 1, "=== preparing CSV import in EC $editingContext
>> ==="
>>
>> formPrototype=ERXEOGlobalIDUtilities.fetchObjectWithGlobalID(editingContext,formPrototypeGID)
>> lognow 1, "=== local prototype $formPrototype ==="
>> ... ...
>> ===
>>
>> Always the “preparing” log was the last thing those threads presented; none
>> of them ever reported “local prototype”. There's no other related log in
>> there.
>>
>> Meantime the application ran normally and the worker tasks communicated with
>> the database all right (with an occasional report that some select took
>> 70-odd ms from ERXAdaptorChannelDelegate, we have the threshold at 50). We
>> run with ERXObjectStoreCoordinatorPool.maxCoordinators=1.
>>
>> Any idea what could have gone wrong and how to find the culprit and prevent
>> the problem in future? I thought a new EC in a new OSC can't be blocked for
>> long, but self-evidently, I was wrong, they seemed to lock indefinitely
>> (application was restarted ten-odd hours after the first import hanged after
>> its “preparing” report, still no “local prototype”).
>>
>> 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