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(a)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,
>>>>
>>>>
>>>
>>