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: "Matthew Ness" Received: from wout2-smtp.messagingengine.com ([64.147.123.25] verified) by post.selbstdenker.com (CommuniGate Pro SMTP 6.3.3) with ESMTPS id 25637604 for webobjects-dev@wocommunity.org; Sun, 28 Mar 2021 22:52:01 +0200 Received-SPF: none receiver=post.selbstdenker.com; client-ip=64.147.123.25; envelope-from=matt@logicsquad.net Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id CDDD715F4 for ; Sun, 28 Mar 2021 16:51:38 -0400 (EDT) Received: from imap10 ([10.202.2.60]) by compute4.internal (MEProxy); Sun, 28 Mar 2021 16:51:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=VAYXqH BiThSetUeXwXqCtkZ3uoK4sSAJ/V0rwTpTKao=; b=ARtrF97uRdPTSxxZP+hIgc B0PUrkFdQl4QJecuXXW3HsXtBpNvMMbQq/j6/RvWcjRDEPGwrmzoRyxQiCcDoABy pzt9+Im4a8DoSKVz2lW9QUezKWUUovUtOQmq+loeI5YFS5+tdhHSOCeOwnkb0fCn B+5FXMWX2ACWRpS2gT4Q014RhthMl2j6ZDz303mD69ZicEiwjSbNbMd4ssHvHONG GxunIkbD8/Yn4Xc32dTgcBmkTQxWPWCPOYRlUu4Imxs+uqtvKjqV57TKgrVEq7Tk WuiB5WE3Mw/DXOraABKm8oz/iGqgo/zZ1B0XTjzG2eM8qy0Ut3vKH3yN4iid7usw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudehiedgudehiecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrg dtreerreertdenucfhrhhomhepfdforghtthhhvgifucfpvghsshdfuceomhgrthhtsehl ohhgihgtshhquhgrugdrnhgvtheqnecuggftrfgrthhtvghrnhepjeelgeeuvdeigeekgf elieegudevvddugeeggedtffejhfegffeitefgffegteeinecuffhomhgrihhnpehlohhg ihgtshhquhgrugdrnhgvthdplhhinhhkvgguihhnrdgtohhmnecuvehluhhsthgvrhfuih iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgrthhtsehlohhgihgtshhquhgr ugdrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 2A2AF4E0504; Sun, 28 Mar 2021 16:51:38 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-273-g8500d2492d-fm-20210323.002-g8500d249 Mime-Version: 1.0 Message-Id: <02d92471-a2c2-440b-a25e-5edba2155868@www.fastmail.com> In-Reply-To: References: Date: Mon, 29 Mar 2021 07:50:37 +1100 To: wo-dev Subject: Re: [WO-DEV] Re: ERXObjectStoreCoordinatorSynchronizer woes Content-Type: multipart/alternative; boundary=1d3a3fde35af4c7f8031e64e85b6d97e --1d3a3fde35af4c7f8031e64e85b6d97e Content-Type: text/plain >> On 24 Mar 2021, at 16:21, ocs@ocs.cz wrote: >> >> Hi there, >> >> 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 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. Regards, -- Matt https://logicsquad.net https://www.linkedin.com/company/logic-squad/ --1d3a3fde35af4c7f8031e64e85b6d97e Content-Type: text/html Content-Transfer-Encoding: quoted-printable

On 24 Mar 2021, at 16:21, ocs@ocs.cz <webobjects-dev@wocommunity.org> wrote:

Hi there,

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 o= ften), we are running a background import task, which uses its own EO st= ack: at launch, it creates a new EOObjectStoreCoordinat= or (and for it it creates an ERXEC and uses it = to import data). When done and saved, the coordinator i= s disposed and released.


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

=
Could you run your background task in a separat= e 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.

Regards,

-- 
Matt
= https://logicsquad.net
<= div class=3D"signature">https://www.linkedin.com/company/logic-squad/


--1d3a3fde35af4c7f8031e64e85b6d97e--