September 2010 - jboss-remoting-issues

[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

13 years, 9 months

1
4
0 / 0

[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

13 years, 9 months

2
4
0 / 0

[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

13 years, 9 months

1
6
0 / 0

[JBoss JIRA] Created: (JBREM-1074) Config Guide should clarify the HTTP transport vs Servlet

by Andrew Oliver (JIRA)

Config Guide should clarify the HTTP transport vs Servlet --------------------------------------------------------- Key: JBREM-1074 URL: https://jira.jboss.org/jira/browse/JBREM-1074 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Andrew Oliver http://docs.jboss.org/jbossas/unified_invoker/UnifiedInvoker_guide.html describes changing to use HTTP as a transport. Meaning JBoss remoting launches its own HTTP server. This is probably a pretty esoteric configuration and most people are probably looking for this: http://www.jboss.org/community/docs/DOC-9632 instead. The guide should clarify WHAT that is and where to find what you're probably REALLY looking for. (you probably don't want to run on some weird port if you're using HTTP and most installs probably run WITH tomcat which means you need to run through TC or have a totally separate IP which is pretty hard to do in most environments) -- 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

13 years, 10 months

2
1
0 / 0

[JBoss JIRA] Created: (JBREM-1248) Avoid connecting to a server in catch clause in case of HttpClientInvoker connection failure

by Toshiya Kobayashi (JIRA)

Avoid connecting to a server in catch clause in case of HttpClientInvoker connection failure -------------------------------------------------------------------------------------------- Key: JBREM-1248 URL: https://jira.jboss.org/browse/JBREM-1248 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Components: transport Affects Versions: 2.5.3.SP1, 2.2.3.SP2 Reporter: Toshiya Kobayashi Due to a change introduced by JBREM-960 , HttpClientInvoker will try to connect to a server again by HttpURLConnection#getResponseMessage() in catch clause. try { ... OutputStream stream = conn.getOutputStream(); ... { catch (Exception e) { String message = "Can not connect http client invoker."; if (e.getMessage() != null) message += " " + e.getMessage() + "."; try { String responseMessage = conn.getResponseMessage(); int code = conn.getResponseCode(); message += " Response: " + responseMessage + "/" + code + "."; } catch (IOException e1) { log.debug("Unable to retrieve response message", e1); } throw new CannotConnectException(message, e); } This second try may succeed depending on server/network condition even if conn.getOutputStream() in try clause fails. >From a point of view of users (actually, JBossWS user), - That may consume a connection with an empty body request - On server side, they can't figure out if the empty request comes from this behaviour or just an empty request was wrongly/maliciously sent So the request is going to be - Avoid connecting to a server in catch clause in case of connection failure If that's impossible or too tricky to achieve JBREM-960 at a time, then - Provide a system property switch to skip the conn.getResponseMessage()/conn.getResponseCode() lines -- 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

13 years, 10 months

2
4
0 / 0

[JBoss JIRA] Created: (JBREM-1144) Extend connection identity to server side

by Ron Sigal (JIRA)

Extend connection identity to server side ----------------------------------------- Key: JBREM-1144 URL: https://jira.jboss.org/jira/browse/JBREM-1144 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 2.2.3, 2.5.1 (Flounder) Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.5.2 (Flounder), 2.2.3.SP1 In JBREM-1128 "Introduce connection identity concept" and JBREM-1132 "CLONE [JBREM-1128] - Introduce connection identity concept", the server was equipped to recognized when a client had been replaced by another client. In other words, clients were assigned an identity. This concept should be extended to the server side, so that ConnectionValidator can detect that a server has been replaced. -- 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

13 years, 10 months

1
9
0 / 0

[JBoss JIRA] Created: (JBREM-1242) Fix deadlock between Client and MicroRemoteClientInvoker

by Ron Sigal (JIRA)

Fix deadlock between Client and MicroRemoteClientInvoker -------------------------------------------------------- Key: JBREM-1242 URL: https://jira.jboss.org/browse/JBREM-1242 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.5.3.SP2, 2.2.3.SP4 1. a. org.jboss.remoting.Client.setupClientLease() calls MicroRemoteClientInvoker.establishLease() b. org.jboss.remoting.MicroRemoteClientInvoker.establishLease() synchronizes on MicroRemoteClientInvoker.clientLeaseLock and calls Client.addConnectionListener() c. Client.addConnectionListener() synchronizes on Client.connectionValidatorLock 2. a. Client.addConnectionListener() synchronizes on Client.connectionValidatorLock and calls new ConnectionValidator() b. new ConnectionValidator() calls MicroRemoteClientInvoker.getLeasePinger(), which synchronizes on MicroRemoteClientInvoker.clientLeaseLock -- 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

13 years, 10 months

2
2
0 / 0

[JBoss JIRA] Created: (JBREM-1226) Sockets created by bisocket secondary ServerSocket should be configured properly

by Ron Sigal (JIRA)

Sockets created by bisocket secondary ServerSocket should be configured properly -------------------------------------------------------------------------------- Key: JBREM-1226 URL: https://jira.jboss.org/browse/JBREM-1226 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.2.3.SP2, 2.5.2.SP3 (Flounder) Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.2.3.SP3, 2.5.2.SP4 (Flounder) Sockets created by org.jboss.remoting.transport.socket.SocketServerInvoker are configured by protected void configureSocket(Socket s) throws SocketException { s.setReuseAddress(getReuseAddress()); if (keepAliveSet) s.setKeepAlive(keepAlive); if (oOBInlineSet) s.setOOBInline(oOBInline); if (receiveBufferSize > -1) s.setReceiveBufferSize(receiveBufferSize); if (sendBufferSize > -1) s.setSendBufferSize(sendBufferSize); if (soLingerSet && soLingerDuration > 0) s.setSoLinger(soLinger, soLingerDuration); if (trafficClass > -1) s.setTrafficClass(trafficClass); } but configureSocket() is not called for sockets created by org.jboss.remoting.transport.bisocket.BisocketServerInvoker. -- 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

13 years, 11 months

1
5
0 / 0

[JBoss JIRA] Created: (JBREM-1247) BisocketClientInvoker$PingTimerTask NPE

by Ron Sigal (JIRA)

BisocketClientInvoker$PingTimerTask NPE --------------------------------------- Key: JBREM-1247 URL: https://jira.jboss.org/browse/JBREM-1247 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.5.3.SP1 Reporter: Ron Sigal Assignee: Ron Sigal Priority: Minor Fix For: 2.5.3.SP2 org.jboss.remoting.transport.bisocket.BisocketClientInvoker$PingTimerTask.run() checks the variable running before accessing the controlOutputStream variable, which is set to null by PingTimerTask.shutdown(). However, PingTimerTask.shutdown() doesn't set running to false. -- 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

13 years, 11 months

1
1
0 / 0

[JBoss JIRA] Created: (JBREM-1227) Fix deadlock between MicroRemoteClientInvoker and RemotingClassLoader

by Ron Sigal (JIRA)

Fix deadlock between MicroRemoteClientInvoker and RemotingClassLoader --------------------------------------------------------------------- Key: JBREM-1227 URL: https://jira.jboss.org/browse/JBREM-1227 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.5.2.SP3 (Flounder) Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.5.2.SP4 (Flounder) The following deadlock can occur: 1. Thread T1 reads a response with an object whose class is not available locally, so it uses its org.jboss.remoting.loading.RemotingClassLoader to try to download the class a. java.lang.ClassLoader.loadClassInternal() acquires a lock on itself (an instance of RemotingClassLoader) b. RemotingClassLoader uses its copy of an org.jboss.remoting.loading.ClassByteClassLoader to try to download the class c. ClassByteClassLoader calls org.jboss.remoting.MicroRemoteClientInvoker.invoke(), which tries to synchronize on MicroRemoteClientInvoker.class as it sets up an UnMarshaller with a ClassLoader 2. Thread T2 attempts to make an invocation a. MicroRemoteClientInvoker.invoke() acquires a lock on MicroRemoteClientInvoker.class b. MicroRemoteClientInvoker.invoke() calls the synchronized method RemotingClassLoader.setUserClassLoader(), which tries to acquire a lock on the RemotingClassLoader Deadlock. The only two synchronized methods in RemotingClassLoader are setUserClassLoader() and unsetUserClassLoader(), which are both called from MicroRemoteClientInvoker.invoke(). The call to setUserClassLoader() is already done while the MicroRemoteClientInvoker.class lock is held. If the call to unsetUserClassLoader() is made with the same lock, then setUserClassLoader() and unsetClassLoader() don't have to be synchronized. That will eliminate the deadlock because step 2b is removed. -- 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

13 years, 11 months

1
6
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

jboss-remoting-issues September 2010