JGroups

Tim Fox wrote:
> Is it possible to install a MessageDispatcher and a Receiver on the same
> channel.

No, unless the channel is a MuxChannel, which you get as result of 
JChannelFactory.createMuxChannel. Then the dispatcher registers under a 
certain ID, and the Receiver under another. Check out 
http://www.jgroups.org/javagroupsnew/docs/manual/html/user-advanced.html#d0e2313 
for details


> I would like to use the same channel for both synchronous and 
> asynchronous messages.

Note that you can use the Dispatcher to do both anyway: castMessage() 
has a mode parameter, which can get GroupRequest.GET_ALL (block for all 
replies, minus the suspected ones) or GroupRequest.GET_NONE (wait for no 
replies), which is essentially asynchronous.


-- 
Bela Ban
Lead JGroups / Manager JBoss Clustering Group
JBoss - a division of Red Hat

Bela Ban wrote:
> 
> Tim Fox wrote:
> 
>>Is it possible to install a MessageDispatcher and a Receiver on the same
>>channel.
> 
> 
> No, unless the channel is a MuxChannel, which you get as result of 
> JChannelFactory.createMuxChannel. Then the dispatcher registers under a 
> certain ID, and the Receiver under another. Check out 
> http://www.jgroups.org/javagroupsnew/docs/manual/html/user-advanced.html#d0e2313 
> for details

I thought this was possible by specifying a MessageListener and a 
MembershipListener to the MessageDispatcher constructor. Then, messages 
that don't begin with the MessageDispatcher specific header (messages 
sent by Channel.send instead of using MessageDispatcher.castMessage or 
sendMessage) are handled by the specified MessageListener and 
MembershipListener

A receiver is both a MessageListener and a MembershipListener, so you 
get the same result.

perhaps it works only with the MessageDispatcher taking a Channel as 
parameter ?

Bela Ban wrote:

> Note that you can use the Dispatcher to do both anyway: castMessage() 
> has a mode parameter, which can get GroupRequest.GET_ALL (block for all 
> replies, minus the suspected ones) or GroupRequest.GET_NONE (wait for no 
> replies), which is essentially asynchronous.
> 

Ok, that's interesting.

Are there any performance implications of doing async sending this way 
as opposed to a straightforward send() ?

The use case I'm thinking of here is casting of unreliable messages to 
distributed topic peers in JBM, so we can expect a lot of traffic.

Hi,



probably this e-mail don't contribute with the question, but I have a doubt 
and this topic motivate me to write here.



I don't know how is the implementation (approach) to send synchronous 
messages on JGroups, but this property (synchrony) is not dependable of the 
environment (physical devices)?



My feeling is that you cannot implement synchronous channels if the physical 
channel is not guarantee timing bounds. Then, JGroups implementations in 
unpredictable networks never could be provide synchronous communication.

Maybe you should need clock synchronization, or some kind of information 
capable to represent the time notion in the distributed system.



Well, repeating, I don't know what is guaranteed and what are the 
assumptions in JGroups implementation of synchronous messages, but I ask if 
this is not dependable of the network used, for example?



Thank you,

Odorico Mendizabal





----- Original Message ----- 
From: "Tim Fox" <tim.fox@...>
To: <javagroups-users@...>
Cc: "Bela Ban" <belaban@...>
Sent: Monday, September 04, 2006 10:39 PM
Subject: Re: [javagroups-users] Asynchonrous and synchronous messages on 
same channel


>
>
> Bela Ban wrote:
>
>> Note that you can use the Dispatcher to do both anyway: castMessage()
>> has a mode parameter, which can get GroupRequest.GET_ALL (block for all
>> replies, minus the suspected ones) or GroupRequest.GET_NONE (wait for no
>> replies), which is essentially asynchronous.
>>
>
> Ok, that's interesting.
>
> Are there any performance implications of doing async sending this way
> as opposed to a straightforward send() ?
>
> The use case I'm thinking of here is casting of unreliable messages to
> distributed topic peers in JBM, so we can expect a lot of traffic.
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job 
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> javagroups-users mailing list
> javagroups-users@...
> https://lists.sourceforge.net/lists/listinfo/javagroups-users
>
>
> -- 
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.405 / Virus Database: 268.11.7/437 - Release Date: 4/9/2006
>
> 


		
_______________________________________________________ 
O Yahoo! está de cara nova. Venha conferir! 
http://br.yahoo.com

Tim Fox wrote:
>
> Bela Ban wrote:
>
>> Note that you can use the Dispatcher to do both anyway: castMessage()
>> has a mode parameter, which can get GroupRequest.GET_ALL (block for all
>> replies, minus the suspected ones) or GroupRequest.GET_NONE (wait for no
>> replies), which is essentially asynchronous.
>>
>
> Ok, that's interesting.
>
> Are there any performance implications of doing async sending this way
> as opposed to a straightforward send() ?

Yes:
- MessageDispatcher has to be prepared to match responses to requests, 
that's some overhead
- You want to install a Marshaller if you expect return values, 
otherwise we use simple&slow Java serialization
- Since you pass org.jgroups.Messages around, you want to 
marshal/unmarshal the buffer inside of those messages yourself, 
otherwise we again use Java serialization

> The use case I'm thinking of here is casting of unreliable messages to
> distributed topic peers in JBM, so we can expect a lot of traffic.

I would not use the MessageDispatcher here,  because you don't need 
correlation, simple Channel.send() will do I think

-- 
Bela Ban
Lead JGroups / Manager JBoss Clustering Group
JBoss - a division of Red Hat

By 'synchronous', we refer to fact that a caller blocks until all 
replies have been received. This is not the same definition you (I 
think) refer to.

Synchronicity can not be provided by a distributed system, that's why 
Virtual Synchrony was invented 
(http://www.jgroups.org/javagroupsnew/docs/presentations/Overview/HTML/img20.htm) 
by Ken Birman at Cornell.

Odorico Mendizabal wrote:
> Hi,
>
>
>
> probably this e-mail don't contribute with the question, but I have a doubt 
> and this topic motivate me to write here.
>
>
>
> I don't know how is the implementation (approach) to send synchronous 
> messages on JGroups, but this property (synchrony) is not dependable of the 
> environment (physical devices)?
>
>
>
> My feeling is that you cannot implement synchronous channels if the physical 
> channel is not guarantee timing bounds. Then, JGroups implementations in 
> unpredictable networks never could be provide synchronous communication.
>
> Maybe you should need clock synchronization, or some kind of information 
> capable to represent the time notion in the distributed system.
>
>
>
> Well, repeating, I don't know what is guaranteed and what are the 
> assumptions in JGroups implementation of synchronous messages, but I ask if 
> this is not dependable of the network used, for example?
>
>
>
> Thank you,
>
> Odorico Mendizabal
>
>
>
>
>
> ----- Original Message ----- 
> From: "Tim Fox" <tim.fox@...>
> To: <javagroups-users@...>
> Cc: "Bela Ban" <belaban@...>
> Sent: Monday, September 04, 2006 10:39 PM
> Subject: Re: [javagroups-users] Asynchonrous and synchronous messages on 
> same channel
>
>
>   
>> Bela Ban wrote:
>>
>>     
>>> Note that you can use the Dispatcher to do both anyway: castMessage()
>>> has a mode parameter, which can get GroupRequest.GET_ALL (block for all
>>> replies, minus the suspected ones) or GroupRequest.GET_NONE (wait for no
>>> replies), which is essentially asynchronous.
>>>
>>>       
>> Ok, that's interesting.
>>
>> Are there any performance implications of doing async sending this way
>> as opposed to a straightforward send() ?
>>
>> The use case I'm thinking of here is casting of unreliable messages to
>> distributed topic peers in JBM, so we can expect a lot of traffic.
>>
>> -------------------------------------------------------------------------
>> Using Tomcat but need to do more? Need to support web services, security?
>> Get stuff done quickly with pre-integrated technology to make your job 
>> easier
>> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>> _______________________________________________
>> javagroups-users mailing list
>> javagroups-users@...
>> https://lists.sourceforge.net/lists/listinfo/javagroups-users
>>
>>
>> -- 
>> No virus found in this incoming message.
>> Checked by AVG Free Edition.
>> Version: 7.1.405 / Virus Database: 268.11.7/437 - Release Date: 4/9/2006
>>
>>
>>     
>
>
> 		
> _______________________________________________________ 
> O Yahoo! está de cara nova. Venha conferir! 
> http://br.yahoo.com
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> javagroups-users mailing list
> javagroups-users@...
> https://lists.sourceforge.net/lists/listinfo/javagroups-users
>
>   

-- 
Bela Ban
Lead JGroups / Manager JBoss Clustering Group
JBoss - a division of Red Hat

Bela Ban wrote:

> Yes:
> - MessageDispatcher has to be prepared to match responses to requests, 
> that's some overhead
> - You want to install a Marshaller if you expect return values, 
> otherwise we use simple&slow Java serialization
> - Since you pass org.jgroups.Messages around, you want to 
> marshal/unmarshal the buffer inside of those messages yourself, 
> otherwise we again use Java serialization
> 
>> The use case I'm thinking of here is casting of unreliable messages to
>> distributed topic peers in JBM, so we can expect a lot of traffic.
> 
> I would not use the MessageDispatcher here,  because you don't need 
> correlation, simple Channel.send() will do I think
> 

Hmmm.. The more I think about, I can see that we certainly don't need to 
wait for responses (i.e. we don't need message dispatcher) when sending 
unreliable messages, but I'm not 100% sure for reliable messages.

When sending a reliable message to a topic, which has multiple 
subscriptions on different nodes, we persist the message if there are 
any durable subscriptions on the sending node, and then the message is 
cast across the group. So we already have the reliability guarantee 
before we cast the message.

If the stack configuration we use can give us a strong enough 
reliability guarantee then i don't think we need to wait for any return 
values to "be sure" the messsage reached the nodes.

There are some use cases where we do need return values - these are when 
sending "control messages" e.g. "a new subscription has been added to a 
topic" and each group member needs to know this.

Thoughts?

Perhaps we should move this discussion to the messaging design forum?

Tim Fox wrote:
>
> Hmmm.. The more I think about, I can see that we certainly don't need to
> wait for responses (i.e. we don't need message dispatcher) when sending
> unreliable messages, but I'm not 100% sure for reliable messages.
>
> When sending a reliable message to a topic, which has multiple
> subscriptions on different nodes, we persist the message if there are
> any durable subscriptions on the sending node, and then the message is
> cast across the group. So we already have the reliability guarantee
> before we cast the message.
>
> If the stack configuration we use can give us a strong enough
> reliability guarantee then i don't think we need to wait for any return
> values to "be sure" the messsage reached the nodes.

The stack essentially gives you the guarantee that a message will 
'eventually' reach all non-faulty members of a group. Which means, that 
if a member leaves (e.g. crashes) before it has received a message, it 
will never receive that message. If that message caused a modification 
to the shared group state, then the crashed member will get the state 
again when it re-joins, so that it has the same (shared) state as 
everyone else in the system. But there won't be any replaying of lost 
messages (a la persistent messages in JMS).

So when you publish to a JMS topic, don't you have the receivers send 
back acks for the received topics (similar to queues) ? If that's the 
case you probably need the MessageDispatcher, otherwise simply send 
messages via Channel.send()

-- 
Bela Ban
Lead JGroups / Manager JBoss Clustering Group
JBoss - a division of Red Hat

I'm not subscribed to that forum. But, yes, if this turns into a JBoss 
Messaging discussion, let's move it over to the JBM forum.

Tim Fox wrote:
> Perhaps we should move this discussion to the messaging design forum?

-- 
Bela Ban
Lead JGroups / Manager JBoss Clustering Group
JBoss - a division of Red Hat

> 
> So when you publish to a JMS topic, don't you have the receivers send 
> back acks for the received topics (similar to queues) ? If that's the 
> case you probably need the MessageDispatcher, otherwise simply send 
> messages via Channel.send()
> 

We used to do it that way, but not any more.

For persistent (reliable) messages, since we persist the message on the 
sending node before sending, then we don't need acks from the other 
members of the group, since if they crash they will reload the message 
from storage on restart - so it's not lost.

In JBM sometimes we need to cast a batch of messages across the group, 
e.g. on transaction commit when multiple messages have been sent in a 
transaction.

I can either do this by casting a different jgroups message for each jms 
message, or by casting a single jgroups message containing a list of the 
jms messages.

Can you think of any pros/cons of either approach. I'm thinking in terms 
of performance, overhead of a single jgroups message, message 
frag/defrag overhead etc?

TIA

I would send a single message, reason being that most of the time 
multiple messages can be serialized into a byte[] buffer (and placed 
into an org.jgroups.Message) more efficiently, than having to marshall 
each message separately

Tim Fox wrote:
> In JBM sometimes we need to cast a batch of messages across the group,
> e.g. on transaction commit when multiple messages have been sent in a
> transaction.
>
> I can either do this by casting a different jgroups message for each jms
> message, or by casting a single jgroups message containing a list of the
> jms messages.
>
> Can you think of any pros/cons of either approach. I'm thinking in terms
> of performance, overhead of a single jgroups message, message
> frag/defrag overhead etc?

-- 
Bela Ban
Lead JGroups / Manager JBoss Clustering Group
JBoss - a division of Red Hat