January 2011 - jboss-remoting-issues

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

by Ron Sigal (JIRA)

Assure version compatibility with earlier versions of Remoting -------------------------------------------------------------- Key: JBREM-1270 URL: https://issues.jboss.org/browse/JBREM-1270 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.5.3.SP2 -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

1
2
0 / 0

[JBoss JIRA] Created: (JBREM-1269) Fix deadlock between Client and MicroRemoteClientInvoker, part 2

by Ron Sigal (JIRA)

Fix deadlock between Client and MicroRemoteClientInvoker, part 2 ---------------------------------------------------------------- Key: JBREM-1269 URL: https://issues.jboss.org/browse/JBREM-1269 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 1. a. org.jboss.remoting.MicroRemoteClientInvoker.terminateLease() synchronizes on clientLeaseLock and calls org.jboss.remoting.LeasePinger.stopPing() b. org.jboss.remoting.LeasePinger.stopPing() calls org.jboss.remoting.Client.notifyListeners(), which synchronized on connectionValidatorLock 2. a. org.jboss.remoting.Client.addConnectionListener() synchronizes on connectionValidatorLock and calls org.jboss.remoting.ConnectionValidator() b. org.jboss.remoting.ConnectionValidator() calls ConnectionValidator.getParameters() c. ConnectionValidator.getParameters() calls org.jboss.remoting.MicroRemoteClientInvoker.getLeasePinger() d. org.jboss.remoting.MicroRemoteClientInvoker.getLeasePinger() synchronized on clientLeaseLock -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
2
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, 3 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, 3 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, 3 months

1
9
0 / 0

[JBoss JIRA] Created: (JBREM-1268) RemotingClientInvoker can change configuration map and prevent InvokerRegistry from reusing client invokers

by Ron Sigal (JIRA)

RemotingClientInvoker can change configuration map and prevent InvokerRegistry from reusing client invokers ----------------------------------------------------------------------------------------------------------- Key: JBREM-1268 URL: https://issues.jboss.org/browse/JBREM-1268 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 When org.jboss.remoting.InvokerRegistry.createClientInvoker() looks to reuse an existing client invoker, it compares the InvokerLocator and the configuration map. However, if org.jboss.remoting.RemoteClientInvoker() finds "socketFactoryClassName" in the InvokerLocator, it adds it to the configuration map, so the new client invoker gets stored with an updated configuration map. When InvokerRegistry.createClientInvoker() is called again with identical parameters, it can't match the incoming configuration map with the one associated with the previously created client invoker, and it creates a new client invoker. Reported by Patrick Speer. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
3
0 / 0

[JBoss JIRA] Created: (JBREM-1267) Allow HTTPClientInvoker to call disconnect on HttpURLConnection after use

by Ron Sigal (JIRA)

Allow HTTPClientInvoker to call disconnect on HttpURLConnection after use ------------------------------------------------------------------------- Key: JBREM-1267 URL: https://issues.jboss.org/browse/JBREM-1267 Project: JBoss Remoting Issue Type: Enhancement 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 org.jboss.remoting.transport.http.HTTPClientInvoker does not currently disconnect a java.net.HttpURLConnection after each use, letting the HttpURLConnection manage its resources internally. It has been found that HttpURLConnection can leave a number of sockets in the CLOSE_WAIT, which can cause problems under heavy load. HTTPClientInvoker should offer an option to disconnect the HttpURLConnection. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
2
0 / 0

[JBoss JIRA] Resolved: (JBREM-159) Patch to enable JRockit 5.0 to work with JBoss Remoting

by Ron Sigal (JIRA)

[ https://issues.jboss.org/browse/JBREM-159?page=com.atlassian.jira.plugin.... ] Ron Sigal resolved JBREM-159. ----------------------------- Resolution: Out of Date > Patch to enable JRockit 5.0 to work with JBoss Remoting > ------------------------------------------------------- > > Key: JBREM-159 > URL: https://issues.jboss.org/browse/JBREM-159 > Project: JBoss Remoting > Issue Type: Patch > Components: general > Affects Versions: 2.2.2.GA > Reporter: Jeff Haynie > Priority: Minor > > org.jboss.remoting.detection.multicast.MulticaseDetector$Listener.run, changed: > try > { > listen(p, buf); > } > catch (Exception ex) > to: > try > { > listen(p, buf); > p.setLength(buf.length); > } > catch (Exception ex) > org.jboss.remoting.loading.ClassUtil.serialize, changed body of the method from: > java.io.ByteArrayOutputStream bos=new java.io.ByteArrayOutputStream(); > java.io.ObjectOutputStream oos=new java.io.ObjectOutputStream(bos); > oos.writeObject(obj); > oos.flush(); > bos.flush(); > byte buf[]=bos.toByteArray(); > bos=null; > oos=null; > return buf; > to: > java.io.ByteArrayOutputStream bos=new java.io.ByteArrayOutputStream(); > java.io.ObjectOutputStream oos=new java.io.ObjectOutputStream(bos); > oos.writeObject(obj); > oos.flush(); > bos.flush(); > oos.close(); > bos.close(); > byte buf[]=bos.toByteArray(); > bos=null; > oos=null; > return buf; -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (JBREM-1265) HTTPClientItnvoker leaks HttpURLConnections

by Ron Sigal (JIRA)

HTTPClientItnvoker leaks HttpURLConnections ------------------------------------------- Key: JBREM-1265 URL: https://issues.jboss.org/browse/JBREM-1265 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 org.jboss.remoting.transport.http.HTTPClientInvoker.transport() needs a finally clause to disconnect the HttpURLConnection after it has been used. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
2
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, 3 months

2
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

jboss-remoting-issues January 2011