[jboss-dev] Unification of transports in AS
Dimitris Andreadis
dandread at redhat.com
Wed Sep 19 05:44:22 EDT 2007
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 at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
More information about the jboss-development
mailing list