Re: [jgroups-dev] Request for comments on FORK: grabbing a private channel for communication from an existing channel

What you want to do would certainly work with FORK. But you don't need 
MuxMessageDispatcher here; you'd create forkChannel2.1 for client1 and 
ForkChannel2.2 for client2. Each fork-channel could then create its own 
regular MessageDispatcher on top of its own fork-channel.

In this respect, fork-channels are a replacement for 
MuxMessageDispatcher/MuxRpcDispatcher.

But the real value of fork-channels is for applications to be able to 
add protocols to their own private fork-stack. This is not possible with 
MuxMessageDispatcher where all MuxChannels use the same stack.

On 8/9/13 6:32 PM, Olexandr Markushyn wrote:
> Greetings,
>
>>> without having to configure and create an entirely new channel, which would be overkill
>>> (duplicate resources, new ports to maintain).
> At first glance it looks very similar to Mux feature (like MuxMessageDispatcher) but FORK is on different level.
> I've described what I have in mind and attached it to the letter.
> Could you please verify my understanding and in case it needs correction provide a little bit more clarification concerning relation between the Mux feature and the proposed FORK?
>
> Best regards,
> Oleksandr Markushyn
> SoftWeb
>
> -----Original Message-----
> From: Bela Ban [mailto:[email protected]]
> Sent: Friday, August 09, 2013 18:38
> To: jg-dev
> Subject: [jgroups-dev] Request for comments on FORK: grabbing a private channel for communication from an existing channel
>
> I wanted to solicit feedback on FORK [1].
>
> Using FORK, one can get a private light-weight channel off of an existing channel, e.g. to send messages, create an RpcDispatcher on top etc. The forked channel is then used exclusively by the application which forks it off of the main channel, which means it will neither interfere with the main channel, nor will it see messages other than its own.
>
> A forked channel can also add protocols, these are then private to it, too. For example, an application could grab the JGroups channel from Infinispan (Cache.getAdvancedCache().getRpcManager().getTransport().getChannel()),
> then fork a light-weight channel with CENTRAL_LOCK on top and use it to manage cluster wide locks. The forked channel would be private to the application which creates it, but it would piggyback its messages on the existing channel, without interfering with it.
>
> I'm currently implementing a prototype, and would like to get feedback for the current design [1]. The design doc and impl are in branch JGRP-1613.
>
> Feedback on the mailing list is appreciated !
> Cheers,
>
> [1] https://github.com/belaban/JGroups/blob/JGRP-1613/doc/design/FORK.txt
>
> --
> Bela Ban, JGroups lead (http://www.jgroups.org)
>
> ------------------------------------------------------------------------------
> Get 100% visibility into Java/.NET code with AppDynamics Lite!
> It's a free troubleshooting tool designed for production.
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> _______________________________________________
> Javagroups-development mailing list
>

-- 
Bela Ban, JGroups lead (http://www.jgroups.org)

------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
_______________________________________________
Javagroups-development mailing list