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 (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
