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: "Aaron Rosenzweig" Received: from mail-qv1-f51.google.com ([209.85.219.51] verified) by selbstdenker.ag (CommuniGate Pro SMTP 6.3.3) with ESMTPS id 25603454 for webobjects-dev@wocommunity.org; Sun, 21 Mar 2021 17:05:32 +0100 Received-SPF: none receiver=post.selbstdenker.com; client-ip=209.85.219.51; envelope-from=recurve@cocoanutstech.com Received: by mail-qv1-f51.google.com with SMTP id t16so7501598qvr.12 for ; Sun, 21 Mar 2021 09:05:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chatnbike.com; s=chatnbike; h=from:message-id:mime-version:date:subject:in-reply-to:to:references; bh=1HK0+U/34y4kJE+PpFW5nwjDZKUVOR2WGlgHN16yZQ4=; b=encZDjW5oMtaUtbk1x7uZZnMDBcRpgdmiRNfDB01DF6OrBLTsZcduyl1caPmjwi1hN ljMsEZbPhs/YT6+NdW3/q/sVX9PkzeZ5Vrf/LfSXfwUU6mx2oO9BMe6SiNqfoxvRjrHh gaUJO05Wgw8EyvCPjVuq0LhjuDQ/RmugnFcPA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:date:subject :in-reply-to:to:references; bh=1HK0+U/34y4kJE+PpFW5nwjDZKUVOR2WGlgHN16yZQ4=; b=kwzBBF6Uxz0FFz/ZCeRdFTuEsc/KurvWC4SKrEQZWRlgid96jUCgc44nwL8x7xHxep mkWB01g3Gl527GGrcv8yHts4VWGEdNaSLLtSITci/FWl5dm/UdfVTA3icpB/uAnoo9zx E5LT5RtXQpdoCK/wBAil46fJKFWEkviwys1pW75qdbPTcmox5l151aPoKMXdvOM7w9mt BGxbMp8clrEcFGTWWtTI+6x+gp4cLk54IM9YTsMA0QCbrgJPgNEAFC9XceY/uYjZOblW ZX18uYNl5U/A1THwQPqw3W6/WpHYCgVqlO4NzP3UL3WJgV7hFj/tclEETYHNUqzL5qyq 7OpQ== X-Gm-Message-State: AOAM532erItZcDclBbNoiZ3xqEC/5Ty6rKtds6ZsuNEMF9Hhl/9djGFq c1h/FB/wnOzqQWFDHV0Ao9SsWo4d1vsHfkNK X-Google-Smtp-Source: ABdhPJwi50cRay+qrSuKcn6qqpt9i89NKkq2i7wDoeBNJc2RwaL1ojtAvGbeSBJ2Pw7YEKoqucinTQ== X-Received: by 2002:a05:6214:1454:: with SMTP id b20mr17701486qvy.24.1616342710818; Sun, 21 Mar 2021 09:05:10 -0700 (PDT) Return-Path: Received: from mac-pro.home (pool-173-79-35-204.washdc.fios.verizon.net. [173.79.35.204]) by smtp.gmail.com with ESMTPSA id j15sm7365549qtr.34.2021.03.21.09.05.09 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 21 Mar 2021 09:05:10 -0700 (PDT) Message-Id: <7BA3D481-F254-4EEF-8EBC-2E00FF1E1E8F@chatnbike.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_C4253042-1EFD-4F36-9B69-646CA84AA158" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Sun, 21 Mar 2021 12:05:09 -0400 Subject: Re: [WO-DEV] ERXObjectStoreCoordinatorSynchronizer woes In-Reply-To: To: WebObjects & WOnder Development References: X-Mailer: Apple Mail (2.3654.60.0.2.21) --Apple-Mail=_C4253042-1EFD-4F36-9B69-646CA84AA158 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi OC,=20 Check to be sure your import task is only started after the app has = finished loading, not during the launch of the app. If you call too = early in the startup phase your ModelGroups, etc, may not be setup yet. = That=E2=80=99s what it sort of looks like from your stack trace because = you have a null pointer inside of EOModelGroup which is a NeXT/Apple = object, not even a WOnder one.=20 If you double check and are sure you don=E2=80=99t kick off a concurrent = thread before the app has finished loading=E2=80=A6 then I=E2=80=99m not = sure. You may have to revisit your use of the ERX messaging = coordinators. I=E2=80=99ve never used them so I don=E2=80=99t have = experience to share. =46rom where I stand they sound =E2=80=9Ccool=E2=80=9D= but I don=E2=80=99t get the use case. I get that people want = =E2=80=9Cfresh=E2=80=9D data and if every edit messages to all the other = ObjectStoreCoordinators then everybody is fresh all the time! Cool! but = at what cost? Does every instance need to fault in objects that people = may never see? If someone is editing the same data, and they get an = update from some other thread, what then? who wins? Chatter is expensive = on CPU / network too. Seems to me that if people want =E2=80=9Cfresh=E2=80= =9D then the best thing is to not sync but to get fresh data on the page = that you are at by setting the timestamp lag to something small like 2 = seconds. For a statistics page maybe avoid EOF altogether, use a direct = fetch of SQL.=20 > On Mar 21, 2021, at 12:01 AM, OCsite = wrote: >=20 > Hi there, >=20 > 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. >=20 > For a long long time it worked reliably and without a glitch. >=20 > Lately, it often (though by far not each time!) happens that >=20 > (i) a save in the background task reports the following exception: >=20 > =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 >=20 > (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. >=20 > =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 :/ ) >=20 > (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 >=20 > =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 >=20 > Any idea what might be the culprit and how to fix it? >=20 > Thanks and all the best, > OC >=20 --Apple-Mail=_C4253042-1EFD-4F36-9B69-646CA84AA158 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = OC, 

Check to = be sure your import task is only started after the app has finished = loading, not during the launch of the app. If you call too early in the = startup phase your ModelGroups, etc, may not be setup yet. That=E2=80=99s = what it sort of looks like from your stack trace because you have a null = pointer inside of EOModelGroup which is a NeXT/Apple object, not even a = WOnder one. 

If you double check and are sure you don=E2=80=99t kick off a = concurrent thread before the app has finished loading=E2=80=A6 then = I=E2=80=99m not sure. You may have to revisit your use of the ERX = messaging coordinators. I=E2=80=99ve never used them so I don=E2=80=99t = have experience to share. =46rom where I stand they sound =E2=80=9Ccool=E2= =80=9D but I don=E2=80=99t get the use case. I get that people want = =E2=80=9Cfresh=E2=80=9D data and if every edit messages to all the other = ObjectStoreCoordinators then everybody is fresh all the time! Cool! but = at what cost? Does every instance need to fault in objects that people = may never see? If someone is editing the same data, and they get an = update from some other thread, what then? who wins? Chatter is expensive = on CPU / network too. Seems to me that if people want =E2=80=9Cfresh=E2=80= =9D then the best thing is to not sync but to get fresh data on the page = that you are at by setting the timestamp lag to something small like 2 = seconds. For a statistics page maybe avoid EOF altogether, use a direct = fetch of SQL. 

On Mar 21, 2021, at 12:01 AM, OCsite <webobjects-dev@wocommunity.org> wrote:

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=_C4253042-1EFD-4F36-9B69-646CA84AA158--