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-2.zoner.com ([217.198.120.70] verified) by post.selbstdenker.com (CommuniGate Pro SMTP 6.3.3) with ESMTPS id 25637941 for webobjects-dev@wocommunity.org; Mon, 29 Mar 2021 01:48:11 +0200 Received-SPF: none receiver=post.selbstdenker.com; client-ip=217.198.120.70; 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-2.zoner.com (Postfix) with ESMTPS id 1D17E180012F; Mon, 29 Mar 2021 01:47:51 +0200 (CEST) Received: from ocbookpro.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 E74963000068; Mon, 29 Mar 2021 01:47:50 +0200 (CEST) Message-Id: <10DC1E30-B57D-48C5-87FF-9900EADC3640@ocs.cz> Content-Type: multipart/alternative; boundary="Apple-Mail=_9DA35D68-36F8-4CC0-B962-C396DA8724B4" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Mon, 29 Mar 2021 01:47:50 +0200 Subject: Re: [WO-DEV] ERXObjectStoreCoordinatorSynchronizer woes In-Reply-To: To: WebObjects & WOnder Development References: X-Mailer: Apple Mail (2.3608.120.23.2.4) --Apple-Mail=_9DA35D68-36F8-4CC0-B962-C396DA8724B4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Matthew, > On 28 Mar 2021, at 22:50, Matthew Ness = wrote: >>> On 24 Mar 2021, at 16:21, ocs@ocs.cz = > = wrote: >>> some followup to the problem quoted below. Eventually, I've found = the order of jars on classpath does not seem to be the culprit; the = problem seem to be caused by... >>>=20 >>>> On 21. 3. 2021, at 5:01 AM, OCsite > wrote: >>>> 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. >=20 > I don't have an answer to your specific EOObjectStoreCoordinator woes, = sorry. >=20 > Could you run your background task in a separate instance or machine? = For high resource background tasks that's what we do, running a = specialised instance on-demand, which uses JGroupsSync to coordinate = with other machines and instances when needed. Thanks! I sort of fear the problems might stay: they are not =E2=80=94 far as I = can say =E2=80=94 caused by the concurrence betwixt the import thread = and the workers, but rather by somewhat unpredictable moment when the = Coordinator's own thread bumps in and starts to coordinate. Which would = be needed anyway. I did a number of improvements meantime =E2=80=94 e.g., whilst I am, so = far, really not able to find why on earth sometimes the coordinator = throws the ObjectNotAvailableException for an object which does exist = and ever did, I've tried to alleviate the problem using the = tolerantEntityPattern to block the exception, whatever causes it. Seems = it helped, so far (touching wood ;)) If the worst comes to the worst, I guess we can switch off the = Coordinator completely and coordinate manually: we use background = threads with their own EO stacks pretty rarely and for a very small set = of well-defined operations (the aforementioned import, not-yet mentioned = pre-computing of some cached data, and that's all), and we never use = separate EO stacks for normal workers; thus a manual coordination would = not be too difficult. Thanks again and all the best, OC --Apple-Mail=_9DA35D68-36F8-4CC0-B962-C396DA8724B4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Matthew,

On 28 Mar 2021, at 22:50, Matthew Ness <webobjects-dev@wocommunity.org> wrote:
On 24 Mar 2021, at = 16:21, ocs@ocs.cz <webobjects-dev@wocommunity.org> wrote:
some followup to the problem quoted = below. Eventually, I've found the order of jars on classpath does not = seem to be the culprit; the problem seem to be caused by...

On 21. 3. 2021, at 5:01 AM, OCsite <webobjects-dev@wocommunity.org> wrote:
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.

I = don't have an answer to your specific EOObjectStoreCoordinator woes, = sorry.

Could you run your background = task in a separate instance or machine? For high resource background = tasks that's what we do, running a specialised instance on-demand, which = uses JGroupsSync to coordinate with other machines and instances when = needed.

Thanks!

I sort = of fear the problems might stay: they are not =E2=80=94 far as I can say = =E2=80=94 caused by the concurrence betwixt the import thread and the = workers, but rather by somewhat unpredictable moment when the = Coordinator's own thread bumps in and starts to coordinate. Which would = be needed anyway.

I did a number of = improvements meantime =E2=80=94 e.g., whilst I am, so far, really not = able to find why on earth sometimes the coordinator throws the ObjectNotAvailableException for an object which does = exist and ever did, I've tried to alleviate the problem using = the tolerantEntityPattern to block the exception, = whatever causes it. Seems it helped, so far (touching wood = ;))

If the worst comes to the worst, = I guess we can switch off the Coordinator completely and coordinate = manually: we use background threads with their own EO stacks pretty = rarely and for a very small set of well-defined operations (the = aforementioned import, not-yet mentioned pre-computing of some cached = data, and that's all), and we never use separate EO stacks for normal = workers; thus a manual coordination would not be too = difficult.

Thanks again and all the = best,
OC


= --Apple-Mail=_9DA35D68-36F8-4CC0-B962-C396DA8724B4--