[JBoss JIRA] Created: (JBREM-1263) ClientSocketWrapper.checkConnection() should check returned value
by Ron Sigal (JIRA)
ClientSocketWrapper.checkConnection() should check returned value
-----------------------------------------------------------------
Key: JBREM-1263
URL: https://issues.jboss.org/browse/JBREM-1263
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 2.2.3.SP3, 2.5.3.SP1
Reporter: Ron Sigal
Assignee: Ron Sigal
Fix For: 2.5.3.SP2, 2.2.3.SP4
The old and new connection checking tests used by org.jboss.remoting.transport.socket.ClientSocketWrapper and ServerSocketWrapper interact in a negative way. In the old test, turned on when socket.check_connection is set to true, ClientSocketWrapper sends a 1, ServerSocketWrapper returns it, and if ClientSocketWrapper is able to read a byte, the test passes. But in the new test, ServerSocketWrapper writes two 254 bytes as it is closing. If ClientSocketWrapper is doing the old test and it reads one of these bytes, it thinks the test has passed. It should check for the actual value of the returned byte.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 3 months
[JBoss JIRA] Created: (JBREM-1246) Can't authenticate using TransporterClient
by Sebastian Dietrich (JIRA)
Can't authenticate using TransporterClient
------------------------------------------
Key: JBREM-1246
URL: https://jira.jboss.org/browse/JBREM-1246
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 2.5.2.SP3 (Flounder)
Reporter: Sebastian Dietrich
I'd like to introduce basic authentication in my project which uses TransporterClient to connect to the server. According to the documentation (http://docs.jboss.org/jbossremoting/2.5.3.SP1/html_single/#d0e2251 5.4.11. HTTP(S) Client Invoker - proxy and basic authentication) this is not supported with TransporterClient, but only via response = client.invoke(payload, metadata);
TransporterClient uses response = remotingClient.invoke(request); (see TransporterClient.class Line 321)
Unfortunately I can neither subclass TransporterClient (since its constructors are private) nor decorate it (since its invoke method I'd like to change uses private attributes & methods).
==> Please provide a way to use basic authentication in TransporterClient
This could be done easily via a further constructor/factory method which accepts metadata.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 3 months
[JBoss JIRA] Created: (JBREM-1245) Consider javax.net.ssl.SSLException("Connection has been shutdown")
by Ron Sigal (JIRA)
Consider javax.net.ssl.SSLException("Connection has been shutdown")
-------------------------------------------------------------------
Key: JBREM-1245
URL: https://jira.jboss.org/browse/JBREM-1245
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 2.5.3.SP1, 2.2.3.SP3
Reporter: Ron Sigal
Assignee: Ron Sigal
Fix For: 2.2.3.SP3, 2.2.3.SP4
An SSLSocket whose remote counterpart has closed will throw
javax.net.ssl.SSLException: Connection has been shutdown: javax.net.ssl.SSLException: java.net.SocketException: Software caused connection abort: socket write error
This should be considered a retriable exception, but the RETRIABLE_ERROR_MESSAGE regular expression in org.jboss.remoting.transport.MicroSocketClientInvoker doesn't match it.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 3 months
[JBoss JIRA] Created: (JBREM-1238) Need invocation timeouts in synchronized blocks in MicroRemoteClientInvoker that create and terminate leases
by Ron Sigal (JIRA)
Need invocation timeouts in synchronized blocks in MicroRemoteClientInvoker that create and terminate leases
-------------------------------------------------------------------------------------------------------------
Key: JBREM-1238
URL: https://jira.jboss.org/browse/JBREM-1238
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 2.5.3.SP1
Reporter: Ron Sigal
Assignee: Ron Sigal
Fix For: 2.5.2.SP2 (Flounder)
org.jboss.remoting.MicroRemoteClientInvoker.establishLease() and MicroRemoteClientInvoker.terminateLease() do network invocations inside synchronized blocks, and, if the invocations get hung up, then it becomes impossible to create new connections with leasing enabled. Setting the 'timeout" parameter appropriately would work around the problem, but some users, notably JBossMessaging, set "timeout" to 0.
A speclal case timeout parameter should be used, along with the per invocation timeout facility, to prevent MicroRemoteClientInvoker from getting stuck in establishLease() or terminateLease().
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 3 months