Hello, all, here’s a plain text version of my previous email, in case anybody
had trouble reading it.
I created this subclass to keep EOF in sync within a single java VM:
/**
* Keeps EOF in sync within a single java VM.
*
* Wonder's ProcessChangesQueue seems to takes care of keeping
* in sync EOF stacks used in other threads.
*/
public class LocalSynchronizer extends ERXRemoteSynchronizer {
public LocalSynchronizer(IChangeListener listener) {
super(listener);
}
@Override
public void join() throws Throwable { }
@Override
public void leave() throws Throwable { }
@Override
public void listen() throws Throwable { }
@Override
protected void _writeCacheChanges(int transactionID, NSArray<CacheChange>
cacheChanges) throws Throwable
{
// Nothing to write to the group
}
}
To use it you use these properties:
# Synchronization across EOF stacks (single VM)
#
# NOTE: The maxCoordinator property is needed to trigger the of
# initialization the synchronizer.
#
er.extensions.ERXObjectStoreCoordinatorPool.maxCoordinators=1
er.extensions.remoteSynchronizer.enabled=true
er.extensions.remoteSynchronizer=com.mpv.eof.LocalSynchronizer
Notice that the properties to specify which entities to include / exclude is
not needed as the filtering of changes by entity seems to be used only when
deciding which changes to send to remote instances.
Thank you
Ricardo J. Parada
> On Mar 25, 2022, at 5:03 PM, Ricardo Parada via Webobjects-dev
> <webobjects-dev@lists.apple.com> wrote:
>
>
> By the way, here’s a synchronizer subclass I wrote to keep changes in sync
> within a single java VM.
>
>
> /**
> * Keeps EOF in sync within a single java VM.
> *
> * Wonder's ProcessChangesQueue seems to takes care of keeping
> * in sync EOF stacks used in other threads.
> */
> public class LocalSynchronizer extends ERXRemoteSynchronizer {
>
> public LocalSynchronizer(IChangeListener listener) {
> super(listener);
> }
>
> @Override
> public void join() throws Throwable { }
>
> @Override
> public void leave() throws Throwable { }
>
> @Override
> public void listen() throws Throwable { }
>
> @Override
> protected void _writeCacheChanges(int transactionID, NSArray<CacheChange>
> cacheChanges) throws Throwable
> {
> // Nothing to write to the group
> }
> }
>
> To use it you use these properties:
>
> # Synchronization across EOF stacks (single VM)
> #
> # NOTE: The maxCoordinator property is needed to trigger the of
> # initialization the synchronizer.
> #
> er.extensions.ERXObjectStoreCoordinatorPool.maxCoordinators=1
> er.extensions.remoteSynchronizer.enabled=true
> er.extensions.remoteSynchronizer=com.mpv.eof.LocalSynchronizer
>
> Notice that the properties to specify which entities to include / exclude is
> not needed as the filtering of changes by entity seems to be used only when
> deciding which changes to send to remote instances.
>
> Thank you
> Ricardo J. Parada
>
>
>> On Mar 25, 2022, at 4:49 PM, Ricardo Parada via Webobjects-dev
>> <webobjects-dev@lists.apple.com <mailto:webobjects-dev@lists.apple.com>>
>> wrote:
>>
>> Thank you all for the responses.
>>
>> When we put the ERJGroupsSynchronizer in production we started receiving
>> reports of users not being able to access the application instances or
>> getting kicked out of the application. I do not know if the
>> ERJGroupsSynchronizer is the one to blame. So I think it would be unfair to
>> blame the problem on ERJGroupsSynchronizer.
>>
>> We just noticed the these warnings in the console and the first thing we
>> tried was to disable the synchronizer and the problem seems like it
>> disappeared after we did that.
>>
>> Mar 11, 2022 12:14:10 AM org.jgroups.protocols.UDP setBufferSize
>> WARNING: JGRP000015: the send buffer of socket MulticastSocket was set to
>> 5MB, but the OS only allocated 212.99KB. This might lead to performance
>> problems. Please set your max send buffer in the OS correctly (e.g.
>> net.core.wmem_max on Linux)
>>
>> This seems like it could be fixed by increasing the max send buffer on the
>> servers.
>>
>> The testers in our UAT environment noticed the following warnings:
>>
>> WARNING: JGRP000012: discarded message from different cluster
>> UATClaimScrubber (our cluster is UATContractManager). Sender was
>> f677bf19-c5e7-a69e-2000-97638a06f579 (received 4 identical messages from
>> f677bf19-c5e7-a69e-2000-97638a06f579 in the last 64665 ms)
>>
>> I think this just means that two different instances with a different
>> application name are using the same multicast address. Nothing really
>> harmful. This could probably be taken care of by setting the group name to
>> the same name on both.
>>
>> If I get any additional information I will post my findings.
>>
>> Thank you all,
>> Ricardo J. Parada
>>
>>
>>
>>
>>
>>> On Mar 21, 2022, at 11:28 AM, Steve Peery <spe...@icloud.com
>>> <mailto:spe...@icloud.com>> wrote:
>>>
>>> I’ve also been using it for years to synchronize instances.
>>>
>>> I’m not sure it is going to do what you want. You say you want to use it so
>>> you can update "without resorting to fetching”. I think the synchronization
>>> notifications simply pass the global IDs of the objects that have changed
>>> so they are refetched in the receiving instances.
>>>
>>> Steve
>>>
>>>
>>>
>>>> On Mar 20, 2022, at 6:21 PM, Paul Hoadley via Webobjects-dev
>>>> <webobjects-dev@lists.apple.com <mailto:webobjects-dev@lists.apple.com>>
>>>> wrote:
>>>>
>>>> Hi Ricardo,
>>>>
>>>> On 19 Mar 2022, at 14:25, Ricardo Parada via Webobjects-dev
>>>> <webobjects-dev@lists.apple.com <mailto:webobjects-dev@lists.apple.com>>
>>>> wrote:
>>>>
>>>>> Does anybody use ERJGroupsSynchronizer?
>>>>
>>>> We've been using it for years now, albeit with some light modifications to
>>>> allow JGroups to work on AWS (originally via the Meltmedia AWS_PING
>>>> project, but now via our own fork of that since it's essentially
>>>> abandonware).
>>>>
>>>>> I’m trying to synchronize two EOF stacks within a single VM. I don’t want
>>>>> the synchronization to happen across application instances.
>>>>>
>>>>> The video from Mike Shrag from a WOWODC conference said it can be single
>>>>> VM or across VM. I’m interested in the single VM but have not yet figured
>>>>> out how to do it.
>>>>>
>>>>> Basically, I have a background task doing work on a separate EOF stack
>>>>> and I want the changes to reflect on the EOF stack used by the user
>>>>> interface without resorting to fetching.
>>>>
>>>> Intra-JVM like that is not a configuration we've used. Can you walk us
>>>> through what you've tried and why you think it's not working? There have
>>>> been a few others using it over the years, maybe they're still on the list.
>>>>
>>>>
>>>> --
>>>> Paul Hoadley
>>>> https://logicsquad.net/ <https://logicsquad.net/>
>>>> https://www.linkedin.com/company/logic-squad/
>>>> <https://www.linkedin.com/company/logic-squad/>
>>>>
>>>> _______________________________________________
>>>> Do not post admin requests to the list. They will be ignored.
>>>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com
>>>> <mailto:Webobjects-dev@lists.apple.com>)
>>>> Help/Unsubscribe/Update your Subscription:
>>>> https://lists.apple.com/mailman/options/webobjects-dev/speery%40me.com
>>>> <https://lists.apple.com/mailman/options/webobjects-dev/speery%40me.com>
>>>>
>>>> This email sent to spe...@me.com <mailto:spe...@me.com>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com
>> <mailto:Webobjects-dev@lists.apple.com>)
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/webobjects-dev/rparada%40mac.com
>> <https://lists.apple.com/mailman/options/webobjects-dev/rparada%40mac.com>
>>
>> This email sent to rpar...@mac.com
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/webobjects-dev/rparada%40mac.com
>
> This email sent to rpar...@mac.com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
