[
https://issues.jboss.org/browse/JGRP-1613?page=com.atlassian.jira.plugin....
]
Bela Ban edited comment on JGRP-1613 at 8/1/13 7:08 AM:
--------------------------------------------------------
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
was (Author: belaban):
OK, based on a conversation with Sanne at Red Hat Summit, we decided to narrow the
scope:
* 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
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