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?

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

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