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