October 2010 - jboss-remoting-issues

[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

14 years

1
6
0 / 0

[JBoss JIRA] Created: (JBREM-1228) Augment Remoting 3 test suite

by Ron Sigal (JIRA)

Augment Remoting 3 test suite ----------------------------- Key: JBREM-1228 URL: https://jira.jboss.org/browse/JBREM-1228 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 3.1.0.Beta3 -- 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

1
3
0 / 0

[JBoss JIRA] Created: (JBREM-1233) Release 2.5.3

by Ron Sigal (JIRA)

Release 2.5.3 ------------- Key: JBREM-1233 URL: https://jira.jboss.org/browse/JBREM-1233 Project: JBoss Remoting Issue Type: Release Security Level: Public (Everyone can see) Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.5.3 (Flounder) -- 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

1
1
0 / 0

[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, 1 month

1
2
0 / 0

[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, 1 month

1
1
0 / 0

[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, 1 month

1
1
0 / 0

[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, 1 month

1
1
0 / 0

[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, 1 month

1
2
0 / 0

[JBoss JIRA] Created: (JBREM-1240) Upgrade to Remoting 2.2.3.SP3

by Ron Sigal (JIRA)

Upgrade to Remoting 2.2.3.SP3 ----------------------------- Key: JBREM-1240 URL: https://jira.jboss.org/browse/JBREM-1240 Project: JBoss Remoting Issue Type: Release Security Level: Public (Everyone can see) Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.2.3.SP3 -- 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, 2 months

1
3
0 / 0

[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, 2 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 October 2010