October 2008 - jboss-remoting-issues

[JBoss JIRA] Created: (JBREM-1048) Release 2.5.0.SP1

by Ron Sigal (JIRA)

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

15 years, 6 months

1
1
0 / 0

[JBoss JIRA] Created: (JBREM-1046) HTTPClientInvoker throws NullPointerException when HttpURLConnection.getInputStream() returns null

by Ron Sigal (JIRA)

HTTPClientInvoker throws NullPointerException when HttpURLConnection.getInputStream() returns null -------------------------------------------------------------------------------------------------- Key: JBREM-1046 URL: https://jira.jboss.org/jira/browse/JBREM-1046 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.5.0.GA (Flounder) Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.5.0.SP1 (Flounder) When an HTTP server returns an error code and no content, it is possible for java.net.HttpUrlConnection.getInputStream() to retun null, which causes a NullPointerException in org.jboss.remoting.transport.http.HTTPClientInvoker.useHttpURLConnection(). -- 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, 6 months

1
6
0 / 0

[JBoss JIRA] Created: (JBREM-1051) CLONE [JBREM-1050] - HTTPClientInvoker does not support BASIC authentication for proxies when use of proxy is configured by system properties

by Ron Sigal (JIRA)

CLONE [JBREM-1050] - HTTPClientInvoker does not support BASIC authentication for proxies when use of proxy is configured by system properties --------------------------------------------------------------------------------------------------------------------------------------------- Key: JBREM-1051 URL: https://jira.jboss.org/jira/browse/JBREM-1051 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 The use of a proxy can be communicated to the HTTP transport in two ways. 1. The parameters "http.proxyHost" and "http.proxyPort" can be configured in the invocation metadata map, or 2. the system properties "http.proxyHost" and "http.proxyPort" can be set. In the former case, org.jboss.remoting.transport.http.HTTPClientInvoker will attempt to call java.net.URL.openConnection(java.net.Proxy) (which exists only in jdk 1.5 and above). If the call succeeds, HTTPClientInvoker will go on to create a "Proxy-Authorization" request header, based on the values associated with ""http.proxy.username" and "http.proxy.password", either in the invocation metadata map or as system properties. In the latter case, the java.net.URL class will configure proxy information based on the system properties. The problem is that, in the latter case, HTTPClientInvoker does not check for the existence of the "http.proxyHost" and "http.proxyPort" system properties, and so never checks to see if it should create a "Proxy-Authorization" request header. -- 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, 6 months

1
3
0 / 0

[JBoss JIRA] Created: (JBREM-1049) Remove old versions of jboss-remoting.jar from distribution zip file

by Ron Sigal (JIRA)

Remove old versions of jboss-remoting.jar from distribution zip file -------------------------------------------------------------------- Key: JBREM-1049 URL: https://jira.jboss.org/jira/browse/JBREM-1049 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.5.0.GA (Flounder) Reporter: Ron Sigal Assignee: Ron Sigal Priority: Minor Fix For: 2.5.0.SP1 (Flounder) Currently, the src/etc/lib directory contains a number of old versions of jboss-remoting.jar, for use in version compatibility tests. Since each jar approaches 1 MB, the distribution files have become quite large (about 22 MB for release 2.5.0.GA). It would make more sense to change build.xml so that the jars are downloaded as needed from the JBoss public repository. -- 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, 6 months

1
1
0 / 0

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

by Ron Sigal (JIRA)

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

15 years, 6 months

1
1
0 / 0

[JBoss JIRA] Created: (JBREM-1044) Old version of org.apache.tomcat.util.net.SocketStatus screws up JBossWeb

by Bill Burke (JIRA)

Old version of org.apache.tomcat.util.net.SocketStatus screws up JBossWeb ------------------------------------------------------------------------- Key: JBREM-1044 URL: https://jira.jboss.org/jira/browse/JBREM-1044 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Components: general Affects Versions: 2.5.0.GA (Flounder) Reporter: Bill Burke Priority: Blocker Old version of org.apache.tomcat.util.net.SocketStatus screws up JBossWeb. This exists in 2.5.0.GA jboss-remoting.jar within 5.0.0.CR2 AS. This screws up all the async HTTP code within JBoss Web (makes it unusable). It would also affect regular JBossWeb request processing, and cause errors when keepalive times out. -- 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, 6 months

2
3
0 / 0

[JBoss JIRA] Created: (JBREM-1045) ServerInvokerCallbackHandler can suffer deadlock when used with BlockingCallbackStore

by Ron Sigal (JIRA)

ServerInvokerCallbackHandler can suffer deadlock when used with BlockingCallbackStore ------------------------------------------------------------------------------------- Key: JBREM-1045 URL: https://jira.jboss.org/jira/browse/JBREM-1045 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.2.2.SP10, 2.5.0.GA (Flounder) Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.5.0.SP1 (Flounder), 2.2.2.SP11 When org.jboss.remoting.callback.ServerInvokerCallbackHandler.handleCallback() gets a true response from persistCallback(), it grabs the lock on the callback field and calls org.jboss.remoting.callback.BlockingCallbackStore.add(), which enters an indefinite wait() until BlockingCallbackStore.getNext() is called. However, ServerInvokerCallbackHandler.getCallbacks() cannot call BlockingCallbackStore.getNext() without getting the lock on the callback field. The solution is to remove the call to BlockingCallbackStore.add() from the synchronized(callbacks) block. Related forum thread: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4184578#4184578. -- 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, 6 months

1
3
0 / 0

[JBoss JIRA] Created: (JBREM-1043) CLONE -Fix PortUtil.getRandomStartingPort()

by Ronnie Govender (JIRA)

CLONE -Fix PortUtil.getRandomStartingPort() ------------------------------------------- Key: JBREM-1043 URL: https://jira.jboss.org/jira/browse/JBREM-1043 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.2.2.SP7 Reporter: Ronnie Govender Assignee: Ron Sigal Fix For: 2.2.2.SP8 >From support case 176016: Description: While starting JBoss using the "all" configuration we get the following error message: "Problem starting service jboss.messaging:service=Connector,transport=bisocket". Followed in the stack trace by the error: "Caused by: java.lang.NumberFormatException: For input string: "add46e5e"". The JBoss messaging service does not start which prevents other JBoss services from being deployed. Walking through the following stack trace: 2008-04-16 09:29:46,160 WARN [org.jboss.system.ServiceController] Problem starting service jboss.messaging:service=Connector,transport=bisocket java.lang.ExceptionInInitializerError at org.jboss.remoting.transport.bisocket.BisocketServerInvoker.start(BisocketS erverInvoker.java:182) at org.jboss.remoting.transport.Connector.start(Connector.java:322) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:3 9) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImp l.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.jav a:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.server.Invocation.invoke(Invocation.java:86) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:2 64) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.ja va:995) at $Proxy0.start(Unknown Source) at org.jboss.system.ServiceController.start(ServiceController.java:417) at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImp l.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.jav a:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.server.Invocation.invoke(Invocation.java:86) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:2 64) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210) at $Proxy4.start(Unknown Source) at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1015) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:3 9) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImp l.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.jav a:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.jav a:133) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOp erationInterceptor.java:142) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:2 64) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210) at $Proxy9.deploy(Unknown Source) at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScann er.java:421) at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner .java:634) at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan (AbstractDeploymentScanner.java:263) at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(Abstrac tDeploymentScanner.java:336) at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport .java:289) at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSup port.java:245) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:3 9) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImp l.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.jav a:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.server.Invocation.invoke(Invocation.java:86) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:2 64) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.ja va:978) at $Proxy0.start(Unknown Source) at org.jboss.system.ServiceController.start(ServiceController.java:417) at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImp l.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.jav a:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.server.Invocation.invoke(Invocation.java:86) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:2 64) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210) at $Proxy4.start(Unknown Source) at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:766) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:3 9) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImp l.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.jav a:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.jav a:133) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOp erationInterceptor.java:142) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:2 64) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210) at $Proxy5.deploy(Unknown Source) at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:533) at org.jboss.system.server.ServerImpl.start(ServerImpl.java:399) at org.jboss.Main.boot(Main.java:200) at org.jboss.Main$1.run(Main.java:508) at java.lang.Thread.run(Thread.java:602) Caused by: java.lang.NumberFormatException: For input string: "add46e5e" at java.lang.Throwable.<init>(Throwable.java:196) at java.lang.Exception.<init>(Exception.java:41) at java.lang.RuntimeException.<init>(RuntimeException.java:43) at java.lang.IllegalArgumentException.<init>(IllegalArgumentException.ja va:36) at java.lang.NumberFormatException.<init>(NumberFormatException.java:38) at java.lang.NumberFormatException.forInputString(NumberFormatException.java:4 8) at java.lang.Integer.parseInt(Integer.java:459) at org.jboss.remoting.transport.PortUtil.getRandomStartingPort(PortUtil.java:1 47) at org.jboss.remoting.transport.PortUtil.<clinit>(PortUtil.java:49) Gets us to the method "getRandomStartingPort" in the class "PortUtil" in the package "org.jboss.remoting.transport". Which is part of the "jboss-remoting.jar" in the directory jboss430/thirdparty/jboss/remoting/lib. The existing code that is failing is: public static int getRandomStartingPort() { Object o = new Object(); String os = o.toString(); os = os.substring(17); int n = Integer.parseInt(os, 16); int p = Math.abs(new SecureRandom(String.valueOf(System.currentTimeMillis() + n).getBytes()).nextInt(2000)) + 2000; return p; } The issue with this code is that, what an object returns for toString() is platform- and JVM-specific and never guaranteed to be parseable as an integer. There's also no guarantee that toString() will produce anything that's at least 17 characters long. The only time the output of toString() is defined is for instances of java.lang.Object; pretty much all classes override that method. Besides the hard-coding of the 17 in the code is rather naive, converting the hex string suffers from the fact that it may be representing a negative number. The parseInt() method allows only 31 bits of magnitude for the string, since the sign must be given externally (leading '+' or '-', with '+' being the default). In many JVM implementations, the hashCode() method for non-String objects returns a value based on the allocation address of the object. For 32-bit systems, such an address is almost always under the 2 GB boundary, and therefore positive. For architectures that use more than 32 bits for an address (including the Unisys OS 2200), there's no guarantee of any particular sign of the result. We propose that the code be changed to the following: public static int getRandomStartingPort() { int n = new Object().hashCode(); int p = Math.abs(new SecureRandom(String.valueOf(System.currentTimeMillis() + n).getBytes()).nextInt(2000)) + 2000; return p; } -- 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, 6 months

3
8
0 / 0

[JBoss JIRA] Created: (JBREM-1020) Release 2.2.2.SP10

by Ron Sigal (JIRA)

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

1
1
0 / 0

[JBoss JIRA] Created: (JBREM-1037) CLONE [JBREM-1006] - SOA MTOM bug points to bug in Remoting codebase

by Ron Sigal (JIRA)

CLONE [JBREM-1006] - SOA MTOM bug points to bug in Remoting codebase --------------------------------------------------------------------- Key: JBREM-1037 URL: https://jira.jboss.org/jira/browse/JBREM-1037 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.2.2.SP7, 2.4.0.GA (Pinto) Environment: SOA 4.3.0 CP02 CR3 Reporter: Ron Sigal Assignee: Ron Sigal Priority: Minor Fix For: 2.4.0.SP1 (Pinto) SOA-568 and JBESB-1803 point to a potential bug in the HttpUnmarshaller code shipped with EAP 4.3.0 CP01. -- 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, 7 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 October 2008