September 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBREM-767) Avoid deadlock in callback BisocketClientInvoker when timeout == 0

by Ron Sigal (JIRA)

Avoid deadlock in callback BisocketClientInvoker when timeout == 0 ------------------------------------------------------------------ Key: JBREM-767 URL: http://jira.jboss.com/jira/browse/JBREM-767 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.4.0.Beta1 (Pinto) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.4.0.Beta1 (Pinto) If timeout == 0 then org.jboss.remoting.transport.bisocket.BisocketClientInvoker.createSocket() can hang forever if the client side is unavailable. One fix is to not set timeout to 0, but currently the timeout value is inherited from the server invoker, for which timeout == 0 might be appropriate. One solution is to implement a separate timeout parameter for callback client invokers (JBREM-765). Another fix is for PingTimeTask to notify a thread waiting in createSocket() when an attempt to send a PING to the client fails. -- 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

18 years, 8 months

1
6
0 / 0

[JBoss JIRA] Created: (JBREM-765) Add a separate timeout parameter for callback clients

by Ron Sigal (JIRA)

Add a separate timeout parameter for callback clients ----------------------------------------------------- Key: JBREM-765 URL: http://jira.jboss.com/jira/browse/JBREM-765 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 2.4.0.Beta1 (Pinto) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.4.0.Beta1 (Pinto) Currently, the timeout set for the server filters down to callback client invokers. However, it would be useful to be able to specify a different timeout value for callback clients. Example. In JBossMessaging the server timeout is set to 0. This causes a problem for bisocket callback client invokers, since they create sockets by sending a message to the client side and then calling wait(). If timeout == 0 and the client dies, then the thread in wait() could wait forever. -- 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

18 years, 8 months

1
5
0 / 0

[JBoss JIRA] Created: (JBREM-731) Address of secondary server socket should be acquired each time a control connection is created.

by Ron Sigal (JIRA)

Address of secondary server socket should be acquired each time a control connection is created. ------------------------------------------------------------------------------------------------ Key: JBREM-731 URL: http://jira.jboss.com/jira/browse/JBREM-731 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.2.0.GA (Bluto) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.4.0.Beta1 (Pinto) Scenario: Client is connected to a server, server dies, and server is restarted (with same InvokerLocator). The new server creates a secondary server socket on a different port than the previous server, but the client invoker retains the old secondary server socket InvokerLocator. When a new Client is created, the old client invoker gets reused, and it isn't possible to create a control connection. -- 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

18 years, 8 months

1
3
0 / 0

[JBoss JIRA] Created: (JBREM-794) LeasePinger.addClient() should not create a new LeaseTimerTask if none currently exists

by Ron Sigal (JIRA)

LeasePinger.addClient() should not create a new LeaseTimerTask if none currently exists --------------------------------------------------------------------------------------- Key: JBREM-794 URL: http://jira.jboss.com/jira/browse/JBREM-794 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.2.0.SP4, 2.2.1.GA, 2.4.0.Beta1 (Pinto) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.2.2.GA, 2.4.0.Beta1 (Pinto) When org.jboss.remoting.LeasePinger.addClient() adds a new org.jboss.remoting.Client with a shorter ping period, it restarts the LeaseTimerTask. However, org.jboss.remoting.MicroRemoteClientInvoker.establishLease() calls LeasePinger.addClient() before it calls LeasePinger.startPing(). LeasePinger incorrectly creates a LeaseTimerTask in addClient() and then creates a second one in startPing(). LeasePinger.addClient() should be changed so that it starts a new LeaseTimerTask only if one already exists. -- 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

18 years, 8 months

1
2
0 / 0

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

by Ron Sigal (JIRA)

NPE in BisocketClientInvoker$PingTimerTask ------------------------------------------ Key: JBREM-790 URL: http://jira.jboss.com/jira/browse/JBREM-790 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.2.0.SP4, 2.2.1.GA Reporter: Ron Sigal Assigned To: Ron Sigal Priority: Minor Fix For: 2.2.1.SP1, 2.2.0.SP4_CP02, 2.4.0.Beta1 (Pinto) org.jboss.remoting.transport.bisocket.BisocketClientInvoker.PingTimerTask.shutdown() sets instance variable controlOutputStream to null. If the PingTimerTask happens to be running when shutdown() is called, there is a possibility of a NullPointerException. -- 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

18 years, 8 months

1
4
0 / 0

[JBoss JIRA] Created: (JBREM-787) Move network i/o in BisocketClientInvoker constructor to handleConnect()

by Ron Sigal (JIRA)

Move network i/o in BisocketClientInvoker constructor to handleConnect() ------------------------------------------------------------------------ Key: JBREM-787 URL: http://jira.jboss.com/jira/browse/JBREM-787 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.2.0.SP4, 2.2.1.GA, 2.4.0.Beta1 (Pinto) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.2.1.SP1, 2.2.0.SP4_CP02, 2.4.0.Beta1 (Pinto) The org.jboss.remoting.transport.bisocket.BisocketClientInvoker constructor is called by org.jboss.remoting.InvokerRegistry.createClientInvoker inside a synchronization block. InvokerRegistry.destroyClientInvoker uses the same lock, so a network problem in the BisocketClientInvoker could affect other threads. -- 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

18 years, 8 months

1
4
0 / 0

[JBoss JIRA] Created: (JBREM-785) BisocketClientInvoker.transport() inadvertently changes listenerId member variable

by Ron Sigal (JIRA)

BisocketClientInvoker.transport() inadvertently changes listenerId member variable ---------------------------------------------------------------------------------- Key: JBREM-785 URL: http://jira.jboss.com/jira/browse/JBREM-785 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.2.1.GA, 2.2.1.SP1, 2.2.0.SP4_CP02, 2.4.0.Beta1 (Pinto) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.2.1.SP1, 2.2.0.SP4_CP02, 2.4.0.Beta1 (Pinto) org.jboss.remoting.transport.bisocket.BisocketClientInvoker.transport() sets listenerId member variable, instead of creating a new variable on the stack. -- 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

18 years, 8 months

1
5
0 / 0

[JBoss JIRA] Created: (JBREM-788) Access to BisocketClientInvoker static maps should be synchronized in handleDisconnect()

by Ron Sigal (JIRA)

Access to BisocketClientInvoker static maps should be synchronized in handleDisconnect() ---------------------------------------------------------------------------------------- Key: JBREM-788 URL: http://jira.jboss.com/jira/browse/JBREM-788 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.2.1.GA, 2.2.0.SP4_CP02, 2.4.0.Beta1 (Pinto) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.2.1.SP1, 2.2.0.SP4_CP02, 2.4.0.Beta1 (Pinto) Access to the two maps listenerIdToControlSocketsMap and listenerIdToSocketsMap should be synchronized in org.jboss.remoting.transport.BisocketClientInvoker.handleDisconnect(). -- 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

18 years, 8 months

1
4
0 / 0

[JBoss JIRA] Created: (JBREM-784) Use separate maps for control sockets and ordinary sockets in BisocketClientInvoker

by Ron Sigal (JIRA)

Use separate maps for control sockets and ordinary sockets in BisocketClientInvoker ----------------------------------------------------------------------------------- Key: JBREM-784 URL: http://jira.jboss.com/jira/browse/JBREM-784 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.2.0.SP4, 2.2.1.GA Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.2.1.SP1, 2.2.0.SP4_CP02, 2.4.0.Beta1 (Pinto) A race condition can cause control sockets and ordinary sockets to be confused with each other. In particular, in some runs of the JBossMessaging test org.jboss.test.messaging.jms.stress.SeveralClientsStressTest, it was observed that a connection that the client side took to be a control connection was used as an ordinary connection by the server side. The result was that org.jboss.remoting.transport.bisocket.BisocketServerInvoker.ControlConnectionThread.run() received unrecognized command. -- 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

18 years, 8 months

1
4
0 / 0

[JBoss JIRA] Created: (JBREM-782) Remove network i/o from synch block in ServerInvokerCallbackHandler.getCallbackHandler()

by Ron Sigal (JIRA)

Remove network i/o from synch block in ServerInvokerCallbackHandler.getCallbackHandler() ---------------------------------------------------------------------------------------- Key: JBREM-782 URL: http://jira.jboss.com/jira/browse/JBREM-782 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.2.0.SP4, 2.2.1.SP1, 2.2.0.SP4_CP02, 2.4.0.Beta1 (Pinto) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.2.1.SP1, 2.2.0.SP4_CP02, 2.4.0.Beta1 (Pinto) org.jboss.remoting.ServerInvoker.getCallbackHandler() has a call to the org.jboss.remoting.callback.ServerInvokerCallbackHandler() constructor inside a synchronization block., ServerInvokerCallbackHandler creates an org.jboss.remoting.Client, which creates a client invoker, and, depending on the transport, the call to Client.connect() might involve network i/o. -- 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

18 years, 8 months

1
5
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira September 2007