September 2007 - jboss-jira - Jboss List Archives

[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, 4 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, 4 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, 4 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, 4 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, 4 months

1
5
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, 4 months

1
4
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, 4 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, 4 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, 4 months

1
5
0 / 0

[JBoss JIRA] Created: (JBREM-778) BisocketServerInvoker.start() creates a new static Timer each time

by Ron Sigal (JIRA)

BisocketServerInvoker.start() creates a new static Timer each time ------------------------------------------------------------------ Key: JBREM-778 URL: http://jira.jboss.com/jira/browse/JBREM-778 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.0.SP4 org.jboss.remoting.transport.bisocket.BisocketServerInvoker.start() creates a new static Timer each time. It should only create a new Timer if (1) there is no existing Timer, or (2) the existing Timer has shut down. See the similar issue JBREM-748. -- 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, 4 months

1
8
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