[JBoss JIRA] Created: (JBAS-4314) A deadlock condition in DistributedReplicantManagerImpl
by Bernd Köcke (JIRA)
A deadlock condition in DistributedReplicantManagerImpl
-------------------------------------------------------
Key: JBAS-4314
URL: http://jira.jboss.com/jira/browse/JBAS-4314
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Clustering
Affects Versions: JBossAS-4.0.2 Final
Environment: Linux 2.6.x, Sun-JVM 1.5.0_11-b03, 1.6.0-b105, JBoss 4.0.2.final.
Reporter: Bernd Köcke
Assigned To: Brian Stansberry
While working on JBAS-4313 I found a deadlock condition in DistributedReplicantManagerImpl. All methods are using the lock order localReplicants -> replicants. But method purgeDeadMembers uses replicants -> localReplicants. To solve the problem I moved the notifyKeyListeners out of the synchronized(replicants)-block.
Newer versions of JBoss are using maps from the concurrent-package and not the normal java.util.HashMap. Maybe this solves the problem, too.
--
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, 7 months
[JBoss JIRA] Created: (JBAOP-347) ClassCastException in MarshalledValue.java
by Tim McCune (JIRA)
ClassCastException in MarshalledValue.java
------------------------------------------
Key: JBAOP-347
URL: http://jira.jboss.com/jira/browse/JBAOP-347
Project: JBoss AOP
Issue Type: Patch
Security Level: Public (Everyone can see)
Affects Versions: 1.5.3.GA
Environment: JBoss 4.0.4, Whatever version of JBossAOP is bundled in with JBoss EJB 3.0-RC9-FD, JDK 1.6
Reporter: Tim McCune
I tried enabling JBoss serialization with EJB 3 remoting for the first time today, by changing the line
<attribute name="InvokerLocator">socket://${jboss.bind.address}:3873</attribute>
to
<attribute name="InvokerLocator">socket://${jboss.bind.address}:3873/?serializationtype=jboss</attribute>
in ejb3.deployer/META-INF/jboss-service.xml. When I do this, any remote call to my EJB results in the following exception on the client:
java.lang.ClassCastException: org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectOutput
at org.jboss.aop.util.MarshalledValue.writeExternal(MarshalledValue.java:190)
at org.jboss.serial.persister.ExternalizePersister.writeData(ExternalizePersister.java:58)
at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.describeObject(ObjectDescriptorFactory.java:275)
at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectOutput.writeObject(DataContainer.java:202)
at org.jboss.aop.metadata.SimpleMetaData.writeExternal(SimpleMetaData.java:226)
at org.jboss.serial.persister.ExternalizePersister.writeData(ExternalizePersister.java:58)
at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.describeObject(ObjectDescriptorFactory.java:275)
at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectOutput.writeObject(DataContainer.java:202)
at org.jboss.aop.joinpoint.MethodInvocation.writeExternal(MethodInvocation.java:321)
at org.jboss.serial.persister.ExternalizePersister.writeData(ExternalizePersister.java:58)
at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.describeObject(ObjectDescriptorFactory.java:275)
at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectOutput.writeObject(DataContainer.java:202)
at org.jboss.serial.persister.RegularObjectPersister.writeSlotWithFields(RegularObjectPersister.java:182)
at org.jboss.serial.persister.RegularObjectPersister.defaultWrite(RegularObjectPersister.java:90)
at org.jboss.serial.persister.RegularObjectPersister.writeData(RegularObjectPersister.java:62)
at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.describeObject(ObjectDescriptorFactory.java:275)
at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectOutput.writeObject(DataContainer.java:202)
at org.jboss.serial.io.JBossObjectOutputStream.writeObjectOverride(JBossObjectOutputStream.java:181)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:298)
at org.jboss.remoting.serialization.impl.jboss.JBossSerializationManager.sendObject(JBossSerializationManager.java:87)
at org.jboss.remoting.marshal.serializable.SerializableMarshaller.write(SerializableMarshaller.java:84)
at org.jboss.remoting.transport.socket.SocketClientInvoker.transport(SocketClientInvoker.java:273)
at org.jboss.remoting.RemoteClientInvoker.invoke(RemoteClientInvoker.java:143)
at org.jboss.remoting.Client.invoke(Client.java:525)
at org.jboss.remoting.Client.invoke(Client.java:488)
at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:55)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.remoting.ClusterChooserInterceptor.invoke(ClusterChooserInterceptor.java:74)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:55)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:77)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.stateless.StatelessClusteredProxy.invoke(StatelessClusteredProxy.java:100)
...
Looking at the code for MarshalledValue.java in the writeExternal method, the following line casts the ObjectOutput parameter to an OutputStream in order to take advantage of ByteArrayOutputStream's writeTo method:
baos.writeTo((OutputStream)out);
However, the assumption that the "out" parameter may be cast to an OutputStream in not a valid one. When using jboss serialization instead of java serialization, the "out" parameter that is passed in is of type org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectOutput, which implements ObjectOutput, but does not extends OutputStream. A simple fix is to change the line above to:
out.write(baos.toByteArray());
I don't know if the writeTo method gives noticeably better performance. If it does, it might be worth it to do an instanceof check first.
--
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, 7 months
[JBoss JIRA] Created: (JBMICROCONT-158) Non-existent manifest Class-Path refs produce vfs IllegalStateException
by Scott M Stark (JIRA)
Non-existent manifest Class-Path refs produce vfs IllegalStateException
-----------------------------------------------------------------------
Key: JBMICROCONT-158
URL: http://jira.jboss.com/jira/browse/JBMICROCONT-158
Project: JBoss MicroContainer
Issue Type: Bug
Components: VFS
Affects Versions: JBossMC_2_0_0 Beta3
Reporter: Scott M Stark
Assigned To: Scott M Stark
When the structure deployers parse a top-level jboss-test-entity.jar with a manifest like:
Manifest-Version: 1.0
Ant-Version: Apache Ant 1.6.5
Created-By: 1.5.0_09-b01 (Sun Microsystems Inc.)
Class-Path: ejb.jar jnp-client.jar jboss-client.jar jndi.jar jboss-jmx
.jar junit.jar deploy.jar
it fails with:
Caused by: java.lang.IllegalStateException: JarHandler@28271403[path= context=file:/C:/home/svn/JBossHead/jboss-head/testsuite/output/lib/jboss-test-entity.jar
real=file:/C:/home/svn/JBossHead/jboss-head/testsuite/output/lib/jboss-test-entity.jar] has no parent.
at org.jboss.virtual.VFSUtils.addManifestLocations(VFSUtils.java:116)
at org.jboss.deployers.plugins.structure.DefaultStructureBuilder.processContext(DefaultStructureBuilder.java:131)
at org.jboss.deployers.plugins.structure.DefaultStructureBuilder.populateContext(DefaultStructureBuilder.java:89)
The invalid references should at most produce debug level warnings.
--
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, 7 months
[JBoss JIRA] Created: (JBCACHE-1024) Move component construction out of Cache into Configuration to allow for better configurability
by Elias Ross (JIRA)
Move component construction out of Cache into Configuration to allow for better configurability
-----------------------------------------------------------------------------------------------
Key: JBCACHE-1024
URL: http://jira.jboss.com/jira/browse/JBCACHE-1024
Project: JBoss Cache
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Reporter: Elias Ross
Assigned To: Manik Surtani
There's a lot of logic embedded in CacheImpl.start() and create() as to what specific object instances are created. For example, the JGroups Channel, or the InterceptorChainFactory are directly constructed here and users have no control on this. A bunch of other objects are also created based on class names and whatnot; these are configurable to some extent but why does the CacheImpl need to know how to build these?
What really should be done is allow the Configuration class to play the role as factory class, and take out all factory details from the Cache itself.
--
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, 7 months