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

[Bela Ban (JIRA)]

    [ https://issues.jboss.org/browse/JGRP-1613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12794739#comment-12794739 ] 

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...
                  
> FORK: cactus stacks
> -------------------
>
>                 Key: JGRP-1613
>                 URL: https://issues.jboss.org/browse/JGRP-1613
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>         Attachments: IMAG0129.jpg
>
>
> Introduce cactus stacks where we can have multiple, different, stacks grafted onto the same base stack. 
> The problem today is that different applications need different functionality (protocol stack configs) in the AS. For example, we have the default stack used by AS. Then, Hibernate Search wants to use distributed locking (CENTRAL_LOCK) and counting (COUNTER). The total order stack wants to use TOA/SEQUENCER and so on.
> Cactus stacks add the ability to:
> * Provide custom (partial) stacks that are grafted onto a base stack
> * Add/remove stacks at runtime
> See the attached picture for details.

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