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

[David M. Lloyd]

Yeah, I'm hoping for getting it in 5.1 (and EAP 5.0) but we'll see what 
happens.

- DML

On 04/21/2008 09:12 AM, Galder Zamarreno wrote:
> Ok, thanks for the heads up. When are you planning to integrate this in 
> AS? I suppose way after JBoss 5 is released, correct?
> 
> David M. Lloyd wrote:
>> 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,
>>>>>
>>>>>
>>>>
>>>
>