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

[JBoss JIRA] Updated: (JBREM-364) refactor client invoker config for common configurations

by Ron Sigal (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-364?page=all ] Ron Sigal updated JBREM-364: ---------------------------- Fix Version/s: (was: 2.4.0.Beta1 (Pinto)) Removed fix version. > refactor client invoker config for common configurations > -------------------------------------------------------- > > Key: JBREM-364 > URL: http://jira.jboss.com/jira/browse/JBREM-364 > Project: JBoss Remoting > Issue Type: Task > Security Level: Public(Everyone can see) > Components: general > Affects Versions: 1.4.0 final > Reporter: Tom Elrod > > Currently client invoker implementations all do their own configuration processing. Since many share the same configuration properties, need to standardize these and handle them in the RemoteClientInvoker instead of individual implementations (i.e. SocketClientInvoker, HTTPClientInvoker, etc.). Should follow same model that has been done for ServerInvoker. -- 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

1
0
0 / 0

[JBoss JIRA] Closed: (JBREM-364) refactor client invoker config for common configurations

by Ron Sigal (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-364?page=all ] Ron Sigal closed JBREM-364. --------------------------- Resolution: Done > refactor client invoker config for common configurations > -------------------------------------------------------- > > Key: JBREM-364 > URL: http://jira.jboss.com/jira/browse/JBREM-364 > Project: JBoss Remoting > Issue Type: Task > Security Level: Public(Everyone can see) > Components: general > Affects Versions: 1.4.0 final > Reporter: Tom Elrod > > Currently client invoker implementations all do their own configuration processing. Since many share the same configuration properties, need to standardize these and handle them in the RemoteClientInvoker instead of individual implementations (i.e. SocketClientInvoker, HTTPClientInvoker, etc.). Should follow same model that has been done for ServerInvoker. -- 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

1
0
0 / 0

[JBoss JIRA] Updated: (JBREM-480) Insure reliable tests in socket invoker for unusable socket connections.

by Ron Sigal (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-480?page=all ] Ron Sigal updated JBREM-480: ---------------------------- Fix Version/s: (was: 2.4.0.Beta1 (Pinto)) Removed fix version. > Insure reliable tests in socket invoker for unusable socket connections. > ------------------------------------------------------------------------ > > Key: JBREM-480 > URL: http://jira.jboss.com/jira/browse/JBREM-480 > Project: JBoss Remoting > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 2.0.0.CR1 (Boon) > Reporter: Ron Sigal > Assigned To: Ron Sigal > > The socket invoker needs to test for unusable socket connections, on both the client and server side. There are currently two tests in place, only one of which is correct. On the client side, if the shouldCheckConnection flag is set, then MicroSocketClientInvoker.getPooledConnection() and SocketClientInvoker.getPooledConnection() will call ClientSocketWrapper.checkConnection(), which will call ObjectInputStream.readByte(), which throws an EOFException at end of file, i.e., when the remote endpoint closes. If the shouldCheckConnection flag is not set, then SocketClientInvoker.getPooledConnection() will call Socket.isConnected() on its socket, and MicroSocketClientInvoker.getPooledConnection() makes no test. In any case, Socket.isConnected() does not appear to be useful, since it seems that a Socket, once connected, never returns to a disconnected state (at least in linux and jdk 1.4). On the server side, ServerThread.acknowledge() will call ServerSocketWrapper.checkConnection(), which behaves like ClientSocketWrapper.checkConnection(), if the shouldCheckConnection flag is set. > The problem on the client side is that if the performVersioning flag is set, a version byte will be read by calling InputStream.read(), which returns -1 at end of file instead of throwing EOFException. If an InputStream at end of file is not tested for end of file, -1 will be read and treated as an incorrect version. resulting in an Exception. There needs to be an explicit test for -1. > On the server side, a version of -1 is set to 1, and the end of file condition is caught later. It would be simpler to test explicitly for -1. > In any case, we need to verify that there are reliable tests in place for unusable connections. It is difficult to see how to write a unit test that creates an error condition on a socket, but there should be unit tests for client side and server side end of file conditions. -- 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

1
0
0 / 0

[JBoss JIRA] Closed: (JBREM-480) Insure reliable tests in socket invoker for unusable socket connections.

by Ron Sigal (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-480?page=all ] Ron Sigal closed JBREM-480. --------------------------- Resolution: Done > Insure reliable tests in socket invoker for unusable socket connections. > ------------------------------------------------------------------------ > > Key: JBREM-480 > URL: http://jira.jboss.com/jira/browse/JBREM-480 > Project: JBoss Remoting > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 2.0.0.CR1 (Boon) > Reporter: Ron Sigal > Assigned To: Ron Sigal > > The socket invoker needs to test for unusable socket connections, on both the client and server side. There are currently two tests in place, only one of which is correct. On the client side, if the shouldCheckConnection flag is set, then MicroSocketClientInvoker.getPooledConnection() and SocketClientInvoker.getPooledConnection() will call ClientSocketWrapper.checkConnection(), which will call ObjectInputStream.readByte(), which throws an EOFException at end of file, i.e., when the remote endpoint closes. If the shouldCheckConnection flag is not set, then SocketClientInvoker.getPooledConnection() will call Socket.isConnected() on its socket, and MicroSocketClientInvoker.getPooledConnection() makes no test. In any case, Socket.isConnected() does not appear to be useful, since it seems that a Socket, once connected, never returns to a disconnected state (at least in linux and jdk 1.4). On the server side, ServerThread.acknowledge() will call ServerSocketWrapper.checkConnection(), which behaves like ClientSocketWrapper.checkConnection(), if the shouldCheckConnection flag is set. > The problem on the client side is that if the performVersioning flag is set, a version byte will be read by calling InputStream.read(), which returns -1 at end of file instead of throwing EOFException. If an InputStream at end of file is not tested for end of file, -1 will be read and treated as an incorrect version. resulting in an Exception. There needs to be an explicit test for -1. > On the server side, a version of -1 is set to 1, and the end of file condition is caught later. It would be simpler to test explicitly for -1. > In any case, we need to verify that there are reliable tests in place for unusable connections. It is difficult to see how to write a unit test that creates an error condition on a socket, but there should be unit tests for client side and server side end of file conditions. -- 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

1
0
0 / 0

[JBoss JIRA] Reopened: (JBREM-480) Insure reliable tests in socket invoker for unusable socket connections.

by Ron Sigal (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-480?page=all ] Ron Sigal reopened JBREM-480: ----------------------------- > Insure reliable tests in socket invoker for unusable socket connections. > ------------------------------------------------------------------------ > > Key: JBREM-480 > URL: http://jira.jboss.com/jira/browse/JBREM-480 > Project: JBoss Remoting > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 2.0.0.CR1 (Boon) > Reporter: Ron Sigal > Assigned To: Ron Sigal > > The socket invoker needs to test for unusable socket connections, on both the client and server side. There are currently two tests in place, only one of which is correct. On the client side, if the shouldCheckConnection flag is set, then MicroSocketClientInvoker.getPooledConnection() and SocketClientInvoker.getPooledConnection() will call ClientSocketWrapper.checkConnection(), which will call ObjectInputStream.readByte(), which throws an EOFException at end of file, i.e., when the remote endpoint closes. If the shouldCheckConnection flag is not set, then SocketClientInvoker.getPooledConnection() will call Socket.isConnected() on its socket, and MicroSocketClientInvoker.getPooledConnection() makes no test. In any case, Socket.isConnected() does not appear to be useful, since it seems that a Socket, once connected, never returns to a disconnected state (at least in linux and jdk 1.4). On the server side, ServerThread.acknowledge() will call ServerSocketWrapper.checkConnection(), which behaves like ClientSocketWrapper.checkConnection(), if the shouldCheckConnection flag is set. > The problem on the client side is that if the performVersioning flag is set, a version byte will be read by calling InputStream.read(), which returns -1 at end of file instead of throwing EOFException. If an InputStream at end of file is not tested for end of file, -1 will be read and treated as an incorrect version. resulting in an Exception. There needs to be an explicit test for -1. > On the server side, a version of -1 is set to 1, and the end of file condition is caught later. It would be simpler to test explicitly for -1. > In any case, we need to verify that there are reliable tests in place for unusable connections. It is difficult to see how to write a unit test that creates an error condition on a socket, but there should be unit tests for client side and server side end of file conditions. -- 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

1
0
0 / 0

[JBoss JIRA] Closed: (JBREM-639) Allow stream factory to be specified for all transports

by Ron Sigal (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-639?page=all ] Ron Sigal closed JBREM-639. --------------------------- Resolution: Done > Allow stream factory to be specified for all transports > ------------------------------------------------------- > > Key: JBREM-639 > URL: http://jira.jboss.com/jira/browse/JBREM-639 > Project: JBoss Remoting > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Tim Fox > Assigned To: Ron Sigal > > Normally marshallers will receive the raw underlying transport Input/OuputStream. > In some cases we want to wrap this in a different stream, e.g.in the case of JBossMessaging we want this wrapped in a DataInput/DataOutputStream. > This is accomplished by specifiying a new Client/ServerSocketWrapper in the socket transport URI params which creates the DataInput/OutputStream. > This works fine for the socket transport, but does not work for other transports which do not use SocketWrappers. > E.g. JBM needs to use the HTTP transport too, and needs the underlying stream wrapped in a DataOutput/InputStream. > The current remoting implementation will pass in the underlying stream to the marshaller when the HTTP transport is used, which means we have create and wrap a new DataInput/OuputStream on each invocation request and response which may have performance implications. > Suggestion is to allow a InputStream/OuputStream factory to be specified for ANY transport, not just the socket transport. > Suggestion is to allow the stream factory to be specified in the URI params, e.g. &streamFactoryClass=org.jboss.tim.MyStreamFactory, and this to be allowed for any transport. If factory is not specified then raw stream is passed into marshaller. -- 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

1
0
0 / 0

[JBoss JIRA] Reopened: (JBREM-639) Allow stream factory to be specified for all transports

by Ron Sigal (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-639?page=all ] Ron Sigal reopened JBREM-639: ----------------------------- > Allow stream factory to be specified for all transports > ------------------------------------------------------- > > Key: JBREM-639 > URL: http://jira.jboss.com/jira/browse/JBREM-639 > Project: JBoss Remoting > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Tim Fox > Assigned To: Ron Sigal > > Normally marshallers will receive the raw underlying transport Input/OuputStream. > In some cases we want to wrap this in a different stream, e.g.in the case of JBossMessaging we want this wrapped in a DataInput/DataOutputStream. > This is accomplished by specifiying a new Client/ServerSocketWrapper in the socket transport URI params which creates the DataInput/OutputStream. > This works fine for the socket transport, but does not work for other transports which do not use SocketWrappers. > E.g. JBM needs to use the HTTP transport too, and needs the underlying stream wrapped in a DataOutput/InputStream. > The current remoting implementation will pass in the underlying stream to the marshaller when the HTTP transport is used, which means we have create and wrap a new DataInput/OuputStream on each invocation request and response which may have performance implications. > Suggestion is to allow a InputStream/OuputStream factory to be specified for ANY transport, not just the socket transport. > Suggestion is to allow the stream factory to be specified in the URI params, e.g. &streamFactoryClass=org.jboss.tim.MyStreamFactory, and this to be allowed for any transport. If factory is not specified then raw stream is passed into marshaller. -- 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

1
0
0 / 0

[JBoss JIRA] Updated: (JBREM-639) Allow stream factory to be specified for all transports

by Ron Sigal (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-639?page=all ] Ron Sigal updated JBREM-639: ---------------------------- Fix Version/s: (was: 2.4.0.Beta1 (Pinto)) Removed fix version. > Allow stream factory to be specified for all transports > ------------------------------------------------------- > > Key: JBREM-639 > URL: http://jira.jboss.com/jira/browse/JBREM-639 > Project: JBoss Remoting > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Tim Fox > Assigned To: Ron Sigal > > Normally marshallers will receive the raw underlying transport Input/OuputStream. > In some cases we want to wrap this in a different stream, e.g.in the case of JBossMessaging we want this wrapped in a DataInput/DataOutputStream. > This is accomplished by specifiying a new Client/ServerSocketWrapper in the socket transport URI params which creates the DataInput/OutputStream. > This works fine for the socket transport, but does not work for other transports which do not use SocketWrappers. > E.g. JBM needs to use the HTTP transport too, and needs the underlying stream wrapped in a DataOutput/InputStream. > The current remoting implementation will pass in the underlying stream to the marshaller when the HTTP transport is used, which means we have create and wrap a new DataInput/OuputStream on each invocation request and response which may have performance implications. > Suggestion is to allow a InputStream/OuputStream factory to be specified for ANY transport, not just the socket transport. > Suggestion is to allow the stream factory to be specified in the URI params, e.g. &streamFactoryClass=org.jboss.tim.MyStreamFactory, and this to be allowed for any transport. If factory is not specified then raw stream is passed into marshaller. -- 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

1
0
0 / 0

[JBoss JIRA] Closed: (JBREM-599) remoting doc does not cover enabling or configuring leasing from the client side

by Ron Sigal (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-599?page=all ] Ron Sigal closed JBREM-599. --------------------------- Resolution: Done Done. > remoting doc does not cover enabling or configuring leasing from the client side > -------------------------------------------------------------------------------- > > Key: JBREM-599 > URL: http://jira.jboss.com/jira/browse/JBREM-599 > Project: JBoss Remoting > Issue Type: Task > Security Level: Public(Everyone can see) > Components: docs > Affects Versions: 2.0.0.GA (Boon) > Reporter: Tom Elrod > Priority: Minor > Fix For: 2.4.0.GA > > -- 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

1
0
0 / 0

[JBoss JIRA] Created: (JBREM-983) Legacy XML configuration should support multihome feature

by Ron Sigal (JIRA)

Legacy XML configuration should support multihome feature --------------------------------------------------------- Key: JBREM-983 URL: http://jira.jboss.com/jira/browse/JBREM-983 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 2.4.0.CR2 Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.4.0.GA Currently the multihome feature is supported by configuration with org.jboss.remoting.ServerConfiguration but not with the legacy XML configuration. Since Remoting 3 will have its own deployer, it might make sense to continue using configuration by XML, in which case the XML document should support the multihome feature. -- 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

1
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

jboss-remoting-issues May 2008