Changes synchronized via jGroups won't always propagate on remote machines
Changes synchronized via jGroups won't always propagate on remote machines
- Subject: Changes synchronized via jGroups won't always propagate on remote machines
- From: René Bock <email@hidden>
- Date: Mon, 16 Jul 2018 13:34:48 +0000
- Thread-topic: Changes synchronized via jGroups won't always propagate on remote machines
Hi!
We are experiencing issues with the RemoteSynchronizer (on jGroups), if we use
more than one er.extensions.ERXObjectStoreCoordinatorPool.maxCoordinators (like
20). The synchronization between instances is working, changes are distributed
and fetched from the database, but they don't "push through" - if we read the
EO-Entity that should contain those changes, we're getting the same data as if
nothing was updated.
It seems to work most of the time if we create a new session: if we hit a new
WorkerThread we get the changes, if not we'll end up with the old data.
We tested it with two vastly different projects (also vastly different in age
of the product) and both suffer from the issue mentioned above.
We looked into the mechanics and wondered, why the following three lines are
present in processing of local changes
(ERXObjectStoreCoordinatorSynchronizer.ProcessChangesQueue.UpdateSnapshotProcessor.processSnapshots()),
but not in the remote-version of this
(ERXObjectStoreCoordinatorSynchronizer.ProcessChangesQueue.UpdateCacheChangeProcessor.processCacheChange()):
NSMutableDictionary userInfo = new NSMutableDictionary(gids,
EODatabaseContext.UpdatedKey);
userInfo.setObjectForKey(Boolean.TRUE,
ERXObjectStoreCoordinatorSynchronizer.SYNCHRONIZER_KEY);
NSNotificationCenter.defaultCenter().postNotification(EODatabaseContext.ObjectsChangedInStoreNotification,
dbc, userInfo);
We added those lines on the RemoteChanges-side and our issue was gone.
Our question is, if this could be a bug, or "if we are doing something wrong"
because no one ever faced those issues... :)
What would be the consequences if we add those three lines to the
UpdateCacheChangeProcessor (or wherever it'd be needed to process all kinds of
changes)?
Another question would be: Why is it working with only one
ObjectStoreCoordinator?
PS: Since we're using a WebSphere environment we can't use the usual "20
instances, one ObjectStore"-approach, we need to use many concurrent threads in
a single process. This issue is also occurring outside of WebSphere though (if
more than one ObjectStoreCoordinator is used with remote instances).
PPS: see also https://github.com/wocommunity/wonder/issues/866
Thanks a lot for your time!
Best regards
René Bock
--
Phone: +49 69 650096 18
salient GmbH, Lindleystraße 12, 60314 Frankfurt
Main: +49 69 65 00 96 0 | http://www.salient-doremus.de
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden