[JBoss JIRA] Created: (JBREM-549) remove dependancy on concurrent.jar within remoting client
by Tom Elrod (JIRA)
remove dependancy on concurrent.jar within remoting client
----------------------------------------------------------
Key: JBREM-549
URL: http://jira.jboss.com/jira/browse/JBREM-549
Project: JBoss Remoting
Issue Type: Task
Security Level: Public (Everyone can see)
Components: general
Affects Versions: 2.0.0.Beta2 (Boon)
Reporter: Tom Elrod
Assigned To: Tom Elrod
Fix For: 2.0.0.CR1 (Boon)
Currently, the remoting clients will require concurrent.jar to be on the classpath because org.jboss.util.id.GUID is used to create the client session id. Problem is that org.jboss.util.id.GUID is what requires concurrent.jar. So will either need to modify the code within jboss common repository or find another class to use for generating the client session id.
java.lang.NoClassDefFoundError: EDU/oswego/cs/dl/util/concurrent/SynchronizedLong
at org.jboss.util.id.UID.<clinit>(UID.java:56)
at org.jboss.util.id.VMID.create(VMID.java:259)
at org.jboss.util.id.VMID.getInstance(VMID.java:223)
at org.jboss.util.id.GUID.<init>(GUID.java:65)
at org.jboss.remoting.Client.<init>(Client.java:133)
at org.jboss.remoting.Client.<init>(Client.java:210)
at org.jboss.remoting.Client.<init>(Client.java:191)
at org.jboss.test.remoting.transport.InvokerClientTest.init(InvokerClientTest.java:80)
--
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, 8 months
[JBoss JIRA] Created: (JBREM-577) Investigate failure of org.jboss.test.remoting.transport.multiplex.MultiplexInvokerTestCase, jdk 1.4, on cruisecontrol
by Ron Sigal (JIRA)
Investigate failure of org.jboss.test.remoting.transport.multiplex.MultiplexInvokerTestCase, jdk 1.4, on cruisecontrol
----------------------------------------------------------------------------------------------------------------------
Key: JBREM-577
URL: http://jira.jboss.com/jira/browse/JBREM-577
Project: JBoss Remoting
Issue Type: Task
Security Level: Public (Everyone can see)
Affects Versions: 2.0.0.GA (Boon)
Reporter: Ron Sigal
Assigned To: Ron Sigal
Fix For: 2.0.0.GA (Boon)
This test is failing rather consistently in testRule4ServerFirst() on cruisecontrol, even though this particular failure can't be reproduced on any other environment. In case the problem is more than environmental, i.e., a real problem in Multiplex, some additional log statements will be added to MultiplexServerInvoker and OutputMultiplexor.
What is happening is that in runPushCallbackTests(), the message "stopped callback Connector" appears, but then the test dies before the callback Connector completes its shut down. It would be nice to believe that there is a deadlock, but none is evident, unless it's due to a problem with Collections.synchronizedMap in jdk 1.4. Note that this problem never occurs in the jdk 1.5 cruisecontrol tests.
--
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, 8 months
[JBoss JIRA] Created: (JBREM-639) Allow stream factory to specified for all transports
by Tim Fox (JIRA)
Allow stream factory to 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: Tom Elrod
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. This would allow how streams are wrapped to be determined in a much more consistent way.
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, 8 months
[JBoss JIRA] Created: (JBREM-729) Make multiplex server invoker more robust
by Ron Sigal (JIRA)
Make multiplex server invoker more robust
-----------------------------------------
Key: JBREM-729
URL: http://jira.jboss.com/jira/browse/JBREM-729
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)
Claudia Richter has reported some problems using Remoting JNDI detection with multiplex transport. If the JNDI heartbeat is looking for an old socket invoker at an address and port where a multiplex invoker currently runs, the multiplex invoker can get hung up trying to process in invocation intended for the socket invoker. It should be able to tolerate unexpected inputs. In particular, MultiplexServerInvoker should set a timeout on the MasterServerSocket so that it doesn't get hung up in accept().
--
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, 8 months
[JBoss JIRA] Created: (JBAS-4176) Error in delist masks the real error creating the connection handle in BaseConnectionManager2
by Adrian Brock (JIRA)
Error in delist masks the real error creating the connection handle in BaseConnectionManager2
---------------------------------------------------------------------------------------------
Key: JBAS-4176
URL: http://jira.jboss.com/jira/browse/JBAS-4176
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: JCA service
Reporter: Adrian Brock
Assigned To: Weston Price
Fix For: JBossAS-4.2.0.CR1
There is a problem with the error reporting in BaseConnectionManager2.allocationConnection().
When it can't get a connection handle, it invokes managedConnectionDisconnected() to
make sure any work already done is undone, e.g. delist the resource and return to the pool.
The problem is that an error thrown from managedConnectionDisconnected()
will be given to the user rather than the original error thrown when getting the handle.
// Ask the managed connection for a connection
Object connection = null;
try
{
connection = cl.getManagedConnection().getConnection(subject, cri);
}
catch (Throwable t)
{
// HERE: Error from this method
managedConnectionDisconnected(cl);
// Means this original error is not thrown
JBossResourceException.rethrowAsResourceException(
"Unchecked throwable in ManagedConnection.getConnection() cl=" + cl, t);
}
In fact, if we do get an error asking for a handle, we should probably just quietly (no logging above DEBUG)
destroy the connection and then rethrow the original error.
i.e.
catch (Throwable t)
{
// HERE: Destroy the connection
returnManagedConnection(cl, true);
JBossResourceException.rethrowAsResourceException(
"Unchecked throwable in ManagedConnection.getConnection() cl=" + cl, t);
}
--
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, 8 months