X-CGP-ClamAV-Result: CLEAN X-VirusScanner: Niversoft's CGPClamav Helper v1.22.2a (ClamAV engine v0.102.2) X-Junk-Score: 0 [] X-KAS-Score: 0 [] From: "OCsite" Received: from smtp-beta-1.zoner.com ([217.198.120.68] verified) by post.selbstdenker.com (CommuniGate Pro SMTP 6.3.3) with ESMTPS id 25602212 for webobjects-dev@wocommunity.org; Sun, 21 Mar 2021 05:01:46 +0100 Received-SPF: none receiver=post.selbstdenker.com; client-ip=217.198.120.68; envelope-from=ocs@ocs.cz Received: from smtp.zoner.com (smtp.zoner.com [217.198.120.6]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp-beta-1.zoner.com (Postfix) with ESMTPS id 8CF28180030E for ; Sun, 21 Mar 2021 05:01:25 +0100 (CET) Received: from macbook-pro.ocsluj (unknown [77.240.103.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: ocs@ocs.cz) by smtp.zoner.com (Postfix) with ESMTPSA id 458753000068 for ; Sun, 21 Mar 2021 05:01:25 +0100 (CET) Content-Type: multipart/alternative; boundary="Apple-Mail=_266E12B9-69FD-48BE-9FCF-AD0779C235F8" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Subject: ERXObjectStoreCoordinatorSynchronizer woes Message-Id: Date: Sun, 21 Mar 2021 05:01:24 +0100 To: WebObjects & WOnder Development X-Mailer: Apple Mail (2.3608.120.23.2.4) --Apple-Mail=_266E12B9-69FD-48BE-9FCF-AD0779C235F8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi there, occasionally (not too often), we are running a background import task, = which uses its own EO stack: at launch, it creates a new = EOObjectStoreCoordinator (and for it it creates an ERXEC and uses it to = import data). When done and saved, the coordinator is disposed and = released. The rationale is that the imported data might be big and we = don't want to limit normal workers processing to wait until the import = saves its results into the database. For a long long time it worked reliably and without a glitch. Lately, it often (though by far not each time!) happens that (i) a save in the background task reports the following exception: =3D=3D=3D 04:38:38.600 ERROR java.lang.NullPointerException = //log:er.extensions.eof.ERXObjectStoreCoordinatorSynchronizer = [ERXOSCProcessChanges] NullPointerException at = com.webobjects.eoaccess.EOModelGroup.modelGroupForObjectStoreCoordinator(E= OModelGroup.java:795) at = er.extensions.eof.ERXEOAccessUtilities.databaseContextForEntityNamed(ERXEO= AccessUtilities.java:1086) at = er.extensions.eof.ERXObjectStoreCoordinatorSynchronizer$ProcessChangesQueu= e._process(ERXObjectStoreCoordinatorSynchronizer.java:509) at = er.extensions.eof.ERXObjectStoreCoordinatorSynchronizer$ProcessChangesQueu= e.process(ERXObjectStoreCoordinatorSynchronizer.java:540) at = er.extensions.eof.ERXObjectStoreCoordinatorSynchronizer$ProcessChangesQueu= e.run(ERXObjectStoreCoordinatorSynchronizer.java:617) ... skipped 1 stack elements =3D=3D=3D (ii) after that, usually no more exceptions are reported, but the = ERXObjectStoreCoordinatorSynchronizer does not seem to work properly = anymore, and it often happens that the changes done in the background = task are not visible in the main OSC for awhile. =46rom the user's perspective it usually means that the import is = finished, but the imported data is not visible for a long long time = (does not seem to be just a fetchTimestampLag, for newly logged-in users = with their new sessions and new ECs still don't see the imported data = for awhile. Frankly, I can't see what the H. might be the culprit :/ ) (iii) another problem which seems to be also caused (perhaps indirectly) = by the above exception is that the application cannot be normally quit = from JavaMonitor, reporting upon an attempt =3D=3D=3D 04:33:43.441 ERROR Exception caught: null ... ... IllegalStateException: Attempted to stop the ProcessChangesQueue when it = wasn't already running at = er.extensions.eof.ERXObjectStoreCoordinatorSynchronizer$ProcessChangesQueu= e.stop(ERXObjectStoreCoordinatorSynchronizer.java:637) at = er.extensions.eof.ERXObjectStoreCoordinatorSynchronizer.stopRemoteSynchron= izer(ERXObjectStoreCoordinatorSynchronizer.java:132) ... skipped 8 stack elements at = er.extensions.appserver.ERXApplication.terminate(ERXApplication.java:2861)= ... ... =3D=3D=3D Any idea what might be the culprit and how to fix it? Thanks and all the best, OC --Apple-Mail=_266E12B9-69FD-48BE-9FCF-AD0779C235F8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = there,

occasionally = (not too often), we are running a background import task, which uses its = own EO stack: at launch, it creates a new EOObjectStoreCoordinator (and for it it creates an ERXEC and uses it to import data). When done and saved, = the coordinator is disposed and released. The rationale is that the = imported data might be big and we don't want to limit normal workers = processing to wait until the import saves its results into the = database.

For = a long long time it worked reliably and without a glitch.

Lately, it often (though = by far not each time!) happens that

(i) a save in the background task = reports the following exception:

=3D=3D=3D
04:38:38.600 ERROR = java.lang.NullPointerException       = //log:er.extensions.eof.ERXObjectStoreCoordinatorSynchronizer = [ERXOSCProcessChanges]
NullPointerException
  = at = com.webobjects.eoaccess.EOModelGroup.modelGroupForObjectStoreCoordinator(E= OModelGroup.java:795)
  at = er.extensions.eof.ERXEOAccessUtilities.databaseContextForEntityNamed(ERXEO= AccessUtilities.java:1086)
  at = er.extensions.eof.ERXObjectStoreCoordinatorSynchronizer$ProcessChangesQueu= e._process(ERXObjectStoreCoordinatorSynchronizer.java:509)
  = at = er.extensions.eof.ERXObjectStoreCoordinatorSynchronizer$ProcessChangesQueu= e.process(ERXObjectStoreCoordinatorSynchronizer.java:540)  = at = er.extensions.eof.ERXObjectStoreCoordinatorSynchronizer$ProcessChangesQueu= e.run(ERXObjectStoreCoordinatorSynchronizer.java:617)
  = ... skipped 1 stack elements
=3D=3D=3D

(ii) after that, = usually no more exceptions are reported, but the ERXObjectStoreCoordinatorSynchronizer does not seem to = work properly anymore, and it often happens that the changes done in the = background task are not visible in the main OSC for awhile.

=46rom the user's = perspective it usually means that the import is finished, but the = imported data is not visible for a long long time (does not seem to be = just a fetchTimestampLag, for newly logged-in = users with their new sessions and new ECs still don't see the imported = data for awhile. Frankly, I can't see what the H. might be the culprit = :/ )

(iii) = another problem which seems to be also caused (perhaps indirectly) by = the above exception is that the application cannot be normally quit from = JavaMonitor, reporting upon an attempt

=3D=3D=3D
04:33:43.441 ERROR Exception caught: null
... ...
IllegalStateException: Attempted to stop the = ProcessChangesQueue when it wasn't already running
  = at = er.extensions.eof.ERXObjectStoreCoordinatorSynchronizer$ProcessChangesQueu= e.stop(ERXObjectStoreCoordinatorSynchronizer.java:637)
  = at = er.extensions.eof.ERXObjectStoreCoordinatorSynchronizer.stopRemoteSynchron= izer(ERXObjectStoreCoordinatorSynchronizer.java:132)
     ... skipped 8 stack = elements
  at = er.extensions.appserver.ERXApplication.terminate(ERXApplication.java:2861)=
... ...
=3D=3D=3D

Any idea what might be = the culprit and how to fix it?

Thanks and all the best,
OC

= --Apple-Mail=_266E12B9-69FD-48BE-9FCF-AD0779C235F8--