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&gt; 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, >> >> >

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&gt; >>>> 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, >>>> >>>> >>> >>