September 2012 - infinispan-issues

[JBoss JIRA] (ISPN-2008) Optimistic concurrency in REST server is not using atomic operations

by Eugen Dück (JIRA)

Eugen Dück created ISPN-2008: -------------------------------- Summary: Optimistic concurrency in REST server is not using atomic operations Key: ISPN-2008 URL: https://issues.jboss.org/browse/ISPN-2008 Project: Infinispan Issue Type: Bug Affects Versions: 5.1.4.CR1 Reporter: Eugen Dück Assignee: Manik Surtani The REST server's optimistic currency control is not atomic. The sequence in e.g. a PUT request goes like this: * request.evaluatePreconditions * cache.put (if preconditions met) Which is not inside any lock (that would make it pessimistic, anyway), in other words, a race condition. This applies to the optimistic variants of PUT, POST, and DELETE. -- 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

11 years, 4 months

4
9
0 / 0

[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-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

11 years, 4 months

4
8
0 / 0

[JBoss JIRA] (ISPN-2176) Test LocalKeyAffinityServiceTest.testFilteredSingleKey fail randomly

by Martin Gencur (JIRA)

Martin Gencur created ISPN-2176: ----------------------------------- Summary: Test LocalKeyAffinityServiceTest.testFilteredSingleKey fail randomly Key: ISPN-2176 URL: https://issues.jboss.org/browse/ISPN-2176 Project: Infinispan Issue Type: Task Affects Versions: 5.1.6.FINAL (JDG) Reporter: Martin Gencur Assignee: Tristan Tarrant Priority: Minor Example failure can be found at https://hudson.qa.jboss.com/hudson/view/EDG6/view/EDG-REPORTS-FUNC/job/ed... In the next run everything was fine: https://hudson.qa.jboss.com/hudson/view/EDG6/view/EDG-REPORTS-FUNC/job/ed... -- 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

11 years, 4 months

5
14
0 / 0

[JBoss JIRA] (ISPN-2318) Reimplement a Topology-Aware Consistent Hash

by Erik Salter (JIRA)

Erik Salter created ISPN-2318: --------------------------------- Summary: Reimplement a Topology-Aware Consistent Hash Key: ISPN-2318 URL: https://issues.jboss.org/browse/ISPN-2318 Project: Infinispan Issue Type: Task Components: Core API Affects Versions: 5.2.0.Alpha3 Reporter: Erik Salter Assignee: Mircea Markus Even with the advent of x-site replication, the TACH is useful to stripe key ownership across machines and/or racks for resiliency. This feature should be refactored from the 5.1 impl. -- 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

11 years, 4 months

5
19
0 / 0

[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 (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

11 years, 4 months

4
14
0 / 0

[JBoss JIRA] (ISPN-2315) PessimisticDistTxTest.testTxInProgress2 fails randomly

by Galder Zamarreño (JIRA)

Galder Zamarreño created ISPN-2315: -------------------------------------- Summary: PessimisticDistTxTest.testTxInProgress2 fails randomly Key: ISPN-2315 URL: https://issues.jboss.org/browse/ISPN-2315 Project: Infinispan Issue Type: Bug Reporter: Galder Zamarreño Assignee: Mircea Markus Fix For: 5.2.0.CR1 {code}Failed tests: testTxInProgress2(org.infinispan.tx.locking.PessimisticDistTxTest): expected:<false> but was:<true>{code} Logs: https://dl.dropbox.com/u/6148072/testTxInProgress2-0.tgz -- 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

11 years, 4 months

3
10
0 / 0

[JBoss JIRA] (ISPN-2162) ParallelCacheStartTest.testParallelStartup fails randomly

by Galder Zamarreño (JIRA)

Galder Zamarreño created ISPN-2162: -------------------------------------- Summary: ParallelCacheStartTest.testParallelStartup fails randomly Key: ISPN-2162 URL: https://issues.jboss.org/browse/ISPN-2162 Project: Infinispan Issue Type: Bug Components: Test Suite Reporter: Galder Zamarreño Assignee: Dan Berindei Fix For: 5.2.0.ALPHA2 Failed tests: testParallelStartup(org.infinispan.api.ParallelCacheStartTest): Timed out before caches had complete views. Expected 1 members in each view. Views are as follows: [[ParallelCacheStartTest-NodeA-41416, ParallelCacheStartTest-NodeB-21482]] -- 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

11 years, 4 months

4
14
0 / 0

[JBoss JIRA] (ISPN-1855) Accessing a non-distributed cache from a RemoteCacheManager can break topology updates

by Dan Berindei (JIRA)

Dan Berindei created ISPN-1855: ---------------------------------- Summary: Accessing a non-distributed cache from a RemoteCacheManager can break topology updates Key: ISPN-1855 URL: https://issues.jboss.org/browse/ISPN-1855 Project: Infinispan Issue Type: Bug Affects Versions: 5.1.1.FINAL Reporter: Dan Berindei Assignee: Manik Surtani Fix For: 5.2.0.FINAL RemoteCacheManager uses a single consistent hash to map requests to different servers, but caches on the server may have different CHs (or even no CH if the cache is not in distributed mode). If the first request goes to a on-distributed cache, the client will never request an updated CH and so it will use a round robin strategy for routing request to all the caches. Obviously this is not optimal for distributed caches. Each distributed cache can also have different members since 5.1, so it would be best if we kept a separate CH per cache on the client. -- 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

11 years, 4 months

3
4
0 / 0

[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 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

11 years, 4 months

7
10
0 / 0

[JBoss JIRA] (ISPN-2209) HotRod client occasionally reports invalid magic number in elasticity tests

by Tristan Tarrant (JIRA)

Tristan Tarrant created ISPN-2209: ------------------------------------- Summary: HotRod client occasionally reports invalid magic number in elasticity tests Key: ISPN-2209 URL: https://issues.jboss.org/browse/ISPN-2209 Project: Infinispan Issue Type: Bug Components: Cache Server Affects Versions: 5.1.5.FINAL Environment: Hyperion w/32 nodes Reporter: Tristan Tarrant Assignee: Galder Zamarreño Fix For: 5.1.x, 5.2.0.FINAL During a 32-node elasticity tests, HotRod clients report "invalid magic number" -- 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

11 years, 4 months

3
10
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues September 2012