[ https://jira.jboss.org/jira/browse/JGRP-822?page=com.atlassian.jira.plugi... ] Bela Ban commented on JGRP-822: ------------------------------- Alternative: maybe call into the application and ask for permission to deliver a message. Downside: the application has to implement ordering now. The callback would pass the message to the app. The app decides, based on the sender and some token passed with the message, whether to pass the message up or whether to queue it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JGRP-822?page=com.atlassian.jira.plugi... ] Bela Ban updated JGRP-822: -------------------------- Fix Version/s: 2.10 (was: 2.9) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JGRP-822?page=com.atlassian.jira.plugi... ] Bela Ban updated JGRP-822: -------------------------- Summary: Scopes: concurrent delivery of messages from the same sender (was: NAKACK: concurrent delivery of messages from the same sender (scopes)) Fix Version/s: 2.11 (was: 3.0) Description: JGroups delivers messages from different senders concurrently. However, it delivers messages from the same sender sequentially. Sometimes, we can deliver messages from the same sender concurrently too, if the app tells us it is okay. For example: - Node N was 3 HTTP sessions: A, B and C - Clients update those sessions concurrently - As a result, N sends the following messages: A1, B1, A2, C1, C2, C3, B2, A3 - As NAKACK assigns sequence numbers (seqnos) based on JGroups instances, all messages from N will have to be delivered in the same order in which they were sent, e.g. (-> means followed by): A1 -> B1 -> A2 -> C1 -> C2 -> C3 -> B2 -> A3 - This means that, for example, the first update to C (C1) has to wait until A1, B1 and A2 have been delivered - This is not optimal, as updates for A, B and C are completely independent, and can be delivered in parallel - So a better delivery would be ('||' means concurrent delivery): A1 -> A2 -> A3 || B1 -> B2 || C1 -> C2 -> C3 - A3 needs to be delivered after A2 which needs to be delivered after A1. However, all updates for A can be delivered concurrently with messages for B or C. - OOB doesn't help: here all messages are delivered concurrently, but there is also no ordering within A, B or C ! SOLUTION: the sender adds a 'scope' token to a Message, e.g. the jsessionid (A, B or C). JGroups maintains NakReceiverWindows per *scope*, not per sender. The sender's address is the default token, so in the absence of a scope token, JGroups of course maintains NakReceiverWindows per sender. (NakReceiverWindows are used to keep track of seqnos). In the above example, if the scopes sent with *each message* are A, B and C, then we'd have 3 NakReceiverWindows: N::A, N::B, N::C. Each window would start with seqno 1, so updates for A, B and C are delivered concurrently with respect to each other, but sequentially within the scope. Issues: - This is an API change, and should probably be propagated up to the building blocks, such as RpcDispatcher. - A scope needs to be associated with an address A (of a JGroups instance): when A leaves or crashes, all associated scopes and their NakReceiverWindows needs to be released, too - Should this be done for UNICAST too ? was: JGroups delivers messages from different senders concurrently. However, it delivers messages from the same sender sequentially. Sometimes, we can deliver messages from the same sender concurrently too, if the app tells us it is okay. For example: - Node N was 3 HTTP sessions: A, B and C - Clients update those sessions concurrently - As a result, N sends the following messages: A1, B1, A2, C1, C2, C3, B2, A3 - As NAKACK assigns sequence numbers (seqnos) based on JGroups instances, all messages from N will have to be delivered in the same order in which they were sent, e.g. (-> means followed by): A1 -> B1 -> A2 -> C1 -> C2 -> C3 -> B2 -> A3 - This means that, for example, the first update to C (C1) has to wait until A1, B1 and A2 have been delivered - This is not optimal, as updates for A, B and C are completely independent, and can be delivered in parallel - So a better delivery would be ('||' means concurrent delivery): A1 -> A2 -> A3 || B1 -> B2 || C1 -> C2 -> C3 - A3 needs to be delivered after A2 which needs to be delivered after A1. However, all updates for A can be delivered concurrently with messages for B or C. - OOB doesn't help: here all messages are delivered concurrently, but there is also no ordering within A, B or C ! SOLUTION: the sender adds a 'scope' token to a Message, e.g. the jsessionid (A, B or C). JGroups maintains NakReceiverWindows per *scope*, not per sender. The sender's address is the default token, so in the absence of a scope token, JGroups of course maintains NakReceiverWindows per sender. (NakReceiverWindows are used to keep track of seqnos). In the above example, if the scopes sent with *each message* are A, B and C, then we'd have 3 NakReceiverWindows: N::A, N::B, N::C. Each window would start with seqno 1, so updates for A, B and C are delivered concurrently with respect to each other, but sequentially within the scope. Issues: - This is an API change, and should probably be propagated up to the building blocks, such as RpcDispatcher. - A scope needs to be associated with an address A (of a JGroups instance): when A leaves or crashes, all associated scopes and their NakReceiverWindows needs to be released, too - Should this be done for UNICAST too ? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JGRP-822?page=com.atlassian.jira.plugi... ] Bela Ban commented on JGRP-822: ------------------------------- The good thing is that SCOPE is a separate protocol, and so no code changes to NAKACK or UNICAST are needed. If scopes are used, and SCOPE is not in the stack config, we should throw an exception. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JGRP-822?page=com.atlassian.jira.plugi... ] Bela Ban commented on JGRP-822: ------------------------------- How do we remove scopes ? If we have web sessions as scope, for example, we'll keep creating new sessions, therefore scopes in SCOPE. How do we purge them, e.g. when a session expires ? We should definitely associate scopes with the member with which they were created. When a member P leaves the cluster, all scopes associated with P should be removed in SCOPE. However, that doesn't solve the issue of creating and expiring sessions (= scopes) within P, when P doesn't leave... Maybe there should be a expire(Scope... scopes) method in SCOPE. This triggers a multicast to all SCOPE instances, and causes purging. The API to use this could be in Message, e.g. removeScope(Scope id), although this feel not right. Maybe a utility method in Util, which - given a channel - grabs the SCOPE protocol and calls expire() method ? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JGRP-822?page=com.atlassian.jira.plugi... ] Bela Ban resolved JGRP-822. --------------------------- Resolution: Done Unit test is SCOPE_Test -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira