[jboss-dev] Unification of transports in AS
Dimitris Andreadis
dandread at redhat.com
Thu Sep 20 09:22:36 EDT 2007
Yes, put the fix in trunk, too.
Thanks
/Dimitris
Scott Marlow wrote:
> 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 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
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>
>
> _______________________________________________
> 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