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

I think I found a good solution here.  Let me know if you see any 
problems with this.

I have set it up to use TCP, and removed the FC protocol.  I then 
configured TCP to not use the send queue.  It seems that this allows us 
to block (I assume from the kernel level from a quick inspection).  I 
then just added a thread pool to handle calling back to alert we are 
ready to send more.  Any worries about this setup?

I tried to remove STABLE and NAKACK.  As I did not understand a need for 
these with the use of TCP (unless a server goes down, in which case I am 
not concerned).  But I continue to get warnings where it says 
digest=null.  But I noticed that these protocols are in the default TCP 
xml config files.  My question is what do these provide on a TCP layer?

Thanks, things have been looking great.

Bela Ban wrote:
>
>
> [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.
>
>


------------------------------------------------------------------------------
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