[jboss-cluster-dev] Re: JBoss Remoting feed back (Was: Re: Apache MINA slides for this year's JavaOne)

[David M. Lloyd]

Remoting 3 Client instances are thread-safe.  Also - there is no notion of 
an InvokerLocator in Remoting 3.  So that will solve that problem. :-)

Remoting 3 client code doesn't have to concern itself with connection 
management in quite the same way.  Basically, a Client is always connected, 
until you kill it.

- DML

On 04/21/2008 06:32 AM, Galder Zamarreno wrote:
> Trustin/Ron,
> 
> Currently, org.jboss.remoting.Client does not contain a getLocator() 
> method which I suspect is the reason why UnifiedInvokerProxy ends up 
> having a reference to org.jboss.remoting.Client and a reference to 
> org.jboss.remoting.InvokerLocator.
> 
> In a non clustered environment, the fact that we maintain a Client and 
> Locator on the client side is not a big problem, but in a clustered 
> environment, for example if using Round Robin, the client and the 
> locator keep changing from invocation to invocation.
> 
> Bottom line is that we're having to synchronize on UnifiedInvokerHAProxy 
> to make sure that the update of the InvokerLocator and Client are 
> atomic. See the following JIRAs for issues we had to resolve around this 
> area:
> 
> http://jira.jboss.com/jira/browse/JBAS-4815
> http://jira.jboss.com/jira/browse/JBAS-5364
> 
> With the complete rewrite, such problem might not even be relevant, but 
> I think it's important that we get it resolved when Remoting 3 is 
> designed. Unified invokers should only need to keep a reference to a 
> single thread safe client Remoting instance.
> 
> Maybe what we need of Remoting's Client class is not only getLocator() 
> but more importantly, an atomic method that is able to check whether 
> we're connected somewhere and if not, connect to it, in similar fashion 
> to putIfAbsent().
> 
> This is effectively what UnifiedInvokerHAProxy.getClient() is doing 
> after selecting the target node from the clustered load balancer. IMO, 
> it's Remoting that should be providing with a thread safe API to do this.
> 
> Thoughts?
> 
> Cheers,
> 
> Trustin Lee wrote:
>> Hi Luc et al,
>>
>> I am interested in everyone's feed back based on your experience with
>> Remoting.  I'd like to hear what was good and bad so we can fix as much
>> as possible in Remoting 3, which is a rewrite of Remoting 2 with whole
>> new API.
>>
>> Thanks in advance,
>>
>> Luc Texier wrote:
>>> Sounds very promising Trustin, great job!
>>>
>>> If you want feedback and suggestions on MINA based on our (painful) 
>>> experience with JBoss Remoting, feel free to contact the support team 
>>> here in cc.
>>>
>>> Cheers,
>>>
>>>
>>>
>>> On Mon, 14 Apr 2008 15:46:43 +0200, Trustin Lee <tlee at redhat.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> The attached PDF file is my slides for this year's JavaOne.  You might
>>>> be interested in this if you want to see what MINA is from examples
>>>> instead of vague propaganda. :)
>>>>
>>>> Any feed back or question is also appreciated.
>>>>
>>>> Please keep the file confidential until my session starts.  It's on
>>>> Friday.  ;)
>>>>
>>>> Thanks,
>>>
>>>
>>
>