Re: [jboss-dev] Unification of transports in AS

I'm not sure if this is related but I checked a (PooledInvokerProxy ) fix for jbas-4719 into 4.2 and would like to apply the fix to 5.x as well. If Pooled Invoker is being deleted from 5.x, then maybe I shouldn't bother with the change in 5.x. jbas-4719 is about fail-over not working and load balancing policies not working as efficiently as they could when the pooled invoker is used. The change is: "+ public boolean equals(Object other) + { + if(! (other instanceof PooledInvokerProxy)) + return false; + return (address.equals( ((PooledInvokerProxy)other).address )); + } + + public int hashCode() + { + return address.hashCode(); + } +" My preference is to check the fix into 5.x as well. Scott Dimitris Andreadis wrote: > Hi Ron, > > thats a very good summary, thanks. > > I think we should put on hold (1) type of issues and deal with (3) (4) > (5), as time permits. > > About (2) I don't believe there is urgency in rushing a remoting 2.4 > out, unless some other project/critical fix depends on it. > > Ron Sigal wrote: >> Hi Dimitris, >> >> I've been looking at the Remoting component issues in JBAS, trying to >> get a handle on what needs to be done and when. It seems to me that >> these issues fall into one of the following categories: >> >> (1) Depends on either Remoting API or Remoting 3 design. These could >> wait for Remoting 3, or, depending on how different the Remoting >> versions are, we could finish them and then redo them for Remoting >> 3. The upcoming design meeting should shed additional light. >> >> (2) Independent of Remoting API but depends on an issue currently >> scheduled for Remoting 2.4. For these issues, we could need to wait >> at least until Remoting 2.4 is available. >> >> (3) Independent of both Remoting API and version. These could (and >> in some cases should) be finished now. >> >> (4) Doesn't look like a Remoting issue to me (I could be wrong). >> These could be done any time. >> >> (5) May no longer be necessary. >> >> Now, I have a couple of questions. >> >> (1) Am I on the right track in my descriptions below? >> >> (2) What is the time frame for getting Remoting 2.4 into JBossAS >> 5.0? We could probably adjust the release schedule accordingly. >> >> (3) Do you (or does anyone else) have any opinions about the urgency >> of these issues? >> >> Thanks, >> Ron >> >> ================================================================================================================================= >> >> JBAS-1465 Pooled Invoker should use common thread pool >> Isn't pooled invoker obsoleted by unifed invoker? >> >> JBAS-1984 HttpNamingContextFactory unable to reconnect >> Independent of Remoting API >> >> JBAS-2448 The server side of org.jboss.invocation.pooled has multiple >> synchronization issues >> Again, is the pooled invoker obsolote? >> JBAS-2766 tomcat libraries not available to remoting when using >> http transport >> Independent of Remoting API. I gather that the solution is to >> put the unified invoker configuration in its own sar. One catch, >> though, is that the http transport currently depends on tomcat jars, >> and JBoss 5 ships with JBossWeb. Issue JBREM-713 "Check if jbossweb >> can replace tomcat jars for the http server invoker" is currently >> scheduled for Remoting 2.4. JBAS-2939 Make Invocation policies >> more configurable >> Independent of Remoting API. >> >> JBAS-3151 Convert HA-JNDI stubs to Remoting >> Depends on Remoting API. >> JBAS-3154 Cleanup the remoting module in 3.2.x >> Independent of Remoting API. >> JBAS-3291 Allow Configurable Parameters To Defined Client >> Interceptors In JRMPProxyFactory >> (1) In AS 4.x, independent of Remoting API. >> (2) In AS 5.0, obsoleted by JBAS-4456. >> JBAS-3309 Remote client couldn't connect EJB remote interface if >> the ejb3.deployer InvokerLocator port is set to non-default value. >> (other than 3873) >> Independent of Remoting API. >> JBAS-3658 Remote classloading service - Redesign >> Related to Remoting 3 design. >> JBAS-3724 NotFoundInDispatcherException from InvokerLocator when >> accessing remote calls when on a non default port >> Duplicates JBAS-3309. >> JBAS-3765 AOP-based version of RetryInterceptor >> Might depend on Remoting API. Not sure. >> JBAS-3885 JMXConnectorServer not respecting the -b value >> I could be wrong, but doesn't look like a Remoting issue. >> JBAS-3925 Unification of transports to Remoting 2.2.0 >> Depends on JBAS-3926, JBAS-3927, JBAS-3928, JBAS-3929, JBAS-3930, >> JBAS-3931, below. >> JBAS-3926 Move remoting transports out of conf/jboss-service.xml >> to a remoting-beans.xml >> I think this depends on JBREM-63 "Get rid of the legacy >> configuration that embeds xml parsing". In forum thread >> http://www.jboss.com/index.html?module=bb&op=viewtopic&t=106643, >> Scott says "The first step is to ensure that every externalizable >> behavior has a pojo metadata object." So, for each of the MBeans >> defined in Remoting (e.g., Connector, AbstractDetector), we should >> create a metadata configuration class. JBREM-63 is currently >> scheduled for Remoting 2.4. >> JBAS-3927 Update naming service to using remoting based proxy >> Depends on Remoting API. >> >> JBAS-3928 Replace jmx-invoker-service.xml with jmx-remoting.sar >> I'm not familiar with jmx-remoting in AS 5.0, but I don't think >> it uses anything from Remoting. Is that true? >> JBAS-3929 RMIAdaptorExt view of >> org.jboss.mx.remoting.service.JMXConnectorServerService >> Doesn't seem to depend on Remoting API. >> >> JBAS-3931 Synch up ejb3x transport configs >> Doesn't seem to depend on Remoting API. >> JBAS-4456 Replace JRMPProxyService with a remoting based bean. >> Seems to depend on Remoting API. >> JBAS-4578 Upgrade jboss remoting to v2.2.2.GA (from v2.2.1.GA) >> Done? >> JBAS-4586 unified invoker causes delays under load >> Bug. Needs to be looked at. >> >> Dimitris Andreadis wrote: >>> We have this base issue to track unification of transports in AS5 >>> http://jira.jboss.com/jira/browse/JBAS-3925 >>> >>> My concern is without a clear strategy yet on remoting v3 (which I >>> understand is currently under discussion) in terms of API changes >>> and compatibility with v2, shouldn't we delay this set of tasks? >>> >>> _______________________________________________ >>> jboss-development mailing list >>> jboss-development(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jboss-development >> >> -- >> JBoss, a Division of Red Hat >> "My company's smarter than your company." >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> jboss-development mailing list >> jboss-development(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-development > _______________________________________________ > jboss-development mailing list > jboss-development(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-development > _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development