You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by David Blevins <da...@visi.com> on 2010/06/16 22:23:48 UTC

Re: Provide a system property to identify whether to cache the cluster datas on the client side

On Jun 13, 2010, at 4:34 PM, Ivan wrote:

> If the data is cleared, ejb client will fetch the cluster info again from
> server, failover will still work.
> Yes, for a clustering scenario, it is better to keep the cluster info to
> share between all the clients in the same VM.
> I am just thinking to have a option that we could turn off this .....

Hmm, the version number is supposed to be ensuring that stale data is removed from the map.  Sounds like maybe this isn't working -- or at least it requires the server to be around to say that it is invalid.

The idea is that the client sends the ClusterMetaData version when it talks to the associated ServerMetaData server.  If the server sees that it is different, then it will send a new ClusterMetaData and the client will update its map.

Maybe we should clear out the ClusterMetaData when we can't connect to the server.  Somewhere around this code in Client.java:

            Set<URI> failed = getFailed();
            failed.add(conn.getURI());
            conn.discard();


Not sure if that will entirely cover the situation you might be seeing.  Thoughts?


-David



> 
> 2010/6/13 Shawn Jiang <ge...@gmail.com>
> 
>> I did't get it.
>> 
>> If the data is cleared,  the ejb client will lose the connection info to
>> other nodes.  As a result, there will  be no failover.  Is a expected
>> behavior for a clustering ?
>> 
>> On Sat, Jun 12, 2010 at 10:48 AM, Ivan <xh...@gmail.com> wrote:
>> 
>>> Hi,
>>>   Currently, we keep a map on the client side to cache all the latest
>>> cluster data, and I do not find a way to clear it ( Or I miss it anywhere
>>> ?). I am thinking that it is better to provide a system property to
>>> identify
>>> that whether to cache those datas on the client side, as sometimes, it
>>> would
>>> make the users ( at least me :-) ) feel confusion, the ejb client
>> connects
>>> to other servers due to the specified server is down some time before.
>>>   Thoughts ?
>>> --
>>> Ivan
>>> 
>> 
>> 
>> 
>> --
>> Shawn
>> 
> 
> 
> 
> -- 
> Ivan