[jboss-jira] [JBoss JIRA] (JGRP-1613) FORK: cactus stacks

[ https://issues.jboss.org/browse/JGRP-1613?page=com.atlassian.jira.plugin.... ] Bela Ban edited comment on JGRP-1613 at 8/1/13 7:09 AM: -------------------------------------------------------- OK, based on a conversation with Sanne at Red Hat Summit, we decided to narrow the scope. One of the main reasons not to implement a cactus stack like architecture like in the picture above was that - as grafts could be dynamically created (as a matter of fact, Sanne would need a graft to be created *per deployed application*) and deleted - not all nodes would have all grafts. This means that GMS would have to maintain something like the dreaded service views (google for Multiplexer service views, e.g. [1]). This means that if we have view \{A,B,C,D\}, but only nodes B and C have a certain graft created, then the *service view* for that graft would be \{B,C\}. The new functionality should be: * FORK can only be the top protocol in a stack (or towards the top of the stack) * An app gets a call createChannel() which takes a string that has to be unique. We create a fork-channel, which is a subclass of JChannel and has a ref to the main channel * The createChannel() method initially carries a list of instantiated protocols. Later we might also accept XML snippets * The close() or disconnect() method on the fork-channel does *not* close or disconnect the main channel, only the fork-channel * In other words, a fork-channel is a very light weight channel, and we might create hundreds of them without a big penalty * That string is used to mux/demux messages to the app * A header is added to each message including that max-id so we know how to mux/demux * There is a *main channel* and the dynamically created channels refer to it, e.g. their lifetime is less than or equal to the main channel * When the main channel is closed, sending of messages on the fork-channel throws an exception * The view and address of the fork-channels is the same as that of the main channel [1] https://community.jboss.org/wiki/MigrationFromMultiplexerToSharedTransport was (Author: belaban): OK, based on a conversation with Sanne at Red Hat Summit, we decided to narrow the scope. One of the main reasons was that - as grafts could be dynamically created (as a matter of fact, Sanne would need a graft to be created *per deployed application*) and deleted - not all nodes would have all grafts. This means that GMS would have to maintain something like the dreaded service views (google for Multiplexer service views, e.g. [1]). This means that if we have view \{A,B,C,D\}, but only nodes B and C have a certain graft created, then the *service view* for that graft would be \{B,C\}. The new functionality should be: * FORK can only be the top protocol in a stack (or towards the top of the stack) * An app gets a call createChannel() which takes a string that has to be unique. We create a fork-channel, which is a subclass of JChannel and has a ref to the main channel * The createChannel() method initially carries a list of instantiated protocols. Later we might also accept XML snippets * The close() or disconnect() method on the fork-channel does *not* close or disconnect the main channel, only the fork-channel * In other words, a fork-channel is a very light weight channel, and we might create hundreds of them without a big penalty * That string is used to mux/demux messages to the app * A header is added to each message including that max-id so we know how to mux/demux * There is a *main channel* and the dynamically created channels refer to it, e.g. their lifetime is less than or equal to the main channel * When the main channel is closed, sending of messages on the fork-channel throws an exception * The view and address of the fork-channels is the same as that of the main channel [1] https://community.jboss.org/wiki/MigrationFromMultiplexerToSharedTransport -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira