May 2009 - jboss-remoting-issues - Jboss List Archives

[JBoss JIRA] Updated: (JBREM-1138) JBREM-1127 - ClassCastExceptions arising from Unmarsharller/Classloader caching in MicroRemoteClientInvoker

by Galder Zamarreño (JIRA)

[ https://jira.jboss.org/jira/browse/JBREM-1138?page=com.atlassian.jira.plu... ] Galder Zamarreño updated JBREM-1138: ------------------------------------ Affects Version/s: 2.2.2.SP11 > JBREM-1127 - ClassCastExceptions arising from Unmarsharller/Classloader caching in MicroRemoteClientInvoker > ----------------------------------------------------------------------------------------------------------- > > Key: JBREM-1138 > URL: https://jira.jboss.org/jira/browse/JBREM-1138 > Project: JBoss Remoting > Issue Type: Support Patch > Security Level: Public(Everyone can see) > Affects Versions: 2.2.2.SP11 > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > > Port JBREM-1127 to a one-off patch so that classloading issues are avoided with paralell isolated EAR invocations using different versions of same class. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 11 months

1
0
0 / 0

[JBoss JIRA] Created: (JBREM-1134) Assure version compatibility with earlier versions of Remoting

by Ron Sigal (JIRA)

Assure version compatibility with earlier versions of Remoting -------------------------------------------------------------- Key: JBREM-1134 URL: https://jira.jboss.org/jira/browse/JBREM-1134 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.5.2 (Flounder) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 11 months

1
1
0 / 0

[JBoss JIRA] Created: (JBREM-1102) Make configuration map available to MarshalFactory

by Ron Sigal (JIRA)

Make configuration map available to MarshalFactory -------------------------------------------------- Key: JBREM-1102 URL: https://jira.jboss.org/jira/browse/JBREM-1102 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 2.5.0.SP2 (Flounder) , 2.2.2.SP11 Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.2.2.SP12, 2.5.0.SP3 (Flounder) The methods public static Marshaller getMarshaller(InvokerLocator locator, ClassLoader classLoader) and public static UnMarshaller getUnMarshaller(InvokerLocator locator, ClassLoader classLoader) in org.jboss.remoting.marshal.MarshalFactory get a marshaller or unmarshaller, respectively, from either a "datatype" parameter or from fully qualified names of the marshaller and unmarshaller classes. However, they don't have access to parameters configured by way of the configuration map. This is a problem for JBossESB, in particular, org.jboss.soa.esb.listeners.gateway.JBossRemotingGatewayListener, which creates an org.jboss.remoting.transport.Connector from parameters configured in a jboss-esb.xml file. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 11 months

1
11
0 / 0

[JBoss JIRA] Created: (JBREM-1137) New jnpserver requires wrapping InitialContext creating in PrivilegedExceptionAction

by Ron Sigal (JIRA)

New jnpserver requires wrapping InitialContext creating in PrivilegedExceptionAction ------------------------------------------------------------------------------------ Key: JBREM-1137 URL: https://jira.jboss.org/jira/browse/JBREM-1137 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.5.1 (Flounder) Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.5.2 (Flounder) org.jnp.interfaces.NamingContext.() accesses system property jboss.global.jnp.disableDiscovery. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 11 months

1
2
0 / 0

[JBoss JIRA] Created: (JBREM-1136) Update jars to match AS 5.1.0

by Ron Sigal (JIRA)

Update jars to match AS 5.1.0 ----------------------------- Key: JBREM-1136 URL: https://jira.jboss.org/jira/browse/JBREM-1136 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.5.2 (Flounder) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 11 months

1
6
0 / 0

[JBoss JIRA] Created: (JBREM-1127) ClassCastExceptions arising from Unmarsharller/Classloader caching in MicroRemoteClientInvoker

by Galder Zamarreño (JIRA)

ClassCastExceptions arising from Unmarsharller/Classloader caching in MicroRemoteClientInvoker ---------------------------------------------------------------------------------------------- Key: JBREM-1127 URL: https://jira.jboss.org/jira/browse/JBREM-1127 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.2.2.SP11, 2.2.2.SP10, 2.2.2.SP9, 2.2.2.SP8, 2.2.2.SP7, 2.2.2.SP5, 2.2.2.SP4, 2.2.2.GA_CP03, 2.2.2.GA_CP02, 2.2.2.SP2, 2.2.2.SP1, 2.2.2.GA_CP01, 2.2.2.GA, 2.2.1.GA, 2.2.0.SP4, 2.2.0.SP3, 2.2.0.SP2, 2.2.0.SP1, 2.2.0.GA (Bluto) Reporter: Galder Zamarreño Priority: Critical Classloading when accessing a remote bean from within 2 separate isolated EARs in AS is broken. Let's say you have a bean, A, deployed in node2 and this bean is accessed from two isolated EARs in node1 and this bean returns a instance of Foo. If you run paralell requests to these two separate EARs, you'll randomly get ClassCastExceptions. This is due to these two isolated EARs could potentially be using the same MicroRemoteClientInvoker instance, and hence the same unmarshaller. So, you could easily get this situation: 1. Invocation for bean A is proxied through isolated EAR-1 in node1. A new client invoker is created. 2009-05-04 16:31:04,489 31905 DEBUG [org.jboss.remoting.transport.socket.MicroSocketClientInvoker] (WorkerThread#0[127.0.0.2:50932]:) SocketClientInvoker[5e5f92, socket://lo3:3873] constructed ... // new logged line below server.log:12767:2009-05-04 16:31:04,489 31905 TRACE [org.jboss.remoting.MicroRemoteClientInvoker] (WorkerThread#0[127.0.0.2:50932]:) New unmarshaller set to org.jboss.remoting.marshal.serializable.SerializableUnMarshaller@2606b8 with classloader org.jboss.remoting.loading.RemotingClassLoader@10f3801 2. Loads Foo (or in this case ResponseMsg from EAR-1): 2009-05-04 16:31:04,534 31950 TRACE [org.jboss.remoting.loading.ObjectInputStreamWithClassLoader] (WorkerThread#0[127.0.0.2:50932]:) Calling Class.forName(classcastexceptiontest.process.ResponseMsg, false, org.jboss.remoting.loading.RemotingClassLoader@10f3801) 2009-05-04 16:31:04,535 31951 TRACE [org.jboss.remoting.loading.ObjectInputStreamWithClassLoader] (WorkerThread#0[127.0.0.2:50932]:) Resolved class classcastexceptiontest.process.ResponseMsg.ClassLoader=org.jboss.mx.loading.UnifiedClassLoader3@1d4f279{ url=file:/home/galder/jboss/code/eap/4.3.0.ga.cp04/build/output/jboss-4.3.0.GA_CP04/server/290590_1/tmp/deploy/tmp4913079009040294654processinvoker1.ear ,addedOrder=37} ..org.jboss.mx.loading.UnifiedClassLoader3@1d4f279{ url=file:/home/galder/jboss/code/eap/4.3.0.ga.cp04/build/output/jboss-4.3.0.GA_CP04/server/290590_1/tmp/deploy/tmp4913079009040294654processinvoker1.ear ,addedOrder=37} ..org.jboss.mx.loading.HeirarchicalLoaderRepository3$NoParentClassLoader@1178281 ..org.jboss.system.server.NoAnnotationURLClassLoader@1e4457d ..sun.misc.Launcher$AppClassLoader@17182c1 ....file:/home/galder/jboss/code/eap/4.3.0.ga.cp04/build/output/jboss-4.3.0.GA_CP04/bin/run.jar ....file:/usr/java/jdk1.6.0_12/lib/tools.jar ..sun.misc.Launcher$ExtClassLoader@13f5d07 ....file:/usr/java/jdk1.6.0_12/jre/lib/ext/dnsns.jar ....file:/usr/java/jdk1.6.0_12/jre/lib/ext/sunjce_provider.jar ....file:/usr/java/jdk1.6.0_12/jre/lib/ext/localedata.jar ....file:/usr/java/jdk1.6.0_12/jre/lib/ext/sunpkcs11.jar ++++CodeSource: (file:/home/galder/jboss/code/eap/4.3.0.ga.cp04/build/output/jboss-4.3.0.GA_CP04/server/290590_1/tmp/deploy/tmp4913079009040294654processinvoker1.ear-contents/process-intf.jar <no signer certificates>) Implemented Interfaces: ++interface java.io.Serializable ++++ClassLoader: null ++++Null CodeSource 2. Invocation for bean B is proxied through isolated EAR-2 in node1. A cached invoker is used: 2009-05-04 16:31:04,516 31932 TRACE [org.jboss.remoting.InvokerRegistry] (WorkerThread#1[127.0.0.2:50931]:) Found and returning cached client invoker (SocketClientInvoker[5e5f92, socket://lo3:3873]) And the unrmarshaller is already set with the wrong classloader!!: 2009-05-04 16:31:04,516 31932 TRACE [org.jboss.remoting.MicroRemoteClientInvoker] (WorkerThread#1[127.0.0.2:50931]:) Unmarshaller is already set to org.jboss.remoting.marshal.serializable.SerializableUnMarshaller@2606b8 3. So, with the wrong classloader, it loads Foo (or ResponseMsg) from EAR-1 again when it should have loaded it from EAR-2: 2009-05-04 16:31:04,524 31940 TRACE [org.jboss.remoting.loading.ObjectInputStreamWithClassLoader] (WorkerThread#1[127.0.0.2:50931]:) Resolved class classcastexceptiontest.process.ResponseMsg.ClassLoader=org.jboss.mx.loading.UnifiedClassLoader3@1d4f279{ url=file:/home/galder/jboss/code/eap/4.3.0.ga.cp04/build/output/jboss-4.3.0.GA_CP04/server/290590_1/tmp/deploy/tmp4913079009040294654processinvoker1.ear ,addedOrder=37} ..org.jboss.mx.loading.UnifiedClassLoader3@1d4f279{ url=file:/home/galder/jboss/code/eap/4.3.0.ga.cp04/build/output/jboss-4.3.0.GA_CP04/server/290590_1/tmp/deploy/tmp4913079009040294654processinvoker1.ear ,addedOrder=37} ..org.jboss.mx.loading.HeirarchicalLoaderRepository3$NoParentClassLoader@1178281 ..org.jboss.system.server.NoAnnotationURLClassLoader@1e4457d ..sun.misc.Launcher$AppClassLoader@17182c1 ....file:/home/galder/jboss/code/eap/4.3.0.ga.cp04/build/output/jboss-4.3.0.GA_CP04/bin/run.jar ....file:/usr/java/jdk1.6.0_12/lib/tools.jar ..sun.misc.Launcher$ExtClassLoader@13f5d07 ....file:/usr/java/jdk1.6.0_12/jre/lib/ext/dnsns.jar ....file:/usr/java/jdk1.6.0_12/jre/lib/ext/sunjce_provider.jar ....file:/usr/java/jdk1.6.0_12/jre/lib/ext/localedata.jar ....file:/usr/java/jdk1.6.0_12/jre/lib/ext/sunpkcs11.jar ++++CodeSource: (file:/home/galder/jboss/code/eap/4.3.0.ga.cp04/build/output/jboss-4.3.0.GA_CP04/server/290590_1/tmp/deploy/tmp4913079009040294654processinvoker1.ear-contents/process-intf.jar <no signer certificates>) Implemented Interfaces: ++interface java.io.Serializable ++++ClassLoader: null ++++Null CodeSource 4. Result is a CCE: 2009-05-04 16:31:04,525 31941 ERROR [classcastexceptiontest.processinvoker.ProcessInvoker2] (WorkerThread#1[127.0.0.2:50931]:) Caught exception java.lang.ClassCastException: classcastexceptiontest.process.ResponseMsg cannot be cast to classcastexceptiontest.process.ResponseMsg at $Proxy74.doProcess(Unknown Source) at classcastexceptiontest.processinvoker.ProcessInvoker2.invokeProcess(ProcessInvoker2.java:71) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:112) at org.jboss.ejb3.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:166) at org.jboss.ejb3.interceptor.EJB3InterceptorsInterceptor.invoke(EJB3InterceptorsInterceptor.java:63) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.ejb3.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:57) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:54) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79) at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:191) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:94) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:70) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:77) at org.jboss.ejb3.security.Ejb3AuthenticationInterceptor.invoke(Ejb3AuthenticationInterceptor.java:108) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:46) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:106) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.ejb3.stateless.StatelessContainer.dynamicInvoke(StatelessContainer.java:280) at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:106) at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82) at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:866) at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:608) at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:406) at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:173) How to resolve this? At first glance, the most trivial thing to do is to have an unmarshaller that simply uses whatever Thread.currentThread().getContextClassLoader() is set to, rather than being caching unmarshaller and classloaders. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 11 months

3
26
0 / 0

[JBoss JIRA] Created: (JBREM-1133) CLONE [JBREM-1129] - Eliminate nondeterminism in Lease updates

by Ron Sigal (JIRA)

CLONE [JBREM-1129] - Eliminate nondeterminism in Lease updates -------------------------------------------------------------- Key: JBREM-1133 URL: https://jira.jboss.org/jira/browse/JBREM-1133 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.5.0.SP2 (Flounder) , 2.2.2.SP11 Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.2.2.SP12, 2.5.2 (Flounder) Each time an org.jboss.remoting.LeasePinger sends a ping to a server side org.jboss.remoting.Lease, the ping message includes a sessionId for each org.jboss.remoting.Client connected to the server that holds the Lease. The lease updates its list of connected Clients each time it gets a ping, and it notifies all registered org.jboss.remoting.ConnectionListener's when a Client is removed from the list. Since the default behavior of the socket (and bisocket) transports is to use a pool of connections, it is possible for ping messages to arrive out of order. There should be a timestamp on each ping message so that out of order messages can be discarded. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 11 months

1
3
0 / 0

[JBoss JIRA] Created: (JBREM-1132) CLONE [JBREM-1128] - Introduce connection identity concept

by Ron Sigal (JIRA)

CLONE [JBREM-1128] - Introduce connection identity concept ---------------------------------------------------------- Key: JBREM-1132 URL: https://jira.jboss.org/jira/browse/JBREM-1132 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 2.2.2.SP11, 2.5.1 (Flounder) Reporter: Ron Sigal Assignee: Ron Sigal Priority: Critical Fix For: 2.2.2.SP12, 2.5.2 (Flounder) Currently, a Remoting server can monitor the continued connection to a Remoting client through the use of an org.jboss.remoting.LeasePinger / org.jboss.remoting.Lease pair. The client side LeasePinger sends out pings to the server side Lease, and, as long as the Lease receives timely pings, the connection is considered to be healthy. If a ping fails to arrive, then the Lease informs any registered org.jboss.remoting.ConnectionListener's about the connection failure. Consider the case in which an org.jboss.remoting.Client crashes, restarts, and recreates a LeasePinger in time for the new LeasePinger to satisfy its corresponding Lease. Then the Lease considers the connection to be intact. Some applications, however, with JBossMessaging being the prime example, might interpret this scenario as the failure and replacement of a connection. Remoting has no way of reporting a failure in this case. Remoting needs an optional behavior in which a connection is identified with a particular LeasePinger / Lease pair. When a LeasePinger is replaced, then a new connection begins. On the client side, the health of a connection can be reported by an org.jboss.remoting.ConnectionValidator, which periodically sends a ping to the server and reports a broken connection if it doesn't receive an answer within a configured window. The ConnectionValidator needs to be able to recognize and report on connections identifed by LeasePinger / Lease pairs. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 11 months

1
5
0 / 0

[JBoss JIRA] Created: (JBREM-1079) Port fixes to ServletServerInvoker from branch 2.x to branch 2.2

by Ron Sigal (JIRA)

Port fixes to ServletServerInvoker from branch 2.x to branch 2.2 ---------------------------------------------------------------- Key: JBREM-1079 URL: https://jira.jboss.org/jira/browse/JBREM-1079 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.2.2.SP11 Reporter: Ron Sigal Fix For: 3.0.0.GA The servlet transport is getting increased use, as demonstrated by JIRA issue JBPAPP-1274 "Fix JBoss Messaging and JBoss Remoting so that servlet transport can be used" and the current attention to JBMESSAGING-1131 "Add configuration for Remoting servlet transport". Some of the changes made for * JBREM-675 "Problems with Servlet invoker" * JBREM-838 "allow user to set content-type for http responses (part 2: ServletServerInvoker)" * JBREM-853 "ServletServerInvoker should not put null URL path in metadata map" should be ported to the 2.2 branch for the version of Remoting used in EAP 4.2/4.3. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 11 months

2
6
0 / 0

[JBoss JIRA] Created: (JBREM-1130) Assure version compatibility with earlier versions of Remoting

by Ron Sigal (JIRA)

Assure version compatibility with earlier versions of Remoting --------------------------------------------------------------- Key: JBREM-1130 URL: https://jira.jboss.org/jira/browse/JBREM-1130 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.2.2.SP12 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 11 months

1
1
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

jboss-remoting-issues May 2009