[
https://issues.jboss.org/browse/JGRP-1613?page=com.atlassian.jira.plugin....
]
Bela Ban commented on JGRP-1613:
--------------------------------
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
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