October 2009 - jboss-remoting-issues

[JBoss JIRA] Created: (JBREM-1161) Evaluate FindBugs reports

by Ron Sigal (JIRA)

Evaluate FindBugs reports ------------------------- Key: JBREM-1161 URL: https://jira.jboss.org/jira/browse/JBREM-1161 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.2.3.SP2 http://hudson.jboss.org/hudson/view/JBoss%20AS/job/JBoss-AS-6.0.x-findbug... and http://hudson.jboss.org/hudson/view/JBoss%20AS/job/JBoss-AS-5.x-findbugs/... -- 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

14 years, 9 months

1
6
0 / 0

[JBoss JIRA] Created: (JBREM-1164) Remoting shouldn't require IPv6 addresses to be surrounded by brackets

by Ron Sigal (JIRA)

Remoting shouldn't require IPv6 addresses to be surrounded by brackets ---------------------------------------------------------------------- Key: JBREM-1164 URL: https://jira.jboss.org/jira/browse/JBREM-1164 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.5.2 (Flounder) Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.5.2.SP1 (Flounder) Although IPv6 addresses are surrounded by brackets in URLs, the addresses themselves don't have brackets. Thus, it should be possible to start the Application Server with run.sh -b ::1 instead of requiring run.sh -b [::1] -- 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

14 years, 10 months

3
17
0 / 0

[JBoss JIRA] Created: (JBREM-1162) Release 2.5.2.SP1

by Ron Sigal (JIRA)

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

14 years, 11 months

1
2
0 / 0

[JBoss JIRA] Created: (JBREM-1096) Remoting 2 entity metadata

by David Lloyd (JIRA)

Remoting 2 entity metadata -------------------------- Key: JBREM-1096 URL: https://jira.jboss.org/jira/browse/JBREM-1096 Project: JBoss Remoting Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: David Lloyd -- 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

14 years, 11 months

1
2
0 / 0

[JBoss JIRA] Created: (JBREM-1153) Malformed Method line in HTTP requests thru HTTP Proxy

by Gerald Turner (JIRA)

Malformed Method line in HTTP requests thru HTTP Proxy ------------------------------------------------------ Key: JBREM-1153 URL: https://jira.jboss.org/jira/browse/JBREM-1153 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Components: transport Affects Versions: 2.2.2.SP8 Environment: JBoss 4.2.3.GA patched with JBossWS 3.0.5 Reporter: Gerald Turner Attachments: jbossws-noproxy.cap, jbossws-proxy.cap Invoking a web service with http.proxyHost and http.proxyPort System properties is broken. It produces a request like the following: POST http://btnwks10.corp.inthosts.net:9090/HVODWebService/Import HTTP/1.1 Authorization: Basic b5V0am91bmR5ZbN0ZXI6bH5cdW9yT3Aw SOAPAction: "" Content-Type: text/xml; charset=UTF-8 JBoss-Remoting-Version: 22 User-Agent: JBossRemoting - 2.2.2.SP8 Host: btnwks10.corp.inthosts.net:9090 Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2 Proxy-Connection: keep-alive Transfer-Encoding: chunked With the System properties removed, the request is sent correctly: POST /HVODWebService/Import HTTP/1.1 Authorization: Basic b5V0am91bmR5ZbN0ZXI6bH5cdW9yT3Aw SOAPAction: "" Content-Type: text/xml; charset=UTF-8 JBoss-Remoting-Version: 22 User-Agent: JBossRemoting - 2.2.2.SP8 Host: btnwks10.corp.inthosts.net:9090 Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2 Connection: keep-alive Transfer-Encoding: chunked Bug appears to be exactly as described in JBREM-569, however that bug claims to have been fixed in 2.0.0.GA, maybe a regression occurred? -- 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

14 years, 11 months

3
9
0 / 0

[JBoss JIRA] Created: (JBREM-1160) CLONE -Version compatibility problem with leasing

by Ron Sigal (JIRA)

CLONE -Version compatibility problem with leasing ------------------------------------------------- Key: JBREM-1160 URL: https://jira.jboss.org/jira/browse/JBREM-1160 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.5.1 (Flounder) Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.5.2 (Flounder) If "useClientConnectionIdentity" is set to "true, then org.jboss.remoting.ServerInvoker.updateClientLease() tries to get a leasePingerId from the request map and compare it to the leasePingerId in a Lease. But if the InvocationRequest came from an older client that doesn't know about connection identity, the value of leasePingerId is null. The test calls leasePingerId.equals(clientLease.getLeasePingerId() which causes a NullPointerException. The test should be reversed. Also, org.jboss.test.remoting.versioning.lease.LeaseVersionTestCase should be strengthened to catch this problem. -- 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

14 years, 11 months

1
3
0 / 0

[JBoss JIRA] Created: (JBREM-998) JBoss Serailization 1.0.3 does not work. Make sure a new Serializtion jar gets sent out with this fix with remoting.

by Jay Howell (JIRA)

JBoss Serailization 1.0.3 does not work. Make sure a new Serializtion jar gets sent out with this fix with remoting. --------------------------------------------------------------------------------------------------------------------- Key: JBREM-998 URL: http://jira.jboss.com/jira/browse/JBREM-998 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Components: serialization Affects Versions: 2.2.2.SP7 Reporter: Jay Howell Priority: Critical Jboss serialization is broken. We need to make sure that we fix http://jira.jboss.org/jira/browse/JBSER-108 and it gets out with future versions of remoting. -- 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

14 years, 11 months

2
1
0 / 0

[JBoss JIRA] Created: (JBREM-947) ConnectionValidator hangs when server dies

by Tim Fox (JIRA)

ConnectionValidator hangs when server dies ------------------------------------------ Key: JBREM-947 URL: http://jira.jboss.com/jira/browse/JBREM-947 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Tim Fox Fix For: 2.2.2.SP7 If the connection between client and server is pulled (pull the real cable) or the entire server suddenly dies, then the connection won't be closed from the server (unlike a kill -9 of the server where the OS will terminate that processses connections), so the client making the write() or read() on the socket won't receive an exception. In the eyes of TCP the connection is still alive and the read/write will block until the socket timeout is reached. Typically the socket timeout will be much higher than the desired failure detection time (the validation interval), but currently failure will never be detected in this situation before the socket timeout time. Remoting should not be dependent on the socket timeout for failure detection, the connetion validation and socket timeout should be possible to be configured separately. E.g. you might want to configure a socket timeout of 60 seconds, but a connection validation frequency (ping) of 5 seconds. Currently this is not possible. The current implementation gives inconsistent behaviour depending on how the server died - i.e. whether the process died (e.g. kill -9) or the cable was pulled or the entire server disappeared. -- 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

3
9
0 / 0

[JBoss JIRA] Created: (JBREM-949) CLONE [JBREM-947] - ConnectionValidator hangs when server dies

by Ron Sigal (JIRA)

CLONE [JBREM-947] - ConnectionValidator hangs when server dies -------------------------------------------------------------- Key: JBREM-949 URL: http://jira.jboss.com/jira/browse/JBREM-949 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.2.2.SP7 Reporter: Tim Fox Assigned To: Ron Sigal Fix For: 2.4.0.GA If the connection between client and server is pulled (pull the real cable) or the entire server suddenly dies, then the connection won't be closed from the server (unlike a kill -9 of the server where the OS will terminate that processses connections), so the client making the write() or read() on the socket won't receive an exception. In the eyes of TCP the connection is still alive and the read/write will block until the socket timeout is reached. Typically the socket timeout will be much higher than the desired failure detection time (the validation interval), but currently failure will never be detected in this situation before the socket timeout time. Remoting should not be dependent on the socket timeout for failure detection, the connetion validation and socket timeout should be possible to be configured separately. E.g. you might want to configure a socket timeout of 60 seconds, but a connection validation frequency (ping) of 5 seconds. Currently this is not possible. The current implementation gives inconsistent behaviour depending on how the server died - i.e. whether the process died (e.g. kill -9) or the cable was pulled or the entire server disappeared. -- 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

2
5
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

jboss-remoting-issues October 2009