December 2008 - jboss-remoting-issues

[JBoss JIRA] Created: (JBREM-1077) Fix problem in CompressingMarshaller

by Ron Sigal (JIRA)

Fix problem in CompressingMarshaller ------------------------------------ Key: JBREM-1077 URL: https://jira.jboss.org/jira/browse/JBREM-1077 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 3.0.0.GA In org.jboss.remoting.marshal.compress.CompressingMarshaller.write(), gzos.finish(); oos.flush(); should be oos.flush(); bos.flush(); gzos.flush(); gzos.finish(); as it is on the 2.x branch. -- 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, 8 months

2
14
0 / 0

[JBoss JIRA] Created: (JBREM-1076) SocketServerInvoker.processInvocation() should return if running == false

by Ron Sigal (JIRA)

SocketServerInvoker.processInvocation() should return if running == false ------------------------------------------------------------------------- Key: JBREM-1076 URL: https://jira.jboss.org/jira/browse/JBREM-1076 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.5.0.SP2 (Flounder) Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.5.0.SP3 (Flounder) The while(worker == null && running) loop can end with worker == null, in which case processRequest() should return instead of proceeding. -- 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

15 years

1
5
0 / 0

[JBoss JIRA] Created: (JBREM-1039) Release 2.2.2.SP11

by Ron Sigal (JIRA)

Release 2.2.2.SP11 ------------------ Key: JBREM-1039 URL: https://jira.jboss.org/jira/browse/JBREM-1039 Project: JBoss Remoting Issue Type: Release Security Level: Public (Everyone can see) Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.2.2.SP11 -- 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

15 years, 1 month

1
1
0 / 0

[JBoss JIRA] Created: (JBREM-1072) Synchronize access to static maps in MarshalFactory

by Ron Sigal (JIRA)

Synchronize access to static maps in MarshalFactory --------------------------------------------------- Key: JBREM-1072 URL: https://jira.jboss.org/jira/browse/JBREM-1072 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.5.0.SP2 (Flounder) , 2.2.2.SP10 Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.2.2.SP11, 2.5.0.SP3 (Flounder) Users have experienced the exception org.jboss.remoting.marshal.InvalidMarshallingResource: Can not find a valid marshaller for data type: serializable at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:79) at org.jboss.remoting.Client.invoke(Client.java:1634) at org.jboss.remoting.Client.invoke(Client.java:548) at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:62) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:67) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:53) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:74) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.ejb3.stateless.StatelessRemoteProxy.invoke(StatelessRemoteProxy.java:107) This is strange, since a marshaller for the datatype "serializable" is hardcoded in org.jboss.remoting.marshal.MarshalFactory. However, access to the static Map marshallers is not synchronized, so it's possible that one subsystem is adding a marshaller (e.g., EJB2, JBossMessaging) at the same time that EJB3 is trying to extract a marshaller. The same observation applies to unmarshallers. -- 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

15 years, 1 month

2
5
0 / 0

[JBoss JIRA] Created: (JBREM-1018) JBREM-1014 patch for 2.2.2.SP4

by Galder Zamarreno (JIRA)

JBREM-1014 patch for 2.2.2.SP4 ------------------------------ Key: JBREM-1018 URL: https://jira.jboss.org/jira/browse/JBREM-1018 Project: JBoss Remoting Issue Type: Support Patch Security Level: Public (Everyone can see) Affects Versions: 2.2.2.SP4 Reporter: Galder Zamarreno Assignee: Galder Zamarreno Port the fix for JBREM-1014 to JBoss Remoting 2.2.2.SP4, which is the Remoting version in EAP 4.3.0.GA and 4.2.0.GA_CP02. -- 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

15 years, 3 months

1
1
0 / 0

[JBoss JIRA] Created: (JBREM-992) Can't restart a Connector that uses SocketServerInvoker

by Brian Stansberry (JIRA)

Can't restart a Connector that uses SocketServerInvoker ------------------------------------------------------- Key: JBREM-992 URL: http://jira.jboss.com/jira/browse/JBREM-992 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.4.0.GA (Pinto) Reporter: Brian Stansberry Priority: Minor You can't take a Connector that uses SocketServerInvoker through a restart, i.e. these lifecycle steps: create/start/stop/start. You have to do a full transition to destroy and back through create. This is because SocketServerInvoker sets its maxPoolSize field to 0 as part of its cleanup work in stop(). If you then call start() you get a failure due to 0 being an invalid value for maxPoolSize: 2008-06-04 12:33:00,382 DEBUG [org.jboss.invocation.unified.server.UnifiedInvokerHA] (RMI TCP Connec tion(31)-127.0.0.1) Starting failed jboss:service=invoker,type=unifiedha,partitionName=RestartPartit ion java.lang.IllegalArgumentException: Illegal cache capacities at org.jboss.util.LRUCachePolicy.<init>(LRUCachePolicy.java:77) at org.jboss.remoting.transport.socket.LRUPool.<init>(LRUPool.java:44) at org.jboss.remoting.transport.socket.SocketServerInvoker.start(SocketServerInvoker.java:231) at org.jboss.invocation.unified.server.UnifiedInvoker.startService(UnifiedInvoker.java:140) at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:376) at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:322) at sun.reflect.GeneratedMethodAccessor65.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

4
7
0 / 0

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

by Ron Sigal (JIRA)

Assure version compatibility with earlier versions of Remoting -------------------------------------------------------------- Key: JBREM-1075 URL: https://jira.jboss.org/jira/browse/JBREM-1075 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.2.2.SP11 -- 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

15 years, 3 months

1
1
0 / 0

[JBoss JIRA] Created: (JBREM-1073) Allow invocations to stopped servers to throw CannotConnectExceptions

by Ron Sigal (JIRA)

Allow invocations to stopped servers to throw CannotConnectExceptions --------------------------------------------------------------------- Key: JBREM-1073 URL: https://jira.jboss.org/jira/browse/JBREM-1073 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.2.2.SP10 Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.2.2.SP11 org.jboss.remoting.transport.socket.SocketServerInvoker has a problem shutting down ServerThreads, which, for Remoting versions 2.4.0.GA and above, was fixed by the changes made for JBREM-821 "JBoss Remoting fails under load". However, the problem remains in Remoting versions 2.2.x. In particular, shutting down the SocketServerInvoker does not necessarily immediately close all if its ServerThreads. Consequently, on the client side, it is possible for an invocation to arrive and obtain a pooled connections to the closed SocketServerInvoker, which results in org.jboss.remoting.ServerInvoker, and therefore the call to org.jboss.remoting.Client.invoke(), throwing a ServerInvoker.InvalidStateException. This can cause problems for a clustered EJB3, leading org.jboss.invocation.unified.interfaces.UnifiedInvokerHAProxy to throw an UndeclaredThrowableException instead of trying an alternative server. One solution seems to be to allow, as an optional behavior, org.jboss.remoting.MicroRemoteClientInvoker to translate an InvalidStateException to an org.jboss.remoting.CannotConnectException. -- 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

15 years, 3 months

1
4
0 / 0

[JBoss JIRA] Created: (JBREM-1042) CLONE [JBREM-1019] - RemotingClassLoader needs option to delegate to user class loader before parent

by Ron Sigal (JIRA)

CLONE [JBREM-1019] - RemotingClassLoader needs option to delegate to user class loader before parent ---------------------------------------------------------------------------------------------------- Key: JBREM-1042 URL: https://jira.jboss.org/jira/browse/JBREM-1042 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.4.0.GA (Pinto) Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.4.0.SP1 (Pinto) For the jbossas5 app client container, a class loader policy that loads from the child first is used to pickup the client jar manifest references. If such a class loader is registered as the user class loader with the RemotingClassLoader, its not going be delegated to first. This results in duplicate and conflicting classes being loaded. -- 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

15 years, 3 months

1
5
0 / 0

[JBoss JIRA] Created: (JBREM-1071) IllegalStateException in ConnectorValidator.run()

by Konstantin Khrapchenko (JIRA)

IllegalStateException in ConnectorValidator.run() ------------------------------------------------- Key: JBREM-1071 URL: https://jira.jboss.org/jira/browse/JBREM-1071 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.5.0.SP2 (Flounder) Reporter: Konstantin Khrapchenko Fix For: 2.5.0.SP3 (Flounder) Sometimes when a server is under a heavy load a connection validator timer thread gets crashed by Exception in thread "Timer-2" java.lang.IllegalStateException: org.jboss.remoting.ConnectionValidator.run() should not be called directly; use org.jboss.remoting.ConnectionValidator.addConnectionListener() instead. at org.jboss.remoting.ConnectionValidator.run(ConnectionValidator.java:289) at java.util.TimerThread.mainLoop(Timer.java:512) at java.util.TimerThread.run(Timer.java:462) It seems an additional synchronization on (lock) is needed in the 'start' method to ensure a 'timer' variable gets assigned before a 'run' method is invoked by a timer thread. -- 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

15 years, 4 months

2
4
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

jboss-remoting-issues December 2008