[JBoss JIRA] Closed: (JBREM-732) When server terminates and has clients, when the server comes back up clients that survived, can't connect. Connection refused when trying to connect the control socket.
by Ron Sigal (JIRA)
[ http://jira.jboss.com/jira/browse/JBREM-732?page=all ]
Ron Sigal closed JBREM-732.
---------------------------
Resolution: Done
> When server terminates and has clients, when the server comes back up clients that survived, can't connect. Connection refused when trying to connect the control socket.
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBREM-732
> URL: http://jira.jboss.com/jira/browse/JBREM-732
> Project: JBoss Remoting
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 2.2.0.GA (Bluto)
> Reporter: Jay Howell
> Assigned To: Ron Sigal
> Fix For: 2.4.0.Beta1 (Pinto)
>
>
> A client survives a server outage. When the server comes back up the survivor client tries to re-establish communictions and can't because the server is refusing the control socket connections.
> New clients are able to connect fine. This happens intermittantly.
> Here's the stack trace .....
> [2007-03-30 10:47:51,770 ERROR] [Thread-10] bisocket.BisocketServerInvoker - [unable to create control connection after 10 retries]
> java.net.ConnectException: Connection refused: connect
> at java.net.PlainSocketImpl.socketConnect(Native Method)
> at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)
> at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195)
> at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)
> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
> at java.net.Socket.connect(Socket.java:519)
> at java.net.Socket.connect(Socket.java:469)
> at java.net.Socket.<init>(Socket.java:366)
> at java.net.Socket.<init>(Socket.java:179)
> at org.jboss.remoting.transport.bisocket.BisocketServerInvoker.createControlConnection(BisocketServerInvoker.java:217)
> at org.jboss.remoting.transport.bisocket.BisocketClientInvoker.transport(BisocketClientInvoker.java:328)
> at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:122)
> at org.jboss.remoting.Client.invoke(Client.java:1544)
> at org.jboss.remoting.Client.addCallbackListener(Client.java:1613)
> at org.jboss.remoting.Client.addListener(Client.java:907)
> at org.jboss.jms.client.remoting.JMSRemotingConnection.addInvokerCallbackHandler(JMSRemotingConnection.java:221)
> at org.jboss.jms.client.remoting.JMSRemotingConnection.start(JMSRemotingConnection.java:287)
> at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate.org$jboss$jms$client$delegate$ClientConnectionFactoryDelegate$createConnectionDelegate$aop(ClientConnectionFactoryDelegate.java:146)
> at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate$createConnectionDelegate_4579211046834694258.invokeNext(ClientConnectionFactoryDelegate$createConnectionDelegate_4579211046834694258.java)
> at org.jboss.jms.client.container.StateCreationAspect.handleCreateConnectionDelegate(StateCreationAspect.java:83)
> at org.jboss.aop.advice.org.jboss.jms.client.container.StateCreationAspect0.invoke(StateCreationAspect0.java)
> at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate$createConnectionDelegate_4579211046834694258.invokeNext(ClientConnectionFactoryDelegate$createConnectionDelegate_4579211046834694258.java)
> at org.jboss.jms.client.container.ExceptionInterceptor.invoke(ExceptionInterceptor.java:71)
> at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate$createConnectionDelegate_4579211046834694258.invokeNext(ClientConnectionFactoryDelegate$createConnectionDelegate_4579211046834694258.java)
> at org.jboss.jms.client.container.ClientLogInterceptor.invoke(ClientLogInterceptor.java:107)
> at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate$createConnectionDelegate_4579211046834694258.invokeNext(ClientConnectionFactoryDelegate$createConnectionDelegate_4579211046834694258.java)
> at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate.createConnectionDelegate(ClientConnectionFactoryDelegate.java)
> at org.jboss.jms.client.JBossConnectionFactory.createConnectionInternal(JBossConnectionFactory.java:205)
> at org.jboss.jms.client.JBossConnectionFactory.createConnection(JBossConnectionFactory.java:87)
> at org.jboss.jms.client.JBossConnectionFactory.createConnection(JBossConnectionFactory.java:82)
> at com.rbos.fx.eCommerce.spreading.messaging.JMSConnector.makeConnection(JMSConnector.java:166)
> at com.rbos.fx.eCommerce.spreading.messaging.JMSConnector.getConnection(JMSConnector.java:141)
> at com.rbos.fx.eCommerce.spreading.messaging.JMSConnector$JMSExceptionListener.onException(JMSConnector.java:188)
> at org.jboss.jms.client.remoting.ConsolidatedRemotingConnectionListener.handleConnectionException(ConsolidatedRemotingConnectionListener.java:115)
> at org.jboss.remoting.ConnectionValidator$1.run(ConnectionValidator.java:346)
--
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, 11 months
[JBoss JIRA] Reopened: (JBREM-732) When server terminates and has clients, when the server comes back up clients that survived, can't connect. Connection refused when trying to connect the control socket.
by Ron Sigal (JIRA)
[ http://jira.jboss.com/jira/browse/JBREM-732?page=all ]
Ron Sigal reopened JBREM-732:
-----------------------------
> When server terminates and has clients, when the server comes back up clients that survived, can't connect. Connection refused when trying to connect the control socket.
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBREM-732
> URL: http://jira.jboss.com/jira/browse/JBREM-732
> Project: JBoss Remoting
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 2.2.0.GA (Bluto)
> Reporter: Jay Howell
> Assigned To: Ron Sigal
> Fix For: 2.2.0.SP1
>
>
> A client survives a server outage. When the server comes back up the survivor client tries to re-establish communictions and can't because the server is refusing the control socket connections.
> New clients are able to connect fine. This happens intermittantly.
> Here's the stack trace .....
> [2007-03-30 10:47:51,770 ERROR] [Thread-10] bisocket.BisocketServerInvoker - [unable to create control connection after 10 retries]
> java.net.ConnectException: Connection refused: connect
> at java.net.PlainSocketImpl.socketConnect(Native Method)
> at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)
> at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195)
> at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)
> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
> at java.net.Socket.connect(Socket.java:519)
> at java.net.Socket.connect(Socket.java:469)
> at java.net.Socket.<init>(Socket.java:366)
> at java.net.Socket.<init>(Socket.java:179)
> at org.jboss.remoting.transport.bisocket.BisocketServerInvoker.createControlConnection(BisocketServerInvoker.java:217)
> at org.jboss.remoting.transport.bisocket.BisocketClientInvoker.transport(BisocketClientInvoker.java:328)
> at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:122)
> at org.jboss.remoting.Client.invoke(Client.java:1544)
> at org.jboss.remoting.Client.addCallbackListener(Client.java:1613)
> at org.jboss.remoting.Client.addListener(Client.java:907)
> at org.jboss.jms.client.remoting.JMSRemotingConnection.addInvokerCallbackHandler(JMSRemotingConnection.java:221)
> at org.jboss.jms.client.remoting.JMSRemotingConnection.start(JMSRemotingConnection.java:287)
> at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate.org$jboss$jms$client$delegate$ClientConnectionFactoryDelegate$createConnectionDelegate$aop(ClientConnectionFactoryDelegate.java:146)
> at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate$createConnectionDelegate_4579211046834694258.invokeNext(ClientConnectionFactoryDelegate$createConnectionDelegate_4579211046834694258.java)
> at org.jboss.jms.client.container.StateCreationAspect.handleCreateConnectionDelegate(StateCreationAspect.java:83)
> at org.jboss.aop.advice.org.jboss.jms.client.container.StateCreationAspect0.invoke(StateCreationAspect0.java)
> at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate$createConnectionDelegate_4579211046834694258.invokeNext(ClientConnectionFactoryDelegate$createConnectionDelegate_4579211046834694258.java)
> at org.jboss.jms.client.container.ExceptionInterceptor.invoke(ExceptionInterceptor.java:71)
> at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate$createConnectionDelegate_4579211046834694258.invokeNext(ClientConnectionFactoryDelegate$createConnectionDelegate_4579211046834694258.java)
> at org.jboss.jms.client.container.ClientLogInterceptor.invoke(ClientLogInterceptor.java:107)
> at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate$createConnectionDelegate_4579211046834694258.invokeNext(ClientConnectionFactoryDelegate$createConnectionDelegate_4579211046834694258.java)
> at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate.createConnectionDelegate(ClientConnectionFactoryDelegate.java)
> at org.jboss.jms.client.JBossConnectionFactory.createConnectionInternal(JBossConnectionFactory.java:205)
> at org.jboss.jms.client.JBossConnectionFactory.createConnection(JBossConnectionFactory.java:87)
> at org.jboss.jms.client.JBossConnectionFactory.createConnection(JBossConnectionFactory.java:82)
> at com.rbos.fx.eCommerce.spreading.messaging.JMSConnector.makeConnection(JMSConnector.java:166)
> at com.rbos.fx.eCommerce.spreading.messaging.JMSConnector.getConnection(JMSConnector.java:141)
> at com.rbos.fx.eCommerce.spreading.messaging.JMSConnector$JMSExceptionListener.onException(JMSConnector.java:188)
> at org.jboss.jms.client.remoting.ConsolidatedRemotingConnectionListener.handleConnectionException(ConsolidatedRemotingConnectionListener.java:115)
> at org.jboss.remoting.ConnectionValidator$1.run(ConnectionValidator.java:346)
--
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, 11 months
[JBoss JIRA] Updated: (JBREM-653) allow user to set content-type for http responses
by Ron Sigal (JIRA)
[ http://jira.jboss.com/jira/browse/JBREM-653?page=all ]
Ron Sigal updated JBREM-653:
----------------------------
Fix Version/s: 2.4.0.Beta1 (Pinto)
(was: 2.2.2.SP1)
Added fix version 2.4.0.Beta1.
> allow user to set content-type for http responses
> -------------------------------------------------
>
> Key: JBREM-653
> URL: http://jira.jboss.com/jira/browse/JBREM-653
> Project: JBoss Remoting
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: transport
> Affects Versions: 2.2.2.GA
> Reporter: Tom Elrod
> Assigned To: Ron Sigal
> Fix For: 2.4.0.Beta1 (Pinto)
>
> Attachments: CoyoteInvoker.java.patch
>
>
> Currently the CoyoteInvoker.versionedWrite() method will set the content type of the http response by using WebUtil.getContentType(responseObject) to identify the content type based on the response object type being sent back to client.
> Should allow this to be overriden by the user in the same way the response code/message can be (using the response map).
--
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, 11 months
[JBoss JIRA] Created: (JBREM-980) ServerInvokerServlet should retrieve ServletServerInvoker based on updated InvokerLocator
by Ron Sigal (JIRA)
ServerInvokerServlet should retrieve ServletServerInvoker based on updated InvokerLocator
-----------------------------------------------------------------------------------------
Key: JBREM-980
URL: http://jira.jboss.com/jira/browse/JBREM-980
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 2.4.0.CR2
Reporter: Ron Sigal
Assigned To: Ron Sigal
Fix For: 2.4.0.GA
>From Galder:
Consider
<servlet>
<servlet-name>Ejb3ServerInvokerServlet</servlet-name>
<description>The ServerInvokerServlet receives requests via HTTP
protocol from within a web container and passes it onto the
ServletServerInvoker for processing.
</description>
<servlet-class>org.jboss.remoting.transport.servlet.web.ServerInvokerServlet</servlet-class>
<init-param>
<param-name>locatorUrl</param-name>
<param-value>servlet://${jboss.bind.address}:8080/unified-invoker/Ejb3ServerInvokerServlet</param-value>
<description>The servlet server invoker</description>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
Now, let's say you bind to 0.0.0.0. You'll get an exception like this:
13:39:26,856 ERROR [ContainerBase] Servlet /unified-invoker threw load() exception
javax.servlet.ServletException: Can not find servlet server invoker with same locator as specified (servlet://0.0.0.0:8080/unified-invoker/Ejb3ServerInvokerServlet)
at org.jboss.remoting.transport.servlet.web.ServerInvokerServlet.getInvokerFromInvokerUrl(ServerInvokerServlet.java:198)
at org.jboss.remoting.transport.servlet.web.ServerInvokerServlet.init(ServerInvokerServlet.java:66)
The problem arises from the fact that Remoting is trying to compare:
servlet://0.0.0.0:8080/unified-invoker/Ejb3ServerInvokerServlet
with
servlet://localhost.localdomain:8080/unified-invoker/Ejb3ServerInvokerServlet
So either, ServerInvokerServlet should call ServerInvoker.validateLocator() with locatorUrl, take the return of that and compare that with the list of locators.
Or validateLocator() is modified to have the real original host passed to the InvokerLocator constructor, rather than the transformed or newHost.
--
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, 11 months
[JBoss JIRA] Created: (JBREM-979) Add invocation retry facility to http transport
by Ron Sigal (JIRA)
Add invocation retry facility to http transport
-----------------------------------------------
Key: JBREM-979
URL: http://jira.jboss.com/jira/browse/JBREM-979
Project: JBoss Remoting
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Affects Versions: 2.4.0.CR2
Reporter: Ron Sigal
Assigned To: Ron Sigal
Fix For: 2.4.0.GA
The test org.jboss.test.remoting.transport.http.keep_alive.StressHTTPInvokerTestCase is failing occasionally with
testPostInvocation(org.jboss.test.remoting.transport.http.keep_alive.StressHTTPInvokerTestClient)java.lang.Exception: org.jboss.remoting.CannotConnectException: Can not connect http client invoker.
at org.jboss.test.remoting.transport.web.WebInvokerTestClient.testPostInvocationSub(WebInvokerTestClient.java:153)
at org.jboss.test.remoting.transport.web.WebInvokerTestClient.testPostInvocation(WebInvokerTestClient.java:54)
at org.jboss.test.remoting.transport.http.keep_alive.StressHTTPInvokerTestClient.testPostInvocation(StressHTTPInvokerTestClient.java:55)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at org.jboss.jrunit.harness.ServerTestHarness.executeTestSuite(ServerTestHarness.java:302)
at org.jboss.jrunit.harness.ServerTestHarness.access$000(ServerTestHarness.java:51)
at org.jboss.jrunit.harness.ServerTestHarness$2.run(ServerTestHarness.java:225)
Caused by: org.jboss.remoting.CannotConnectException: Can not connect http client invoker.
at org.jboss.remoting.transport.http.HTTPClientInvoker.useHttpURLConnection(HTTPClientInvoker.java:346)
at org.jboss.remoting.transport.http.HTTPClientInvoker.transport(HTTPClientInvoker.java:146)
at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:177)
at org.jboss.remoting.Client.invoke(Client.java:1708)
at org.jboss.remoting.Client.invoke(Client.java:612)
at org.jboss.test.remoting.transport.web.WebInvokerTestClient.makeExceptionInvocation(WebInvokerTestClient.java:215)
at org.jboss.test.remoting.transport.web.WebInvokerTestClient.testPostInvocationSub(WebInvokerTestClient.java:148)
... 20 more
Caused by: java.io.IOException: Stream closed.
at java.net.PlainSocketImpl.available(PlainSocketImpl.java:428)
at java.net.SocketInputStream.available(SocketInputStream.java:217)
at java.io.BufferedInputStream.read(BufferedInputStream.java:321)
at sun.net.www.MeteredStream.read(MeteredStream.java:116)
at java.io.FilterInputStream.read(FilterInputStream.java:111)
at sun.net.www.protocol.http.HttpURLConnection$HttpInputStream.read(HttpURLConnection.java:2196)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
at java.io.BufferedInputStream.read1(BufferedInputStream.java:256)
at java.io.BufferedInputStream.read(BufferedInputStream.java:313)
at java.io.ObjectInputStream$PeekInputStream.read(ObjectInputStream.java:2213)
at java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2226)
at java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:2694)
at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:761)
at java.io.ObjectInputStream.<init>(ObjectInputStream.java:277)
at org.jboss.remoting.loading.ObjectInputStreamWithClassLoader.<init>(ObjectInputStreamWithClassLoader.java:98)
at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.createInput(JavaSerializationManager.java:54)
at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.getMarshallingStream(SerializableUnMarshaller.java:75)
at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:122)
at org.jboss.remoting.marshal.http.HTTPUnMarshaller.read(HTTPUnMarshaller.java:71)
at org.jboss.remoting.transport.http.HTTPClientInvoker.readResponse(HTTPClientInvoker.java:496)
at org.jboss.remoting.transport.http.HTTPClientInvoker.useHttpURLConnection(HTTPClientInvoker.java:317)
... 26 more
It looks like the HttpURLConnection has returned a cached connection, the HTTPClientInvoker writes the invocation, and then it turns out that the server has closed the connection. It would be useful to add a retry facility parallel to the one in the socket transport.
--
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, 12 months
[JBoss JIRA] Created: (JBREM-976) CLONE [JBREM-912] - Remove stacktrace when SSLSocketBuilder.createSSLSocketFactory() fails
by Ron Sigal (JIRA)
CLONE [JBREM-912] - Remove stacktrace when SSLSocketBuilder.createSSLSocketFactory() fails
------------------------------------------------------------------------------------------
Key: JBREM-976
URL: http://jira.jboss.com/jira/browse/JBREM-976
Project: JBoss Remoting
Issue Type: Task
Security Level: Public (Everyone can see)
Affects Versions: 2.2.0.SP4
Reporter: Ron Sigal
Assigned To: Ron Sigal
Priority: Minor
Fix For: 2.2.2.SP7
Remoting is too noisy in places when org.jboss.remoting.security.SSLSocketBuilder.createSSLSocketFactory() fails. In particular,
org.jboss.remoting.transport.http.ssl.HTTPSClientInvoker.createSocketFactory()
org.jboss.remoting.transport.sslbisocket.BisocketClientInvoker.createSocketFactory()
org.jboss.remoting.transport.sslbisocket.BisocketServerInvoker.createSocketFactory()
org.jboss.remoting.transport.bisocket.SocketClientInvoker.createSocketFactory()
print stacktraces at ERROR log level. It would be better if they just printed a message at ERROR level and saved the stacktrace for DEBUG level.
--
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
16 years
[JBoss JIRA] Created: (JBREM-970) Enhance client-side error reporting so a misspelled truststore file name required by SSL can be easily spotted
by Ovidiu Feodorov (JIRA)
Enhance client-side error reporting so a misspelled truststore file name required by SSL can be easily spotted
--------------------------------------------------------------------------------------------------------------
Key: JBREM-970
URL: http://jira.jboss.com/jira/browse/JBREM-970
Project: JBoss Remoting
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Affects Versions: 2.2.2.SP7
Reporter: Ovidiu Feodorov
Assigned To: Ovidiu Feodorov
Priority: Minor
A misspelled client-side truststore file name causes a remoting connection to fail with a misleading error message:
Exception in thread "main" org.jboss.remoting.CannotConnectException: Can not get connection to server. Problem establishing socket connection for InvokerLocator [sslsocket://192.168.67.164:3874/]
at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:530)
at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:122)
[...]
Caused by: java.net.SocketException: Socket Closed
at java.net.PlainSocketImpl.setOption(PlainSocketImpl.java:201)
at java.net.Socket.setSoTimeout(Socket.java:997)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.setSoTimeout(SSLSocketImpl.java:2047)
[...]
There's nothing in the stacktrace hinting towards the root cause of the problem, and this could make the debugging quite laborious and time consuming.
A welcome improvement would be to identify and loudly advertise the root cause of the problem (or at least problems related to the fact that the SSL handshake did not succeed)
--
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
16 years
[JBoss JIRA] Created: (JBREM-971) Enhance client-side connection error handling so certain (potentially revealing) socket-related exceptins are not discarded
by Ovidiu Feodorov (JIRA)
Enhance client-side connection error handling so certain (potentially revealing) socket-related exceptins are not discarded
---------------------------------------------------------------------------------------------------------------------------
Key: JBREM-971
URL: http://jira.jboss.com/jira/browse/JBREM-971
Project: JBoss Remoting
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Affects Versions: 2.2.2.SP7
Reporter: Ovidiu Feodorov
Assigned To: Ovidiu Feodorov
Priority: Minor
A SSL connection (for example) may fail due to handshake problems, but Remoting would discard the original exception and throw a different and less relevant exception, thus hiding the original cause of the error.
Example:
The server reports
Caused by: java.net.SocketException: Socket Closed
at java.net.PlainSocketImpl.setOption(Unknown Source)
at java.net.Socket.setSoTimeout(Unknown Source)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.setSoTimeout(Unknown Source)
at org.jboss.remoting.transport.socket.SocketWrapper.setTimeout(SocketWrapper.java:85)
at org.jboss.remoting.transport.socket.ClientSocketWrapper.createStreams(ClientSocketWrapper.java:168)
at org.jboss.remoting.transport.socket.ClientSocketWrapper.<init>(ClientSocketWrapper.java:66)
while in fact the root problem is:
14:39:38,174 ERROR [STDERR] javax.net.ssl.SSLException: Received fatal alert: internal_error
14:39:38,175 ERROR [STDERR] at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:190)
14:39:38,175 ERROR [STDERR] at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:136)
14:39:38,175 ERROR [STDERR] at com.sun.net.ssl.internal.ssl.SSLSocketImpl.recvAlert(SSLSocketImpl.java:1657)
14:39:38,175 ERROR [STDERR] at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:932)
14:39:38,175 ERROR [STDERR] at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1096)
14:39:38,175 ERROR [STDERR] at com.sun.net.ssl.internal.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:623)
14:39:38,175 ERROR [STDERR] at com.sun.net.ssl.internal.ssl.AppOutputStream.write(AppOutputStream.java:59)
14:39:38,175 ERROR [STDERR] at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)
This makes troubleshooting of a potential simple problem such a misspelled truststore file name laborious and time consuming.
The server-side code could be modified to log relevant exceptions.
--
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
16 years