Re: background tasks locked, workers run all right
Re: background tasks locked, workers run all right
- Subject: Re: background tasks locked, workers run all right
- From: Aaron Rosenzweig via Webobjects-dev <email@hidden>
- Date: Thu, 21 May 2020 11:30:14 -0400
Hi OC,
It looks like you are mixing a couple things.
If you are going to use Kieran’s code (I believe it was him initially) you
should use it fully and have a healthy number of coordinators. I say that
because his code does round robin and there is a chance that two threads get
the same coordinator under heavy load so you better stock up on them. Think of
each coordinator as a single cursor to the DB.
For some reason you are telling Kieran’s code to only have one coordinator.
Then, on top of that, you make your own coordinator each time. It’s like
crossing the beams in Ghostbusters. Go one way, or the other, don’t mix.
There is something to be said about rolling your own and ensuring every thread
has their own coordinator and then you don’t even need to lock. You would also
want a queuing mechanism so that you don’t create too many coordinators. If you
are are not going to do that and want the easy button, embrace Kieran’s code
fully by making a large pool and letting his code give you an EC to work with.
Think about how many people you expect to be using a long running task
concurrently and at least double that number for your pool size. Don’t forget
to send him some Red Breast Whiskey.
AARON ROSENZWEIG / Chat 'n Bike <http://www.chatnbike.com/>
e: email@hidden <mailto:email@hidden> t: (301) 956-2319
> On May 21, 2020, at 7:13 AM, OCsite via Webobjects-dev
> <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