May 2008 - jboss-remoting-issues - Jboss List Archives

[JBoss JIRA] Updated: (JBREM-750) Logger in HTTPClientInvoker should be static.

by Ron Sigal (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-750?page=all ] Ron Sigal updated JBREM-750: ---------------------------- Fix Version/s: 2.4.0.Beta1 (Pinto) Added fix version 2.4.0.Beta1 - see JBREM-975 "Make sure all fixes on 2.2 branch are applied to 2.x branch". > Logger in HTTPClientInvoker should be static. > --------------------------------------------- > > Key: JBREM-750 > URL: http://jira.jboss.com/jira/browse/JBREM-750 > Project: JBoss Remoting > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 2.2.2.GA > Reporter: Ron Sigal > Assigned To: Ron Sigal > Fix For: 2.2.2.SP1, 2.4.0.Beta1 (Pinto) > > > When org.jboss.remoting.transport.http.ssl.HTTPSClientInvoker.createSocketFactory() (which is called from the RemoteClientInvoker() constructor) tries to log an error, it throws a NullPointerException because the log variable has not been initialized. > The log variable should be static. -- 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

16 years, 6 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBREM-653) allow user to set content-type for http responses

by Ron Sigal (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-653?page=all ] Ron Sigal closed JBREM-653. --------------------------- Resolution: Done > allow user to set content-type for http responses > ------------------------------------------------- > > Key: JBREM-653 > URL: http://jira.jboss.com/jira/browse/JBREM-653 > Project: JBoss Remoting > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: transport > Affects Versions: 2.2.2.GA > Reporter: Tom Elrod > Assigned To: Ron Sigal > Fix For: 2.4.0.Beta1 (Pinto), 2.2.2.SP1 > > Attachments: CoyoteInvoker.java.patch > > > Currently the CoyoteInvoker.versionedWrite() method will set the content type of the http response by using WebUtil.getContentType(responseObject) to identify the content type based on the response object type being sent back to client. > Should allow this to be overriden by the user in the same way the response code/message can be (using the response map). -- 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

16 years, 6 months

1
0
0 / 0

[JBoss JIRA] Reopened: (JBREM-750) Logger in HTTPClientInvoker should be static.

by Ron Sigal (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-750?page=all ] Ron Sigal reopened JBREM-750: ----------------------------- > Logger in HTTPClientInvoker should be static. > --------------------------------------------- > > Key: JBREM-750 > URL: http://jira.jboss.com/jira/browse/JBREM-750 > Project: JBoss Remoting > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 2.2.2.GA > Reporter: Ron Sigal > Assigned To: Ron Sigal > Fix For: 2.2.2.SP1, 2.4.0.Beta1 (Pinto) > > > When org.jboss.remoting.transport.http.ssl.HTTPSClientInvoker.createSocketFactory() (which is called from the RemoteClientInvoker() constructor) tries to log an error, it throws a NullPointerException because the log variable has not been initialized. > The log variable should be static. -- 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

16 years, 6 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBREM-741) Eliminate unnecessary log.warn() in BisocketServerInvoker

by Ron Sigal (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-741?page=all ] Ron Sigal closed JBREM-741. --------------------------- Resolution: Done > Eliminate unnecessary log.warn() in BisocketServerInvoker > --------------------------------------------------------- > > Key: JBREM-741 > URL: http://jira.jboss.com/jira/browse/JBREM-741 > Project: JBoss Remoting > Issue Type: Task > Security Level: Public(Everyone can see) > Affects Versions: 2.2.0.SP3 > Reporter: Ron Sigal > Assigned To: Ron Sigal > Fix For: 2.4.0.Beta1 (Pinto), 2.2.0.SP3 > > > As described in the forum reference, the "unrecognized listener ID:" warning from BisocketServerInvoker.destroyControlConnection() can happen when the client and server are in the same JVM, so it should be reduced to DEBUG level. -- 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

16 years, 6 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBREM-748) BisocketClientInvoker should guard agains scheduling on an expired Timer

by Ron Sigal (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-748?page=all ] Ron Sigal closed JBREM-748. --------------------------- Resolution: Done > BisocketClientInvoker should guard agains scheduling on an expired Timer > ------------------------------------------------------------------------ > > Key: JBREM-748 > URL: http://jira.jboss.com/jira/browse/JBREM-748 > Project: JBoss Remoting > Issue Type: Bug > 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), 2.2.0.SP4 > > > In two places, org.jboss.remoting.transport.bisocket.BisocketClientInvoker schedules a PingTimerTask on the Timer referenced by the static variable timer. The problem is that if the Timer has been around for a while and all of its tasks have completed, it could have entered a state in which in can no longer schedule new tasks. -- 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

16 years, 6 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBREM-748) BisocketClientInvoker should guard agains scheduling on an expired Timer

by Ron Sigal (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-748?page=all ] Ron Sigal updated JBREM-748: ---------------------------- Fix Version/s: 2.4.0.Beta1 (Pinto) Added fix version 2.4.0.Beta1 - see JBREM-975 "Make sure all fixes on 2.2 branch are applied to 2.x branch". > BisocketClientInvoker should guard agains scheduling on an expired Timer > ------------------------------------------------------------------------ > > Key: JBREM-748 > URL: http://jira.jboss.com/jira/browse/JBREM-748 > Project: JBoss Remoting > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 2.4.0.Beta1 (Pinto) > Reporter: Ron Sigal > Assigned To: Ron Sigal > Fix For: 2.2.0.SP4, 2.4.0.Beta1 (Pinto) > > > In two places, org.jboss.remoting.transport.bisocket.BisocketClientInvoker schedules a PingTimerTask on the Timer referenced by the static variable timer. The problem is that if the Timer has been around for a while and all of its tasks have completed, it could have entered a state in which in can no longer schedule new tasks. -- 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

16 years, 6 months

1
0
0 / 0

[JBoss JIRA] Reopened: (JBREM-748) BisocketClientInvoker should guard agains scheduling on an expired Timer

by Ron Sigal (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-748?page=all ] Ron Sigal reopened JBREM-748: ----------------------------- > BisocketClientInvoker should guard agains scheduling on an expired Timer > ------------------------------------------------------------------------ > > Key: JBREM-748 > URL: http://jira.jboss.com/jira/browse/JBREM-748 > Project: JBoss Remoting > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 2.4.0.Beta1 (Pinto) > Reporter: Ron Sigal > Assigned To: Ron Sigal > Fix For: 2.2.0.SP4, 2.4.0.Beta1 (Pinto) > > > In two places, org.jboss.remoting.transport.bisocket.BisocketClientInvoker schedules a PingTimerTask on the Timer referenced by the static variable timer. The problem is that if the Timer has been around for a while and all of its tasks have completed, it could have entered a state in which in can no longer schedule new tasks. -- 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

16 years, 6 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBREM-741) Eliminate unnecessary log.warn() in BisocketServerInvoker

by Ron Sigal (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-741?page=all ] Ron Sigal updated JBREM-741: ---------------------------- Fix Version/s: 2.4.0.Beta1 (Pinto) Added fix version 2.4.0.Beta1 - see JBREM-975 "Make sure all fixes on 2.2 branch are applied to 2.x branch". > Eliminate unnecessary log.warn() in BisocketServerInvoker > --------------------------------------------------------- > > Key: JBREM-741 > URL: http://jira.jboss.com/jira/browse/JBREM-741 > Project: JBoss Remoting > Issue Type: Task > Security Level: Public(Everyone can see) > Affects Versions: 2.2.0.SP3 > Reporter: Ron Sigal > Assigned To: Ron Sigal > Fix For: 2.2.0.SP3, 2.4.0.Beta1 (Pinto) > > > As described in the forum reference, the "unrecognized listener ID:" warning from BisocketServerInvoker.destroyControlConnection() can happen when the client and server are in the same JVM, so it should be reduced to DEBUG level. -- 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

16 years, 6 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBREM-732) When server terminates and has clients, when the server comes back up clients that survived, can't connect. Connection refused when trying to connect the control socket.

by Ron Sigal (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-732?page=all ] Ron Sigal closed JBREM-732. --------------------------- Resolution: Done > When server terminates and has clients, when the server comes back up clients that survived, can't connect. Connection refused when trying to connect the control socket. > -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: JBREM-732 > URL: http://jira.jboss.com/jira/browse/JBREM-732 > Project: JBoss Remoting > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 2.2.0.GA (Bluto) > Reporter: Jay Howell > Assigned To: Ron Sigal > Fix For: 2.4.0.Beta1 (Pinto), 2.2.0.SP3 > > > A client survives a server outage. When the server comes back up the survivor client tries to re-establish communictions and can't because the server is refusing the control socket connections. > New clients are able to connect fine. This happens intermittantly. > Here's the stack trace ..... > [2007-03-30 10:47:51,770 ERROR] [Thread-10] bisocket.BisocketServerInvoker - [unable to create control connection after 10 retries] > java.net.ConnectException: Connection refused: connect > at java.net.PlainSocketImpl.socketConnect(Native Method) > at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333) > at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195) > at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182) > at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366) > at java.net.Socket.connect(Socket.java:519) > at java.net.Socket.connect(Socket.java:469) > at java.net.Socket.<init>(Socket.java:366) > at java.net.Socket.<init>(Socket.java:179) > at org.jboss.remoting.transport.bisocket.BisocketServerInvoker.createControlConnection(BisocketServerInvoker.java:217) > at org.jboss.remoting.transport.bisocket.BisocketClientInvoker.transport(BisocketClientInvoker.java:328) > at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:122) > at org.jboss.remoting.Client.invoke(Client.java:1544) > at org.jboss.remoting.Client.addCallbackListener(Client.java:1613) > at org.jboss.remoting.Client.addListener(Client.java:907) > at org.jboss.jms.client.remoting.JMSRemotingConnection.addInvokerCallbackHandler(JMSRemotingConnection.java:221) > at org.jboss.jms.client.remoting.JMSRemotingConnection.start(JMSRemotingConnection.java:287) > at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate.org$jboss$jms$client$delegate$ClientConnectionFactoryDelegate$createConnectionDelegate$aop(ClientConnectionFactoryDelegate.java:146) > at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate$createConnectionDelegate_4579211046834694258.invokeNext(ClientConnectionFactoryDelegate$createConnectionDelegate_4579211046834694258.java) > at org.jboss.jms.client.container.StateCreationAspect.handleCreateConnectionDelegate(StateCreationAspect.java:83) > at org.jboss.aop.advice.org.jboss.jms.client.container.StateCreationAspect0.invoke(StateCreationAspect0.java) > at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate$createConnectionDelegate_4579211046834694258.invokeNext(ClientConnectionFactoryDelegate$createConnectionDelegate_4579211046834694258.java) > at org.jboss.jms.client.container.ExceptionInterceptor.invoke(ExceptionInterceptor.java:71) > at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate$createConnectionDelegate_4579211046834694258.invokeNext(ClientConnectionFactoryDelegate$createConnectionDelegate_4579211046834694258.java) > at org.jboss.jms.client.container.ClientLogInterceptor.invoke(ClientLogInterceptor.java:107) > at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate$createConnectionDelegate_4579211046834694258.invokeNext(ClientConnectionFactoryDelegate$createConnectionDelegate_4579211046834694258.java) > at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate.createConnectionDelegate(ClientConnectionFactoryDelegate.java) > at org.jboss.jms.client.JBossConnectionFactory.createConnectionInternal(JBossConnectionFactory.java:205) > at org.jboss.jms.client.JBossConnectionFactory.createConnection(JBossConnectionFactory.java:87) > at org.jboss.jms.client.JBossConnectionFactory.createConnection(JBossConnectionFactory.java:82) > at com.rbos.fx.eCommerce.spreading.messaging.JMSConnector.makeConnection(JMSConnector.java:166) > at com.rbos.fx.eCommerce.spreading.messaging.JMSConnector.getConnection(JMSConnector.java:141) > at com.rbos.fx.eCommerce.spreading.messaging.JMSConnector$JMSExceptionListener.onException(JMSConnector.java:188) > at org.jboss.jms.client.remoting.ConsolidatedRemotingConnectionListener.handleConnectionException(ConsolidatedRemotingConnectionListener.java:115) > at org.jboss.remoting.ConnectionValidator$1.run(ConnectionValidator.java:346) -- 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

16 years, 6 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBREM-732) When server terminates and has clients, when the server comes back up clients that survived, can't connect. Connection refused when trying to connect the control socket.

by Ron Sigal (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-732?page=all ] Ron Sigal updated JBREM-732: ---------------------------- Fix Version/s: 2.2.0.SP3 Added fix version 2.2.0.SP3. > When server terminates and has clients, when the server comes back up clients that survived, can't connect. Connection refused when trying to connect the control socket. > -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: JBREM-732 > URL: http://jira.jboss.com/jira/browse/JBREM-732 > Project: JBoss Remoting > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 2.2.0.GA (Bluto) > Reporter: Jay Howell > Assigned To: Ron Sigal > Fix For: 2.4.0.Beta1 (Pinto), 2.2.0.SP3 > > > A client survives a server outage. When the server comes back up the survivor client tries to re-establish communictions and can't because the server is refusing the control socket connections. > New clients are able to connect fine. This happens intermittantly. > Here's the stack trace ..... > [2007-03-30 10:47:51,770 ERROR] [Thread-10] bisocket.BisocketServerInvoker - [unable to create control connection after 10 retries] > java.net.ConnectException: Connection refused: connect > at java.net.PlainSocketImpl.socketConnect(Native Method) > at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333) > at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195) > at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182) > at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366) > at java.net.Socket.connect(Socket.java:519) > at java.net.Socket.connect(Socket.java:469) > at java.net.Socket.<init>(Socket.java:366) > at java.net.Socket.<init>(Socket.java:179) > at org.jboss.remoting.transport.bisocket.BisocketServerInvoker.createControlConnection(BisocketServerInvoker.java:217) > at org.jboss.remoting.transport.bisocket.BisocketClientInvoker.transport(BisocketClientInvoker.java:328) > at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:122) > at org.jboss.remoting.Client.invoke(Client.java:1544) > at org.jboss.remoting.Client.addCallbackListener(Client.java:1613) > at org.jboss.remoting.Client.addListener(Client.java:907) > at org.jboss.jms.client.remoting.JMSRemotingConnection.addInvokerCallbackHandler(JMSRemotingConnection.java:221) > at org.jboss.jms.client.remoting.JMSRemotingConnection.start(JMSRemotingConnection.java:287) > at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate.org$jboss$jms$client$delegate$ClientConnectionFactoryDelegate$createConnectionDelegate$aop(ClientConnectionFactoryDelegate.java:146) > at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate$createConnectionDelegate_4579211046834694258.invokeNext(ClientConnectionFactoryDelegate$createConnectionDelegate_4579211046834694258.java) > at org.jboss.jms.client.container.StateCreationAspect.handleCreateConnectionDelegate(StateCreationAspect.java:83) > at org.jboss.aop.advice.org.jboss.jms.client.container.StateCreationAspect0.invoke(StateCreationAspect0.java) > at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate$createConnectionDelegate_4579211046834694258.invokeNext(ClientConnectionFactoryDelegate$createConnectionDelegate_4579211046834694258.java) > at org.jboss.jms.client.container.ExceptionInterceptor.invoke(ExceptionInterceptor.java:71) > at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate$createConnectionDelegate_4579211046834694258.invokeNext(ClientConnectionFactoryDelegate$createConnectionDelegate_4579211046834694258.java) > at org.jboss.jms.client.container.ClientLogInterceptor.invoke(ClientLogInterceptor.java:107) > at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate$createConnectionDelegate_4579211046834694258.invokeNext(ClientConnectionFactoryDelegate$createConnectionDelegate_4579211046834694258.java) > at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate.createConnectionDelegate(ClientConnectionFactoryDelegate.java) > at org.jboss.jms.client.JBossConnectionFactory.createConnectionInternal(JBossConnectionFactory.java:205) > at org.jboss.jms.client.JBossConnectionFactory.createConnection(JBossConnectionFactory.java:87) > at org.jboss.jms.client.JBossConnectionFactory.createConnection(JBossConnectionFactory.java:82) > at com.rbos.fx.eCommerce.spreading.messaging.JMSConnector.makeConnection(JMSConnector.java:166) > at com.rbos.fx.eCommerce.spreading.messaging.JMSConnector.getConnection(JMSConnector.java:141) > at com.rbos.fx.eCommerce.spreading.messaging.JMSConnector$JMSExceptionListener.onException(JMSConnector.java:188) > at org.jboss.jms.client.remoting.ConsolidatedRemotingConnectionListener.handleConnectionException(ConsolidatedRemotingConnectionListener.java:115) > at org.jboss.remoting.ConnectionValidator$1.run(ConnectionValidator.java:346) -- 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

16 years, 6 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

jboss-remoting-issues May 2008