September 2009 - jboss-remoting-issues

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

by Ron Sigal (JIRA)

Assure version compatibility with earlier versions of Remoting -------------------------------------------------------------- Key: JBREM-1155 URL: https://jira.jboss.org/jira/browse/JBREM-1155 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.5.0.SP2 (Flounder) Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.5.2 (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

15 years, 2 months

1
1
0 / 0

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

by Ron Sigal (JIRA)

Version compatibility problem with leasing ------------------------------------------ Key: JBREM-1159 URL: https://jira.jboss.org/jira/browse/JBREM-1159 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

15 years, 2 months

1
1
0 / 0

[JBoss JIRA] Created: (JBREM-1158) Update jars to match AS 5.2.0.Beta2

by Ron Sigal (JIRA)

Update jars to match AS 5.2.0.Beta2 ----------------------------------- Key: JBREM-1158 URL: https://jira.jboss.org/jira/browse/JBREM-1158 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Reporter: Ron Sigal The jars used by the test suite should match those in the target version of the application server. -- 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

15 years, 2 months

1
3
0 / 0

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

by Ron Sigal (JIRA)

Assure version compatibility with earlier versions of Remoting -------------------------------------------------------------- Key: JBREM-1156 URL: https://jira.jboss.org/jira/browse/JBREM-1156 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.2.3.SP1 Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.2.3.SP1 -- 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

15 years, 2 months

1
2
0 / 0

[JBoss JIRA] Created: (JBREM-1140) Bisocket client cannot detect connection failure

by David Lloyd (JIRA)

Bisocket client cannot detect connection failure ------------------------------------------------ Key: JBREM-1140 URL: https://jira.jboss.org/jira/browse/JBREM-1140 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Components: transport Reporter: David Lloyd Assignee: David Lloyd Fix For: 2.2.3.SP1 The BisocketClientInvoker never reads from the control socket. Therefore, it might take a long time for it to notice that the control connection dies, causing confusion between the client and server (for example, the client may reuse a listener ID that the server considers extinct). By adding a ping reply mechanism, the client must both send and receive a ping for the connection to be known "good", which should help speed up the dead connection detection process. Since this change is protocol-incompatible, it should be enabled by a configuration option. I'm using Bisocket.ENABLE_PING_REPLY = "enablePingReply" for this purpose. -- 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

15 years, 2 months

2
5
0 / 0

[JBoss JIRA] Created: (JBREM-1154) Client.connect() should throw an exception when Lease creation fails

by Ron Sigal (JIRA)

Client.connect() should throw an exception when Lease creation fails -------------------------------------------------------------------- Key: JBREM-1154 URL: https://jira.jboss.org/jira/browse/JBREM-1154 Project: JBoss Remoting Issue Type: Bug 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 When any of the versions of org.jboss.remoting.Client.connect() is called, it will try, if leasing is enabled, to register the Client with an org.jboss.remoting.Lease on the server side. Client.connect() calls org.jboss.remoting.MicroRemoteClientInvoker.establishLease(), which calls org.jboss.remoting.LeasePinger.addClient(), which calls LeasePinger.sendClientPing(), which sends to the server the Clients it represents. If LeasePinger.sendClientPing() fails, it just logs a message and swallows the exception. That behavior is appropriate when sendClientPing() is just sending an ordinary PING, but if the attempt to register a new Client fails, the call to Client.connect() should fail. -- 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

15 years, 2 months

1
3
0 / 0

[JBoss JIRA] Created: (JBREM-1149) Do not include samples in the JAR

by Ondrej Medek (JIRA)

Do not include samples in the JAR --------------------------------- Key: JBREM-1149 URL: https://jira.jboss.org/jira/browse/JBREM-1149 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Environment: JBoss AS 5.1.0GA Reporter: Ondrej Medek Priority: Minor We have a Java swing application using session beans. We have to distribute jboss-remoting.jar (1,14MB) to our clients. I have found that when I delete samples from the jboss-remoting.jar, it has only 0,86MB. It saves some download time for our clients behind a thin line. Please, remove the samples and all not-necessary code from the jboss-remoting.jar. -- 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

15 years, 2 months

2
5
0 / 0

[JBoss JIRA] Created: (JBREM-1151) Correct dependency discussion in Chapter 4 of Remoting Guide

by Ron Sigal (JIRA)

Correct dependency discussion in Chapter 4 of Remoting Guide ------------------------------------------------------------ Key: JBREM-1151 URL: https://jira.jboss.org/jira/browse/JBREM-1151 Project: JBoss Remoting Issue Type: Task 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 The discussion is misleading and possibly incorrect. -- 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

15 years, 2 months

1
1
0 / 0

[JBoss JIRA] Created: (JBREM-1152) If MicroSocketClientInvoker gets a SocketException in getConnection(), it should retry

by Ron Sigal (JIRA)

If MicroSocketClientInvoker gets a SocketException in getConnection(), it should retry -------------------------------------------------------------------------------------- Key: JBREM-1152 URL: https://jira.jboss.org/jira/browse/JBREM-1152 Project: JBoss Remoting Issue Type: Bug 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 If a SocketException is thrown in the main loop in org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(), the invocation will be retried (if "numberOfCallRetries" is set to a value > 1). The same should apply if a SocketConnection is thrown in the preliminary attempt to create a socket. This issue is particularly relevant to the bisocket transport, where the attempt by a callback client to create a socket involves a write on the control connection. -- 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

15 years, 2 months

1
6
0 / 0

[JBoss JIRA] Created: (JBREM-1107) SocketServerInvoker.IdleTimeoutTask interrupts ServerThreads during long invocation

by Ron Sigal (JIRA)

SocketServerInvoker.IdleTimeoutTask interrupts ServerThreads during long invocation ----------------------------------------------------------------------------------- Key: JBREM-1107 URL: https://jira.jboss.org/jira/browse/JBREM-1107 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.5.0.SP2 (Flounder) , 2.2.2.SP11 Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.2.2.SP12, 2.5.0.SP3 (Flounder) org.jboss.remoting.transport.socket.SocketServerInvoker.IdleTimerTask is intended to shut down org.jboss.remoting.transport.socket.ServerThreads that haven't been in use for some configured amount of time. For each ServerThread, it compares the value of System.currentTimeMillis() to the time at which the ServerThread last started or finished processing an invocation, and, if the difference exceeds the value of the "idleTimeout" parameter, it shuts down the ServerThread. The problem is that if processing an invocation takes longer than the value of "idleTimeout", a ServerThread could be shut down DURING the processing of an invocation. -- 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

15 years, 2 months

1
5
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

jboss-remoting-issues September 2009