You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@tomee.apache.org by "viola.lu" <vi...@gmail.com> on 2010/06/02 07:58:03 UTC

Multipoint URI

As we know, we can access ejb members with multicast URI:
multicast://239.255.3.2:6142?group=cluster1

Now i have serveral multipoint members: NODE1, NODE2, Node3, 
if i want to acess ejb members with multipoint URI, this URI format is?

Thanks a lot!
-- 
View this message in context: http://openejb.979440.n4.nabble.com/Multipoint-URI-tp2239616p2239616.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.

Re: Multipoint URI

Posted by Ivan <xh...@gmail.com>.

I think in the doc, we should also reminder the user to configure
openejb.client.requestretry property with true, or in the failover process,
users will get an IOException in the first time call, as the bad connection
is cached in the pool, and it seems that we have no way to know it until
trying to read something from it.

2010/6/11 David Blevins <da...@visi.com>

>
> On Jun 9, 2010, at 2:59 AM, viola.lu wrote:
>
> > The doc is clear for end-users to understand. thanks. But I have one
> > question about multipoint failover.
> > There are three servers:server 1. server 2, server 3, now i add server 2
> as
> > server 1 initial multipoint servers, server 3 as server 2 inital
> multipoint
> > servers, an openejb client call server 1 using:
> > failover:ejbd://[server 1]:4201( here i don't need add all servers to
> > openejb client provider url, right?)
> > then i shutdown server 1, openejb client should still work coz server 1
> will
> > failover to server 2, and if i shutdown server 2, then server 2 will
> > failover to server 3. This is the specific multipoint failover scenario,
> am
> > i right?
>
> If I understand correctly, then right on all points.
>
> To recap for possible doc benefit, sounds like this is the setup.
>
>   client -> server1 -> server2 -> server3
>
> That should definitely work, but the start order would have to be the exact
> opposite:
>
>   server3, server2, server1, client
>
> And the overall outcome would be:
>
>   server3 starts
>   server2 starts
>     - static: connect to server3
>   server1 starts
>     - static: connect to server2
>     - dynamic: connect to server3
>
> At this point all nodes are connected.
>
> And then when the client comes online and connects to server1, it will be
> sent the following dynamic list [server1, server2, server3].  That list is
> versioned and will be dynamically updated in future responses from the
> server if other servers join/leave the network.
>
> Once the dynamic list is obtained, the original
> "failover:ejbd://server1:4201" URL initially used by the client is no longer
> consulted and the dynamically obtained list is preferred for all failover
> situations.  This is built right into the ejbd protocol and is the same for
> multipoint(TCP) or multicast(UDP).
>
> Any method of connecting to a server will work -- "ejbd://server1:4201",
> "failover:ejbd://server1:4201,ejbd://server2:4201", or "multicast://
> 239.255.2.3:6142".  Upon first connect, the dynamic list is exchanged and
> that original URL is ignored.  Note for that reason using
> "failover:ejbd://server1:4201" and "ejbd://server1:4201" is essentially the
> same thing.
>
> Should a situation arise where the client cannot connect to any of the
> servers in the dynamic list, then the original URL is used one more time
> before failing the request.  Here is where the benefit of the "failover:"
> URL lies in that multiple servers can be listed resulting in more than one
> fallback.
>
> Should that fail as well, the request will finally fail and the remote bean
> method invocation will result in an exception.  The entire process is
> repeated should the application code attempt another remote bean invocation.
>  It is not necessary to construct a new InitialContext.
>
>
> Going to put this into the doc as well.  Good questions!  It's very helpful
> in flushing out the documentation -- or lack there of :)
>
> Keep them coming!  It's a good way to fill out anything that isn't
> completely clear.
>
> Thanks, Viola!
>
> -David
>
>


-- 
Ivan