Re: [jgroups-dev] How to implement/use flow control in JGroups

[email protected] wrote:
> Hi everyone, I must apologize first that my first post here is asking 
> for help. Â I also apologize if this is the wrong mailing list for 
> this type of question.
>
> I will keep introductions short in this post. Â Basically I am a 
> software developer working for a web/teleconferencing company. Â We 
> often have large web conferences which require multiple servers to 
> coordinate and share information. Â We have wanted to move to JGroups 
> as a possible solution to handle message passing, group membership, 
> and all the other love JGroups can offer.
>
> In order to do this, I am trying to create a layer just above JGroups 
> that we can use to run our application without the need to have the 
> application interface directly with JGroups. Â This has been a fairly 
> easy task, and I have been able to do it with one exception, flow 
> control....
>
> With the needs we have, we never want messages to be queued (or rather 
> have the queue be very very short).

This doesn't look like a flow control issue; more like an issue related 
to retransmission. E.g. if we receive P3, P4, P6, P7, then P's messages 
3 and 4 can be delivered to the application, but 6 and 7 have to be 
queued until P5 has been received, at which point P5-7 can be delivered.

So I understand you'd rather *not* receive P5 and instead deliver P6 and 
P7 immediately ?

> Â The reason being that a message waiting in queue may already be 
> outdated, and instead we would much rather just create a new message 
> that is more relevant for the time being. Â There are several ways to 
> implement this, but we have chosen:
> After a message is sent by JGroups, we call a "callback" which alerts 
> the application that we are now ready for more data. Â Then the 
> application gives us a new bit to send, we send it, and after that is 
> sent we call that messages callback, the cycle continues. This is more 
> ideal than blocking because if we have data ready to send, and it is 
> blocked, this means the data is going out of date while it is blocked. 
> If we are just alerted right when we can accept data, that gives us 
> the greatest chances of providing fresh and current information. (I 
> recognize there are some ways to get around this, but I prefer not to 
> complicate it)
>
> The issues I face in accomplising this are:
> I can't figure out how I can know what (how much) data is in queue to 
> send within JGroups. Â And thus have no idea when I should be ready to 
> send more data to JGroups

Ah, ok, this related to *sending* of a message, not receiving...

Well, there's 2 things you can do: if you use synchronous RPCs for 
example, you won't need FC, then you can either remove FC or use 
Message.setFlag(Message.NO_FC), which bypasses FC for a given message.

You could also set FC.max_block_times, e.g. 
max_block_times="50:1,500:3,1500:5,10000:10,100000:100", which sets the 
max time we're blocked for a message of a given size, e.g. in the above 
example we block 1 ms max for messages up to 50 bytes, 3 ms for messages 
between 50 and 500 bytes, and so on. The max time we block for messages 
 > 100K is 100ms.


-- 
Bela Ban
Lead JGroups / Clustering Team
JBoss

------------------------------------------------------------------------------
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
Javagroups-development mailing list