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: ocs--- via Webobjects-dev <email@hidden>
- Date: Mon, 29 Jun 2020 16:26:04 +0200
Aaron,
thanks, this I hope I sort of understand.
Still, in the garbage-collected environment, any object, far as I can say,
should
(a) be automatically disposed when there's no explicit reference to it,
regardless of whether it is cheap or big;
(b) if there's some internal means to keep unreferenced objects alive forever,
it should be explicitly documented (e.g., like
EOObjectStoreCoordinator.defaultCoordinator()).
What am I overlooking? And, much more important question: is the explicitly
called dispose indeed the right and safe way to get rid of an OSC, wouldn't it
cause some other problems elsewhere in the future?
Thanks,
OC
> On 29. 6. 2020, at 4:17 PM, Aaron Rosenzweig <email@hidden> wrote:
>
> 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 <mailto: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
>> <mailto: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