February 2010 - jboss-remoting-issues

[JBoss JIRA] Created: (JBREM-1161) Evaluate FindBugs reports

by Ron Sigal (JIRA)

Evaluate FindBugs reports ------------------------- Key: JBREM-1161 URL: https://jira.jboss.org/jira/browse/JBREM-1161 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.2.3.SP2 http://hudson.jboss.org/hudson/view/JBoss%20AS/job/JBoss-AS-6.0.x-findbug... and http://hudson.jboss.org/hudson/view/JBoss%20AS/job/JBoss-AS-5.x-findbugs/... -- 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, 2 months

1
6
0 / 0

[JBoss JIRA] Created: (JBREM-1179) jboss-remoting.jar should log a version message when it is loaded

by Ron Sigal (JIRA)

jboss-remoting.jar should log a version message when it is loaded ----------------------------------------------------------------- Key: JBREM-1179 URL: https://jira.jboss.org/jira/browse/JBREM-1179 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Ron Sigal Assignee: Ron Sigal Priority: Minor Fix For: 2.2.3.SP2, 2.5.2.SP3 (Flounder) The logging should be done at DEBUG level. -- 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, 2 months

1
3
0 / 0

[JBoss JIRA] Created: (JBREM-1188) Socket transport doesn't set "timeout" to default value

by Ron Sigal (JIRA)

Socket transport doesn't set "timeout" to default value ------------------------------------------------------- Key: JBREM-1188 URL: https://jira.jboss.org/jira/browse/JBREM-1188 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.5.2.SP2 (Flounder), 2.2.3.SP1 Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.2.3.SP2, 2.5.2.SP3 (Flounder) >From Jaikiran Pai: Bug, bug, bug ;) There's some Java initialization trick going on with that piece of code (only relevant code has been pasted below): public class SocketClientInvoker extends MicroSocketClientInvoker { /** * Default value for socket timeout is 30 minutes. */ public static final int SO_TIMEOUT_DEFAULT = 1800000; protected int timeout = SO_TIMEOUT_DEFAULT; ... public SocketClientInvoker(InvokerLocator locator) { this(locator, null); } public SocketClientInvoker(InvokerLocator locator, Map configuration) { super(locator, configuration); configureParameters(); } protected ServerAddress createServerAddress(InetAddress addr, int port) { return new ServerAddress(addr.getHostAddress(), port, enableTcpNoDelay, timeout, maxPoolSize); } ... } public class MicroSocketClientInvoker ... { public MicroSocketClientInvoker(InvokerLocator locator, Map configuration) { ... try { setup(); } ... log.debug(this + " constructed"); } protected void setup() throws Exception { ... address = createServerAddress(addr, port); } ... } 1) SocketClientInvoker extends MicroSocketClientInvoker 2) When someone constructs SocketClientInvoker through it's constructor, JVM first constructs MicroSocketClientInvoker. 3) This includes MicroSocketClientInvoker's object field initialization and then the code execution in MicroSocketClientInvoker's constructor. 4) MicroSocketClientInvoker's constructor invokes setup() on itself which then invokes the (overridden) createServerAddress() on SocketClientInvoker 5) Note that, at this point the object field initialization of SocketClientInvoker has *not* yet been done. So the protected int timeout = SO_TIMEOUT_DEFAULT; in SocketClientInvoker hasn't yet been executed. Effectively, when SocketClientInvoker.createServerAddress() is invoked, the timeout value is 0. As a result, SocketClientInvoker.createServerAddress() ends up creating a ServerAddress with timeout = 0 (infinite timeout). (Rest of the flow is irrelevant, but let's just outline it here for the sake of completeness) 6) After completion of SocketClientInvoker.createServerAddress() method invoked in step#4, the MicroSocketClientInvoker.setup too completes and ultimately the code execution in the MicroSocketClientInvoker's constructor too is completed. 7) After step#6, the object field initialization of SocketClientInvoker starts and it's at this point where the timeout field value gets set to 1800000, but by now it's too late. And here are the logs (only a part of the entire log file) from remoting which prove that the timeout is being set to 0: 2010-02-19 16:32:29,104 DEBUG [org.jboss.remoting.Client] Client[16278782:3j001-51zxod-g5uvg99p-1-g5uvg99q-2].connect(null) 2010-02-19 16:32:29,104 TRACE [org.jboss.remoting.Client] Client[16278782:3j001-51zxod-g5uvg99p-1-g5uvg99q-2]: metadata = null 2010-02-19 16:32:29,172 DEBUG [org.jboss.remoting.transport.socket.MicroSocketClientInvoker] SocketClientInvoker[879860, socket://localhost.localdomain:3873] constructed 2010-02-19 16:32:29,172 DEBUG [org.jboss.remoting.MicroRemoteClientInvoker] SocketClientInvoker[879860, socket://localhost.localdomain:3873] connecting 2010-02-19 16:32:29,173 DEBUG [org.jboss.remoting.transport.socket.MicroSocketClientInvoker] Creating semaphore with size 50 2010-02-19 16:32:29,173 TRACE [org.jboss.remoting.transport.socket.MicroSocketClientInvoker] SocketClientInvoker[879860, socket://localhost.localdomain:3873] added new pool ([]) as ServerAddress[127.0.0.1:3873, NO enableTcpNoDelay timeout 0 ms, maxPoolSize=50] .... 2010-02-19 16:32:29,185 TRACE [org.jboss.remoting.transport.socket.MicroSocketClientInvoker] SocketClientInvoker[879860, socket://localhost.localdomain:3873] retryCount: 0 2010-02-19 16:32:29,185 TRACE [org.jboss.remoting.transport.socket.MicroSocketClientInvoker] SocketClientInvoker[879860, socket://localhost.localdomain:3873] obtained semaphore: 49 2010-02-19 16:32:29,185 TRACE [org.jboss.remoting.transport.socket.MicroSocketClientInvoker] SocketClientInvoker[879860, socket://localhost.localdomain:3873] creating socket 2010-02-19 16:32:29,186 TRACE [org.jboss.remoting.transport.socket.MicroSocketClientInvoker] SocketClientInvoker[879860, socket://localhost.localdomain:3873] created socket: Socket[addr=/127.0.0.1,port=3873,localport=39135] 2010-02-19 16:32:29,187 TRACE [org.jboss.remoting.transport.socket.SocketWrapper] constructing org.jboss.remoting.transport.socket.ClientSocketWrapper instance for Socket[addr=/127.0.0.1,port=3873,localport=39135], using timeout 0 2010-02-19 16:32:29,187 TRACE [org.jboss.remoting.transport.socket.SocketWrapper] ClientSocketWrapper[Socket[addr=/127.0.0.1,port=3873,localport=39135].6c5482] setting timeout to 0 ... regards, -Jaikiran -- 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, 2 months

1
3
0 / 0

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

by Ron Sigal (JIRA)

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

1
1
0 / 0

[JBoss JIRA] Created: (JBREM-1184) Fix NPE in ClassByteClassLoader.addClass()

by Ron Sigal (JIRA)

Fix NPE in ClassByteClassLoader.addClass() ------------------------------------------ Key: JBREM-1184 URL: https://jira.jboss.org/jira/browse/JBREM-1184 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.5.2.SP2 (Flounder), 2.2.3.SP1 Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.2.3.SP2, 2.5.2.SP3 (Flounder) When org.jboss.remoting.marshal.MarshallerLoaderHandler gets a request for a class, it returns an instance of org.jboss.remoting.loading.ClassBytes. If MarshallerLoaderHandler isn't able to find the desired class, then the returned ClassBytes object has null value for the class byte array. However, org.jboss.remoting.loading.ClassByteClassLoader doesn't check for the possibility of a null byte array. -- 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, 2 months

1
4
0 / 0

[JBoss JIRA] Created: (JBREM-1180) Formally reject hostnames which don't conform to RFC-952

by Justin Bertram (JIRA)

Formally reject hostnames which don't conform to RFC-952 -------------------------------------------------------- Key: JBREM-1180 URL: https://jira.jboss.org/jira/browse/JBREM-1180 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.2.3.SP1 Reporter: Justin Bertram Assignee: Ron Sigal Host names which don't conform to RFC-952 [1] should be formally rejected. This will save time diagnosing problems as org.jboss.remoting.InvokerLocator(String uri) does not handle non-conformant names properly and seemingly unrelated errors can occur as a result. [1] http://www.ietf.org/rfc/rfc952.txt -- 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, 2 months

2
5
0 / 0

[JBoss JIRA] Created: (JBREM-1183) ServerThread should catch java.lang.Errordorun

by Ron Sigal (JIRA)

ServerThread should catch java.lang.Errordorun ---------------------------------------------- Key: JBREM-1183 URL: https://jira.jboss.org/jira/browse/JBREM-1183 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.5.2.SP2 (Flounder), 2.2.3.SP1 Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.5.2.SP3 (Flounder) org.jboss.remoting.transport.socket.ServerThread.dorun() does not catch org.lang.Error, so an Error causes it to terminate without closing its socket. -- 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, 2 months

2
5
0 / 0

[JBoss JIRA] Created: (JBREM-1185) Change use of == to String.equals() in SSLSocketBuilder.validateStoreURL()

by Ron Sigal (JIRA)

Change use of == to String.equals() in SSLSocketBuilder.validateStoreURL() -------------------------------------------------------------------------- Key: JBREM-1185 URL: https://jira.jboss.org/jira/browse/JBREM-1185 Project: JBoss Remoting Issue Type: Sub-task Security Level: Public (Everyone can see) Affects Versions: 2.5.2.SP2 (Flounder), 2.2.3.SP1 Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.2.3.SP2, 2.5.2.SP3 (Flounder) org.jboss.remoting.security.SSLSocketBuilder.validateStoreURL() compares two Strings using ==. -- 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, 2 months

1
3
0 / 0

[JBoss JIRA] Created: (JBREM-1181) Fix NPE in SSLSocketBuilder

by Ron Sigal (JIRA)

Fix NPE in SSLSocketBuilder --------------------------- Key: JBREM-1181 URL: https://jira.jboss.org/jira/browse/JBREM-1181 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.5.2.SP2 (Flounder), 2.2.3.SP1 Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.2.3.SP2, 2.5.2.SP3 (Flounder) JBREM-1172 'SSLSocketBuilder should allow keystore and truststore URLs to be "NONE"' allows org.jboss.remoting.security.SSLSocketBuilder to build an unpopulated keystore, but if the keystore password is not set, a NullPointerException is thrown. -- 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, 2 months

1
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

jboss-remoting-issues February 2010