tag:blogger.com,1999:blog-19835054.post6990527145811177984..comments2024-03-16T13:42:14.318+01:00Comments on Belas Blog: Shunning has been shunnedBela Banhttp://www.blogger.com/profile/01830789377474906550noreply@blogger.comBlogger8125tag:blogger.com,1999:blog-19835054.post-50726868820205848532009-10-04T09:44:31.237+02:002009-10-04T09:44:31.237+02:00Yes, every cluster will see traffic from different...Yes, every cluster will see traffic from different clusters running at the sam mcast_addr and mcast_port. They will discard it though but you´ll still see warnings in the logs...<br />Can't you preassign mcast addresses in your app ?<br />Other than that, your app could simply create random mcast addresses, so the chances of picking the same mcast address are small.<br />We do something similar for our unit tests, take a look at ResourceManager, which is part of JGroups to see how we allocate a range of mcast addressesBela Banhttps://www.blogger.com/profile/03832183909163653875noreply@blogger.comtag:blogger.com,1999:blog-19835054.post-79009130587928010032009-10-04T02:11:03.493+02:002009-10-04T02:11:03.493+02:00Bela,
I'm using JGroups to create Replicated...Bela,<br /><br />I'm using JGroups to create ReplicatedHashMaps in several bundles in an OSGi application. They all use the udp.xml configuration file. I assume that these will have issues with using the same mcast_addr value. If so, what is the best approach to setting values for the mcast_addr at run-time so that each ReplicatedHashMap has its own mcast_addr?Unknownhttps://www.blogger.com/profile/13864064832681457042noreply@blogger.comtag:blogger.com,1999:blog-19835054.post-55733114396006880072009-07-08T08:35:03.169+02:002009-07-08T08:35:03.169+02:00I'm afraid there is no simple one-fits-all sol...I'm afraid there is no simple one-fits-all solution to state merging;it always depends on the state at hand.<br /><br />I discuss some ways to handle state merging in section 5.6 of the manual: http://www.jgroups.org/manual/html/user-advanced.html#d0e2713 <br /><br />It all depends on whether the different partitions were allowed to progress, or whether (as described in 5.6.3) only the primary partition was allowed to make progress, and the others had to shut down or become read-only. In the latter case, on a merge everyone in a *non-primary* partition simply fetches the state from the primary partition (via Channel.getState()) and overwrites its own state and everything is fine.<br /><br />If we don't have primary partitions, and all partitions can have changes to the *same* data, then we could use timestamps. A timestamp is updated on a write, and on a merge, the data with the latest timestamp wins. This requires time synchronization, e.g. via NTP.<br /><br />Another mechanism (used. e.g. by Amazon Dynamo, google for the paper describing the mechanism), is to maintain version numbers per data element. A version is updated on a write. On a merge, data can be merged without conflict in some cases. If there are conflicts, however, they have to be handled by the application programmer ! The dev will get multiple data items back, each with a version history and then has to merge them back into one.<br />I hope this helps somewhat. Again, I cannot implement data merging in JGroups because it is highly dependent on your application. <br />However, one thing we want to do in JGroups/Infinispan/JBossAS is to provide a few data merge strategies to select from, that cover a number of app scenarios.Bela Banhttps://www.blogger.com/profile/01830789377474906550noreply@blogger.comtag:blogger.com,1999:blog-19835054.post-10435369518752109912009-07-08T05:28:54.941+02:002009-07-08T05:28:54.941+02:00I'm very keen to see how to handle the shared ...I'm very keen to see how to handle the shared state merging. Shunning and ensuring our state was correct has been our biggest problem using jGroupsAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-19835054.post-89577403653631751722009-07-03T09:52:47.817+02:002009-07-03T09:52:47.817+02:00Thanks a lot!Thanks a lot!Vatelhttps://www.blogger.com/profile/07049940821725217460noreply@blogger.comtag:blogger.com,1999:blog-19835054.post-58799647711818982382009-07-03T07:38:00.906+02:002009-07-03T07:38:00.906+02:00Actually, the changes are in GMS. I didn't hav...Actually, the changes are in GMS. I didn't have to add a new MERGE4 protocol, but simply changed MERGE2, MERGE3 and MERGEFAST.<br />Your existing config will work, but 'shun' has been deprecated, that's all.Bela Banhttps://www.blogger.com/profile/03832183909163653875noreply@blogger.comtag:blogger.com,1999:blog-19835054.post-43140395220652891702009-07-02T22:53:25.704+02:002009-07-02T22:53:25.704+02:00Bela, I do not see MERGE4 class in 2.8 beta, but I...Bela, I do not see MERGE4 class in 2.8 beta, but I see MERGE2 and MERGE3.<br />Where can I get it? Are there examples of stack configuration (TCP/UDP) with MERGE4?Vatelhttps://www.blogger.com/profile/07049940821725217460noreply@blogger.comtag:blogger.com,1999:blog-19835054.post-52065974109605381122009-06-18T16:22:59.946+02:002009-06-18T16:22:59.946+02:00OK, 2.8.0.Beta2 has now been uploaded to SourceFor...OK, 2.8.0.Beta2 has now been uploaded to SourceForge and can be downloaded here: http://sourceforge.net/project/showfiles.php?group_id=6081&package_id=94868&release_id=690750Bela Banhttps://www.blogger.com/profile/03832183909163653875noreply@blogger.com