[JBoss JIRA] Created: (JBCACHE-1192) Cannot gravitate data only stored in cache loader
by Brian Stansberry (JIRA)
Cannot gravitate data only stored in cache loader
-------------------------------------------------
Key: JBCACHE-1192
URL: http://jira.jboss.com/jira/browse/JBCACHE-1192
Project: JBoss Cache
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Eviction, Replication
Affects Versions: 1.4.1.SP4, 1.4.1.SP3, 1.4.1.SP2, 1.4.1.SP1, 2.0.0.GA, 1.4.1.GA, 1.4.0.SP1, 1.4.0.GA
Reporter: Brian Stansberry
Assigned To: Manik Surtani
Priority: Critical
Fix For: 1.4.1.SP6, 2.1.0.GA
If data has been evicted and is only available via a cacheloader, data gravitation fails to find it. The CacheImpl.gravitateData method only searches the in-memory state.
--
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
18 years, 9 months
[JBoss JIRA] Created: (JBCACHE-1209) Restore existing Option to InvocationContext in TreeCache._gravitateData
by Brian Stansberry (JIRA)
Restore existing Option to InvocationContext in TreeCache._gravitateData
------------------------------------------------------------------------
Key: JBCACHE-1209
URL: http://jira.jboss.com/jira/browse/JBCACHE-1209
Project: JBoss Cache
Issue Type: Sub-task
Security Level: Public (Everyone can see)
Affects Versions: 1.4.1.SP6
Reporter: Brian Stansberry
Assigned To: Manik Surtani
Fix For: 1.4.1.SP6
The fix for JBCACHE-1192 has introduced a couple of problems that are manifesting themselves in numerous errors in the test suite:
1) _gravitateData changes the value of skipDataGravitation for the Option associated with the call, but then doesn't restore the correct value to *that* instance of Option.
2) _gravitateData calls get(Fqn), and that call actually results in the instance of Option that is associated with the thread being changed (see impl of get(Fqn). But, _gravitateData does not restore the original Option to the thread. Maybe not a problem if _gravitateData is called remotely, since there is no meaningful Option associated with the thread. But _gravitateData can now also be called by DataGravitationInterceptor.localBackupGet, and in that case there very well could be a meaningful Option associated with the thread, and it needs to be restored before _gravitateData returns.
I'll attach a possible patch in a minute.
--
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
18 years, 9 months
[JBoss JIRA] Created: (JGRP-465) Deadlock in FC if RPC response blocks
by Brian Stansberry (JIRA)
Deadlock in FC if RPC response blocks
-------------------------------------
Key: JGRP-465
URL: http://jira.jboss.com/jira/browse/JGRP-465
Project: JGroups
Issue Type: Bug
Affects Versions: 2.4.1 SP1
Reporter: Brian Stansberry
Assigned To: Brian Stansberry
Fix For: 2.4.1 SP2
In 2.4.1.SP1 (and probably earlier) FC can deadlock if all up/down threads are set to false at and above FC and an incoming RPC loops back down the channel with its response.
Following stack trace shows a deadlock situation (note the line numbers in FC are off from the cvs code; this occured with a patched FC version, but the patch is not relevant to this error):
"IncomingPacketHandler (channel=Tomcat-Cluster)" daemon prio=1 tid=0xc8a68b60 nid=0x1ece in Object.wait() [0xc94d1000..0xc94d1f30]
at java.lang.Object.wait(Native Method)
at EDU.oswego.cs.dl.util.concurrent.CondVar.timedwait(CondVar.java:222)
- locked <0xd187e398> (a EDU.oswego.cs.dl.util.concurrent.CondVar)
at org.jgroups.protocols.FC.handleDownMessage(FC.java:394)
at org.jgroups.protocols.FC.down(FC.java:336)
at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
at org.jgroups.protocols.FC.receiveDownEvent(FC.java:330)
at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
at org.jgroups.protocols.FRAG2.down(FRAG2.java:167)
at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
at org.jgroups.protocols.pbcast.STATE_TRANSFER.down(STATE_TRANSFER.java:294)
at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:385)
at org.jgroups.JChannel.down(JChannel.java:1231)
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.down(MessageDispatcher.java:790)
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.passDown(MessageDispatcher.java:767)
at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:693)
at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:544)
at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:367)
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:777)
at org.jgroups.JChannel.up(JChannel.java:1091)
at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:377)
at org.jgroups.stack.ProtocolStack.receiveUpEvent(ProtocolStack.java:393)
at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
at org.jgroups.protocols.pbcast.STATE_TRANSFER.up(STATE_TRANSFER.java:158)
at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
at org.jgroups.protocols.FRAG2.up(FRAG2.java:197)
at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
at org.jgroups.protocols.FC.up(FC.java:377)
at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
at org.jgroups.protocols.pbcast.GMS.up(GMS.java:768)
at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
at org.jgroups.protocols.pbcast.GMS.receiveUpEvent(GMS.java:788)
at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:260)
at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
at org.jgroups.protocols.UNICAST.handleDataReceived(UNICAST.java:476)
- locked <0xd1eec6d8> (a org.jgroups.protocols.UNICAST$Entry)
at org.jgroups.protocols.UNICAST.up(UNICAST.java:206)
at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:569)
at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:170)
at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
at org.jgroups.protocols.FD.up(FD.java:300)
at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:301)
at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
at org.jgroups.protocols.MERGE2.up(MERGE2.java:162)
at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
at org.jgroups.protocols.Discovery.up(Discovery.java:225)
at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
at org.jgroups.protocols.TP.handleIncomingMessage(TP.java:908)
at org.jgroups.protocols.TP.handleIncomingPacket(TP.java:850)
at org.jgroups.protocols.TP.access$400(TP.java:45)
at org.jgroups.protocols.TP$IncomingPacketHandler.run(TP.java:1296)
at java.lang.Thread.run(Thread.java:595)
The thread carried an RPC up to RpcDispatcher and is waiting in FC.handleDownMessage() for credits to become available to send the RPC response. Those credits will never arrive, as the thread that is blocking is the one that would need to deliver the credits.
This is less of an issue in 2.5. This is because 2.5. uses the concurrent stack and credit replenishments are sent as OOB messages on a separate thread. (Would still be an issue in 2.5 if the concurrent stack were disabled via configuration.)
Hacky solution is to somehow flag the up thread and in handleDownMessage() check for the flag before blocking the thread. If the flag is set, don't block the thread -- just let it through, i.e. let it exceed max_credits.
In cases like recent JBC releases where the vast majority of RPC responses are lightweight "null" responses, this is pretty safe. Need to add a config flag to disable the workaround though for use in applications where RPC responses frequently return large amounts of data.
--
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
18 years, 9 months
[JBoss JIRA] Created: (JBAS-3704) Add a notion of available interfaces to org.jboss.test.util.server.*
by Scott M Stark (JIRA)
Add a notion of available interfaces to org.jboss.test.util.server.*
--------------------------------------------------------------------
Key: JBAS-3704
URL: http://jira.jboss.com/jira/browse/JBAS-3704
Project: JBoss Application Server
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Test Suite
Affects Versions: JBossAS-4.0.4.GA
Reporter: Scott M Stark
Fix For: JBossAS-4.0.6.CR1
An issue with automating testing involving binding to specific addresses is that there is no predefined set of properties a testsuite descriptor can reference. The qa env has MYTESTIP_1 type of env vars set, and java 1.4.2+ has java.net.NetworkInterface, that could be used as the basis for defining jboss.server.iface.0..N system properties that configurations could rely on for setting one or more bind interfaces.
We need to add this functionality to the server startup tasks.
--
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
18 years, 9 months
[JBoss JIRA] Created: (JBREM-736) [org.jboss.remoting.transport.socket.SocketClientInvoker] Got marshalling exception, exiting java.lang.ClassNotFoundException: [Ljava.lang.StackTraceElement;
by Ravi Alagappan (JIRA)
[org.jboss.remoting.transport.socket.SocketClientInvoker] Got marshalling exception, exiting java.lang.ClassNotFoundException: [Ljava.lang.StackTraceElement;
---------------------------------------------------------------------------------------------------------------------------------------------------------------
Key: JBREM-736
URL: http://jira.jboss.com/jira/browse/JBREM-736
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: marshall
Affects Versions: 1.4.3.GA
Environment: Jboss 4.0.4.GA/EJB3/JDK1.6
Reporter: Ravi Alagappan
Assigned To: Tom Elrod
I am throwing custom application exception from bean and trying to catch that in client. But I am getting
2007-04-17 09:57:15,480 DEBUG [org.jboss.remoting.transport.socket.SocketClientInvoker] connect called for: org.jboss.remoting.transport.socket.SocketClientInvoker@16a38b5
2007-04-17 09:57:15,558 ERROR [org.jboss.remoting.transport.socket.SocketClientInvoker] Got marshalling exception, exiting
java.lang.ClassNotFoundException: [Ljava.lang.StackTraceElement;
at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at org.jboss.remoting.loading.RemotingClassLoader.loadClass(RemotingClassLoader.java:50)
at org.jboss.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:139)
at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
at java.io.ObjectInputStream.readArray(ObjectInputStream.java:1624)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1323)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1945)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1869)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1945)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1869)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:128)
at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:66)
at org.jboss.remoting.transport.socket.SocketClientInvoker.transport(SocketClientInvoker.java:279)
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.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:78)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.stateless.StatelessRemoteProxy.invoke(StatelessRemoteProxy.java:102)
at $Proxy0.save(Unknown Source)
at linc.document.service.RepositoryClient.save(RepositoryClient.java:109)
at linc.document.service.DocumentService.save(DocumentService.java:35)
at linc.document.service.DocumentService.main(DocumentService.java:184)
2007-04-17 09:57:15,573 ERROR [org.jboss.remoting.transport.socket.SocketClientInvoker] Error loading classes from remote call result.
java.lang.ClassNotFoundException: [Ljava.lang.StackTraceElement;
at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at org.jboss.remoting.loading.RemotingClassLoader.loadClass(RemotingClassLoader.java:50)
at org.jboss.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:139)
at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
at java.io.ObjectInputStream.readArray(ObjectInputStream.java:1624)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1323)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1945)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1869)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1945)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1869)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:128)
at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:66)
at org.jboss.remoting.transport.socket.SocketClientInvoker.transport(SocketClientInvoker.java:279)
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.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:78)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.stateless.StatelessRemoteProxy.invoke(StatelessRemoteProxy.java:102)
at $Proxy0.save(Unknown Source)
at linc.document.service.RepositoryClient.save(RepositoryClient.java:109)
at linc.document.service.DocumentService.save(DocumentService.java:35)
at linc.document.service.DocumentService.main(DocumentService.java:184)
But no exception with jdk1.5. With JDK1.5 client able to catch custom exception.
--
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
18 years, 9 months