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

Olexandr Markushyn <[email protected]> Mon, 12 Aug 2013 10:36:12 +0000
Newsgroups gmane.comp.java.javagroups.devel
Message-ID <[email protected]>
Greetings,
=A0
Thank you for the clarification, now it's clear to me.
We have rather big amount of clients so in our case it looks as it's better=
 to have one instance of MuxMessageDispatcher instead of personal MessageDi=
spatcher for each of those many clients.
=A0
Best regards,
Oleksandr Markushyn
SoftWeb


-----Original Message-----
From: Bela Ban [mailto:[email protected]] =

Sent: Saturday, August 10, 2013 11:09
To: Olexandr Markushyn
Cc: jg-dev; SoftWeb Product Architects
Subject: 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 MuxM=
essageDispatcher here; you'd create forkChannel2.1 for client1 and
ForkChannel2.2 for client2. Each fork-channel could then create its own reg=
ular MessageDispatcher on top of its own fork-channel.

In this respect, fork-channels are a replacement for MuxMessageDispatcher/M=
uxRpcDispatcher.

But the real value of fork-channels is for applications to be able to add p=
rotocols to their own private fork-stack. This is not possible with MuxMess=
ageDispatcher 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 MuxMessageDisp=
atcher) 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 fo=
rked 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 c=
hannel, 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 ex=
isting channel, without interfering with it.
>
> I'm currently implementing a prototype, and would like to get feedback fo=
r 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=3D48897031&iu=3D/4140/ostg.c
> lktrk _______________________________________________
> 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=3D48897031&iu=3D/4140/ostg.cl=
ktrk
_______________________________________________
Javagroups-development mailing list