[JBoss JIRA] Created: (JBREM-1227) Fix deadlock between MicroRemoteClientInvoker and RemotingClassLoader
by Ron Sigal (JIRA)
Fix deadlock between MicroRemoteClientInvoker and RemotingClassLoader
---------------------------------------------------------------------
Key: JBREM-1227
URL: https://jira.jboss.org/browse/JBREM-1227
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 2.5.2.SP3 (Flounder)
Reporter: Ron Sigal
Assignee: Ron Sigal
Fix For: 2.5.2.SP4 (Flounder)
The following deadlock can occur:
1. Thread T1 reads a response with an object whose class is not available locally, so it uses its org.jboss.remoting.loading.RemotingClassLoader to try to download the class
a. java.lang.ClassLoader.loadClassInternal() acquires a lock on itself (an instance of RemotingClassLoader)
b. RemotingClassLoader uses its copy of an org.jboss.remoting.loading.ClassByteClassLoader to try to download the class
c. ClassByteClassLoader calls org.jboss.remoting.MicroRemoteClientInvoker.invoke(), which tries to synchronize on MicroRemoteClientInvoker.class as it sets up an UnMarshaller with a ClassLoader
2. Thread T2 attempts to make an invocation
a. MicroRemoteClientInvoker.invoke() acquires a lock on MicroRemoteClientInvoker.class
b. MicroRemoteClientInvoker.invoke() calls the synchronized method RemotingClassLoader.setUserClassLoader(), which tries to acquire a lock on the RemotingClassLoader
Deadlock.
The only two synchronized methods in RemotingClassLoader are setUserClassLoader() and unsetUserClassLoader(), which are both called from MicroRemoteClientInvoker.invoke(). The call to setUserClassLoader() is already done while the MicroRemoteClientInvoker.class lock is held. If the call to unsetUserClassLoader() is made with the same lock, then setUserClassLoader() and unsetClassLoader() don't have to be synchronized. That will eliminate the deadlock because step 2b is removed.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 11 months
[JBoss JIRA] Created: (JBREM-1256) Unit tests should use unique Xnio instances
by Ron Sigal (JIRA)
Unit tests should use unique Xnio instances
-------------------------------------------
Key: JBREM-1256
URL: https://jira.jboss.org/browse/JBREM-1256
Project: JBoss Remoting
Issue Type: Task
Security Level: Public (Everyone can see)
Affects Versions: 3.1.0.Beta2
Reporter: Ron Sigal
Assignee: Ron Sigal
Priority: Minor
Fix For: 3.1.0.Beta3
org.jboss.xnio.Xnio has a default instance which can be acquired by calling Xnio.getInstance(). The problem is that once this default instance is closed, it cannot be reused.
The cobertura maven plugin executes all tests in the same JVM, so once the default Xnio instance is closed, subsequent tests fail.
The workaround is to always use a unique Xnio instance, which can be created by calling
public static Xnio getInstance(final String name) throws IOException;
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years
[JBoss JIRA] Created: (JBREM-1252) Problems in ReaderInputStream
by Ron Sigal (JIRA)
Problems in ReaderInputStream
-----------------------------
Key: JBREM-1252
URL: https://jira.jboss.org/browse/JBREM-1252
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: stream
Affects Versions: 3.1.0.Beta2
Reporter: Ron Sigal
Fix For: 3.1.0.Beta3
There are a couple of little problems in org.jboss.remoting3.stream.ReaderInputStream:
1. When you enter read(), you want byteBuffer to be in "read" mode, so byteBuffer.flip() should be added to the constructor.
2. When you enter flip(), you want charBuffer to be in "read" mode, so charBuffer.flip() should be added to the constructor.
3. In fill()
try {
final int cnt = reader.read(charBuffer);
if (cnt == -1) {
return false;
}
doesn't tmake sense. It could be that you've transferred some bytes to byteBuffer and now reader is empty. When changed to
try {
final int cnt = reader.read(charBuffer);
if (cnt == -1) {
// return false;
return byteBuffer.position() > 0;
}
the code works.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years
[JBoss JIRA] Created: (JBREM-1253) Problems in PrimaryExternalizerFactory$ObjectSourceExternalizer and PrimaryExternalizerFactory$ObjectSinkExternalizer
by Ron Sigal (JIRA)
Problems in PrimaryExternalizerFactory$ObjectSourceExternalizer and PrimaryExternalizerFactory$ObjectSinkExternalizer
---------------------------------------------------------------------------------------------------------------------
Key: JBREM-1253
URL: https://jira.jboss.org/browse/JBREM-1253
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: stream
Affects Versions: 3.1.0.Beta2
Reporter: Ron Sigal
Fix For: 3.1.0.Beta3
1. In org.jboss.remoting3.remote.PrimaryExternalizerFactory$ObjectSourceExternalizer.createExternal(), the variable ok never gets set to true. createExternal() should be changed to
public ObjectSource createExternal(final Class<?> subjectType, final ObjectInput input, final Creator defaultCreator) throws IOException, ClassNotFoundException {
boolean ok = false;
final Unmarshaller unmarshaller = connectionHandler.getMarshallerFactory().createUnmarshaller(connectionHandler.getMarshallingConfiguration());
try {
unmarshaller.start(readInboundStream(input.readInt()));
ok = true; // <== ADD THIS
return new UnmarshallerObjectSource(unmarshaller);
} finally {
if (! ok) {
IoUtils.safeClose(unmarshaller);
}
}
}
2. In PrimaryExternalizerFactory$ObjectSinkExternalizer.createExternal(), the variable ok never gets set to true. createExternal() should be changed to
public ObjectSink createExternal(final Class<?> subjectType, final ObjectInput input, final Creator defaultCreator) throws IOException, ClassNotFoundException {
boolean ok = false;
final Marshaller marshaller = connectionHandler.getMarshallerFactory().createMarshaller(connectionHandler.getMarshallingConfiguration());
try {
marshaller.start(readOutboundStream(input.readInt()));
ok = true; // <== ADD THIS
return new MarshallerObjectSink(marshaller);
} finally {
if (! ok) {
IoUtils.safeClose(marshaller);
}
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years
[JBoss JIRA] Created: (JBREM-1251) WriterOutputStream.write() won't call doFlush() until the ByteBuffer is full
by Ron Sigal (JIRA)
WriterOutputStream.write() won't call doFlush() until the ByteBuffer is full
----------------------------------------------------------------------------
Key: JBREM-1251
URL: https://jira.jboss.org/browse/JBREM-1251
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: stream
Affects Versions: 3.1.0.Beta2
Reporter: Ron Sigal
Fix For: 3.1.0.Beta3
If a client sends a java.io.Writer and the org.jboss.remoting3.RequestListener writes a short message to it and flushes, the message isn't available on the client side. org.jboss.remoting3.stream.WriterOutputStream.write() won't call doFlush() until the ByteBuffer is full. So the RequestHandler has to close the writer, and then WriterOutputStream.close() will call doFlush().
WriterOutputStream.write() should be flushing. Also, the behavior should be consistent with OutputStream.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years
[JBoss JIRA] Created: (JBREM-1257) InboundClient should not be removed while a request is in progress
by Ron Sigal (JIRA)
InboundClient should not be removed while a request is in progress
------------------------------------------------------------------
Key: JBREM-1257
URL: https://jira.jboss.org/browse/JBREM-1257
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: r3 core: remote
Affects Versions: 3.1.0.Beta2
Reporter: Ron Sigal
Fix For: 3.1.0.Beta3
An invocation of org.jboss.remoting.Client.send() will cause the execution of an InboundRequestTask on the server, where InboundRequestTask.run() looks for the related org.jboss.remoting3.remote.InboundClient to execute the request. An invocation of Client.close() will result in the related InboundClient being removed from its map. Since the InboundRequestTask is executed in a separate thread, it is possible for the removal of the InboundClient to occur before the InboundRequestTask accesses it. The result is a NullPointerException.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years
[JBoss JIRA] Created: (JBREM-1255) Classname redundancy in Remoting.addServices()
by Ron Sigal (JIRA)
Classname redundancy in Remoting.addServices()
----------------------------------------------
Key: JBREM-1255
URL: https://jira.jboss.org/browse/JBREM-1255
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 3.1.0.Beta2
Reporter: Ron Sigal
Priority: Minor
Fix For: 3.1.0.Beta3
In org.jboss.remoting3.Remoting.addServices()
private static <T> void addServices(final Endpoint endpoint, final ProtocolServiceType<T> serviceType, final Properties props) {
final String basePropName = serviceType.getName().toLowerCase();
final String instances = props.getProperty(endpoint.getName() + "." + basePropName + "_list");
final Class<T> valueClass = serviceType.getValueClass();
if (instances != null) {
for (String name : instances.split(",")) {
final String trimmed = name.trim();
final String className = props.getProperty(name + "." + basePropName + "." + trimmed + ".class"); // <<<=====
if (className != null) {
try {
final Class<? extends T> instanceType = Class.forName(className).asSubclass(valueClass);
final T instance = instanceType.getConstructor().newInstance();
log.trace("Adding protocol service '%s' of type '%s'", name, serviceType);
endpoint.addProtocolService(serviceType, name, instance);
} catch (InvocationTargetException e) {
log.warn(e.getCause(), "Unable to create %s instance '%s'", serviceType, name);
} catch (Exception e) {
log.warn("Unable to register %s '%s': %s", serviceType, name, e);
}
}
}
}
}
the line labelled <<<==== has what seems to be the redundant use of name and trimmed. As a result, the property it's looking for ends up looking like, for example, "mockClassResolver.class_resolver.mockClassResolver.class". I suspect it should be "class_resolver.mockClassResolver.class".
Note that the property file jboss-remoting/src/test/resources/protocols.test.remoting.properties, used by org.jboss.remoting3.test.EndpointConfigurationTestCase, is written to work with this redundancy. It should be changed if the code is changed.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month