[ https://issues.jboss.org/browse/JGRP-1613?page=com.atlassian.jira.plugin.... ] Bela Ban edited comment on JGRP-1613 at 8/2/13 7:16 AM: -------------------------------------------------------- The above problem could be solved by declaratively defining FORK and the various fork channels, e.g. (pseudo config): {noformat} ... <MFC/> <UFC/> <FORK> <fork id="1"> <CENTRAL_LOCK ... /> </fork> <fork id="2"> <COUNTER ... /> </fork> </FORK> <FRAG2/> <TOA/> {noformat} This defines # A main (default) stack with MFC, UFC, FRAG2 and TOA at the top # A stack (id=1) with CENTRAL_LOCK at the top and # A stack (id=2) with COUNTER at the top When a new fork-channel is created, we'd have to pick an ID and the channel could then be created over the corresponding entry in FORK. At node creation time, when the main-channel is created, FORK will also create the 2 fork-stacks. When a fork-channel with id=2 is created, it will be created over the fork-stack with id=2. This would require that we can create many fork-channels over the *same* stack, e.g. id=2. Say we deploy 20 applications where each app needs a fork-channel for id=2, we'd have 20 fork-channels over the stack with id=2. This means that a connect(), disconnect() and close() of a fork-channel should have no effect on the underlying stack, or we need to implement reference counting and only the close() of the last fork-channel removes that stack (or doesn't remove it at all...). Hmm... this may not work; the problem is how to demux messages coming from the fork-stack to the right fork-channel. If we have 1 fork-stack but 20 fork-channels on top, we won't know which channel to select... We could use a first id to select the right fork-stack (e.g. id=2) and then use a unique id to demux into the right fork-channel... this is getting complicated ! was (Author: belaban): The above problem could be solved by declaratively defining FORK and the various fork channels, e.g. (pseudo config): {noformat} ... <MFC/> <UFC/> <FORK> <fork id="1"> <CENTRAL_LOCK ... /> </fork> <fork id="2"> <COUNTER ... /> </fork> </FORK> <FRAG2/> <TOA/> {noformat} This defines # A main (default) stack with MFC, UFC, FRAG2 and TOA at the top # A stack (id=1) with CENTRAL_LOCK at the top and # A stack (id=2) with COUNTER at the top When a new fork-channel is created, we'd have to pick an ID and the channel could then be created over the corresponding entry in FORK. At node creation time, when the main-channel is created, FORK will also create the 2 fork-stacks. When a fork-channel with id=2 is created, it will be created over the fork-stack with id=2. This would require that we can create many fork-channels over the *same* stack, e.g. id=2. Say we deploy 20 applications where each app needs a fork-channel for id=2, we'd have 20 fork-channels over the stack with id=2. This means that a connect(), disconnect() and close() of a fork-channel should have no effect on the underlying stack, or we need to implement reference counting and only the close() of the last fork-channel removes that stack (or doesn't remove it at all...). Hmm... this may not work; the problem is how to demux messages coming from the fork-stack to the right fork-channel. If we have 1 fork-stack but 20 fork-channels on top, we won't know which channel to select... -- 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