"New features in JGroups 2.5" is an article by Vladimir Blagojevic addressing changes introduced in JGroups 2.5. JGroups is a toolkit for the development of distributed Java applications based on group communication; changes include support for virtual synchrony, the concurrent stack, and the improved multiplexer.

Virtual synchrony is a model of group communication defined by Ken Birman. First of all, virtual synchrony guarantees that group membership changes are observed in the same order by all the surviving group members. Moreover, virtual synchrony guarantees that two members observing the same two consecutive membership changes are guaranteed to receive the same set of application multicast messages between the two membership changes. Note that we are not concerned about particular order of application multicast messages between two consecutive membership changes. Virtual synchrony is only concerned that the same set of application messages is received by all surviving group members and that membership changes are totally ordered with respect to application messages. Clustered application using virtual synchrony model will have an appearance that group members observe the same events and in the same order – virtually synchronous order.

Some credit should be given to where these features originated a while back :) http://tomcat.apache.org/tomcat-6.0-doc/tribes/introduction.html#Feature%20Overview The concurrent stack was one of the main reasons I wrote tribes, cause no other framework had it. As for multiplexing channels, that is still a limitation in Jgroups, if you look at tribes, I can have a per-message configuration, allowing almost unlimited permutations of how messages are sent and delivered. Great work, look forward to see what 3.0 brings to the table Filip

The concurrent stack was one of the main reasons I wrote tribes, cause no other framework had it.

That's lame. Every ORB or multithreaded server (think app server) has a concurrent stack in some form or shape. With group communication it's a bit more tricky, as you have to make sure you don't mess up the ordering guarantees provided by the stack.

As for multiplexing channels, that is still a limitation in JGroups, if you look at tribes, I can have a per-message configuration, allowing almost unlimited permutations of how messages are sent and delivered.

What is the limitation ? Having a simple programming model that everyone understands ? Versus a *possibly* more powerful but easy to screw up model where you define properties per message ? Without knowing the details, I can imagine it would be hard to send message M1 with FIFO, M2 with total order and M3 with causal order (M1,2,3 from the same sender). We have actually introduced minimal per-message ordering 'overrides' in the form of out-of-band or priority messages. Bela

but we are not talking about appservers, we are talking about groupcom frameworks, and jgroups as part of them. yet, with Tribes this is fully possible, since Tribes supports parallel messaging. Tribes goes beyond concurrent stack, it goes onto parallel message sending and delivery interesting, that means Tribes must be really lame, we'll I'm a lame kind of guy :) and I'm glad I could help out, that's all I wanted :)

interesting, that means Tribes must be really lame, we'll I'm a lame kind of guy :) and I'm glad I could help out, that's all I wanted :)

Don't worry about it. He's from JBoss and they like dissing anybody else's ideas/work claiming that they thought of it all before the world was created.

Don't worry about it. He's from JBoss and they like dissing anybody else's ideas/work claiming that they thought of it all before the world was created.

Funny, but worth mentioning, when Tribes was created, we got an email accusing us of stealing ideas from JGroups, I think we now have a chicken or the egg problem going on. Not so funny, and very unfortunate, the proclaimed email pretty much ruined a good friendship, as the email was from Bela to me, but signed as it was backed by JBoss. I guess that's why we like the ASF, a much more liberal view on software development. (from my personal understanding)

Don't worry about it. He's from JBoss ..

Funny, but worth mentioning, when Tribes was created, we got an email accusing us of stealing ideas from JGroups ..

That's OK .. all of these "new" features have been in TCMP (the protocol that Coherence uses) for a while ;-) Peace, Cameron Purdy Oracle Coherence: The Java Data Grid

Where can I download TCMP and look at the src code to verify your claims Cameron ? :-) Still plugger-in-chief for Coherance at ORCL ? Bela

Where can I download TCMP and look at the src code to verify your claims Cameron ? :-)

I just get it off our Perforce server .. somehow I don't think that it will be open sourced any time soon, though ..

Still plugger-in-chief for Coherance at ORCL ?

Yes, I suppose so. ;-) Peace, Cameron Purdy Oracle Coherence: The Java Data Grid

The ordering of membership events and messages is a great addition and comes extremely useful in distributed computing environments. In distributed environments there is always a window when Node1 has discovered Node2 but Node2 has not discovered Node1. As an example, a product such as GridGain has to constantly watch out for such windows and make sure that overall execution is not affected. Having this resolved at communication layer should let the grid react to topology changes in a more symmetric and balanced way. Best, Dmitriy GridGain - Grid Computing Made Easy

sohbetim mirc muhabbet Sohbet Sitesi Chat Sohpet Sohbet ISO 9001 Teşvik Belgesi Çocuk Bezi Makyaj Malzemeleri Kişisel Bakım Dudak Koruyucu Göz Kalemi Diyet Ürünleri Süper Site driver Güvenlik Kamerası Islak Mendil Kolonyalı Mendil Kolonyalı Mendil JoyTurk driver ara web tasarım