[JBoss JIRA] (ISPN-2300) Versioned Transactional Cache issues
by Pedro Ruivo (JIRA)
Pedro Ruivo created ISPN-2300:
---------------------------------
Summary: Versioned Transactional Cache issues
Key: ISPN-2300
URL: https://issues.jboss.org/browse/ISPN-2300
Project: Infinispan
Issue Type: Bug
Components: Transactions
Affects Versions: 5.2.0.Alpha3
Reporter: Pedro Ruivo
Assignee: Mircea Markus
Description from http://lists.jboss.org/pipermail/infinispan-dev/2012-…
[View More]September/011205.html
1) testPutIfAbsent, testRemoveIfPresent, testReplaceWithOldVal (methods
the test cases)
In this tests, it was updating the cache entry with a null version. This
originates later a IllegalStateException when it tries to perform the
write skew check and the version is null.
I have fixed this problem in this way: if the command fails (PutCommand,
RemoveCommand, ReplaceCommand), I unset the flag CHANGED in the
MvccEntry to avoid to update the entry in the DataContainer.
2) testClear in distributed mode
I have no clear idea how to solve this problem but it looks like the
PrepareCommand (with the ClearCommand) is not sent to all the nodes in
the cluster. Then, when I do a get, a remote get is performed and the
key is still there. I think that it is not the desired behavior.
3) testRemoveUnexistingEntry
In this test, it tries to remove a key that does not exists but it does
not success due to a NullPointerException. I have looked deeper and I
check that the transaction's lookup entries map has an entry with [key
=> null] and when it tries to perform the write skew check in that key,
a NullPointerException is thrown in here [2] (line 80, WriteSkewHelper)
[1] https://github.com/pruivo/infinispan/tree/t_replace_fix
[2] https://github.com/pruivo/infinispan/blob/t_replace_fix/core/src/main/jav...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[View Less]
12 years, 3 months
[JBoss JIRA] (ISPN-2025) NPE in Externalizer on shutdown
by Michal Linhard (JIRA)
Michal Linhard created ISPN-2025:
------------------------------------
Summary: NPE in Externalizer on shutdown
Key: ISPN-2025
URL: https://issues.jboss.org/browse/ISPN-2025
Project: Infinispan
Issue Type: Bug
Components: Marshalling
Affects Versions: 5.1.4.FINAL
Reporter: Michal Linhard
Assignee: Galder Zamarreño
I get this what I get when I'm shutting down one of the clustered nodes (…
[View More]default config standalone-ha.xml) of JDG 6.0.0.ER7
{code}
09:50:25,505 WARN [org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher] Problems unmarshalling remote command from byte buffer: java.lang.NullPointerException
at org.infinispan.marshall.jboss.ExternalizerTable.readObject(ExternalizerTable.java:222)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:351)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:37) [jboss-marshalling-1.3.13.GA-redhat-1.jar:1.3.13.GA-redhat-1]
at org.infinispan.marshall.jboss.AbstractJBossMarshaller.objectFromObjectStream(AbstractJBossMarshaller.java:154)
at org.infinispan.marshall.VersionAwareMarshaller.objectFromByteBuffer(VersionAwareMarshaller.java:114)
at org.infinispan.marshall.AbstractDelegatingMarshaller.objectFromByteBuffer(AbstractDelegatingMarshaller.java:85)
at org.infinispan.remoting.transport.jgroups.MarshallerAdapter.objectFromBuffer(MarshallerAdapter.java:50)
at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:200)
at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:456) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1]
at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:363) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1]
at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:238) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1]
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:543) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1]
at org.jgroups.blocks.mux.MuxUpHandler.up(MuxUpHandler.java:130) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1]
at org.jgroups.JChannel.up(JChannel.java:716) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1]
at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1026) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1]
at org.jgroups.protocols.RSVP.up(RSVP.java:179) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1]
at org.jgroups.protocols.FRAG2.up(FRAG2.java:181) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1]
at org.jgroups.protocols.FlowControl.up(FlowControl.java:418) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1]
at org.jgroups.protocols.FlowControl.up(FlowControl.java:400) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1]
at org.jgroups.protocols.pbcast.GMS.up(GMS.java:889) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1]
at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:244) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1]
at org.jgroups.protocols.UNICAST2.handleDataReceived(UNICAST2.java:793) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1]
at org.jgroups.protocols.UNICAST2.up(UNICAST2.java:365) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1]
at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:602) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1]
at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:177) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1]
at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:288) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1]
at org.jgroups.protocols.MERGE2.up(MERGE2.java:205) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1]
at org.jgroups.protocols.Discovery.up(Discovery.java:359) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1]
at org.jgroups.stack.Protocol.up(Protocol.java:363) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1]
at org.jgroups.protocols.TP.passMessageUp(TP.java:1180) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1]
at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1728) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1]
at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1710) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_30]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_30]
at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_30]
at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.0.0.GA-redhat-1.jar:2.0.0.GA-redhat-1]
{code}
I've ran the instances out of the box by this commands, binding them to virtual ips on my laptop:
{code}
server1/bin/standalone.sh -b 192.168.11.101 -c standalone-ha.xml -Djboss.bind.address.management=192.168.11.101 -Djboss.node.name=node1
server2/bin/standalone.sh -b 192.168.11.102 -c standalone-ha.xml -Djboss.bind.address.management=192.168.11.102 -Djboss.node.name=node2
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[View Less]
12 years, 3 months
[JBoss JIRA] (ISPN-1583) AbstractDelegatingAdvancedCache with(ClassLoader), withFlags(Flag...) logic is broken
by Paul Ferraro (Created) (JIRA)
AbstractDelegatingAdvancedCache with(ClassLoader), withFlags(Flag...) logic is broken
-------------------------------------------------------------------------------------
Key: ISPN-1583
URL: https://issues.jboss.org/browse/ISPN-1583
Project: Infinispan
Issue Type: Bug
Components: Core API
Affects Versions: 5.1.0.BETA5
Reporter: Paul Ferraro
Assignee: Manik Surtani
Priority: Critical
…
[View More]When the withFlags(...) logic was modified to use a DecoratedCache instead of thread-local storage, any caches already decorated with the AbstractDelegatingAdvancedCache(...) broke.
Take the following code:
AdvancedCache<K, V> baseCache;
AdvancedCache<K, V> customCache = new AbstractDelegatingAdvancedCache<K, V>(baseCache) {
public void clear() {
// custom clear logic
}
};
customCache.withFlags(Flag.CACHE_MODE_LOCAL).clear();
In the above statement, the flag is not applied.
The call to withFlags(...) returns a reference to customCache, and the reference to DecoratedCache containing the flags is lost to garbage collection.
In the case of with(ClassLoader) we have the opposite problem.
customCache.with(customClassLoader).clear();
In the above statement, the native clear() method is invoked instead of my custom clear() method. with(ClassLoader) returns a reference to DecoratedCache. The clear() method then operates on baseCache, instead of decoratedCache.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[View Less]
12 years, 3 months