August 2012 - infinispan-issues - Jboss List Archives

[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

12 years

4
9
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

12 years

5
14
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

12 years

4
14
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

12 years

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

12 years

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

12 years

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

12 years

3
10
0 / 0

[JBoss JIRA] (ISPN-1822) Cache entry not evicted from memory on IBM JDK when another entry was loaded from a cache loader and maxEntries had been reached

by Martin Gencur (JIRA)

Martin Gencur created ISPN-1822: ----------------------------------- Summary: Cache entry not evicted from memory on IBM JDK when another entry was loaded from a cache loader and maxEntries had been reached Key: ISPN-1822 URL: https://issues.jboss.org/browse/ISPN-1822 Project: Infinispan Issue Type: Bug Components: Eviction Affects Versions: 5.1.0.FINAL Environment: java version "1.6.0" Java(TM) SE Runtime Environment (build pxi3260sr9fp1-20110208_03(SR9 FP1)) IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 Linux x86-32 jvmxi3260sr9-20110203_74623 (JIT enabled, AOT enabled) ; java version "1.7.0" Java(TM) SE Runtime Environment (build pxi3270-20110827_01) IBM J9 VM (build 2.6, JRE 1.7.0 Linux x86-32 20110810_88604 (JIT enabled, AOT enabled) Reporter: Martin Gencur Assignee: Manik Surtani This behavior is specific to IBM JDK (I tried JDK6 and 7), it works fine with Java HotSpot. Steps to reproduce the problem: 1) set maxEntries for eviction to 2 and algorithm e.g. to LRU 2) store 3 entries key1, key2, key3 to the cache (after that you can see that the cache contains only 2 entries - key2 and key3, the first one was evicted from memory) 3) call cache.get("key1") 4) PROBLEM - cache contains all key1, key2, key3 even though it should contain only 2 entries - only happens with IBM JDK (6 or 7 ..no matter) I'll shortly issue a pull request with a test to ispn-core -- 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

12 years

6
30
0 / 0

[JBoss JIRA] Created: (ISPN-928) Interceptor that allows invocations only when cluster is formed of N nodes

by Galder Zamarreño (JIRA)

Interceptor that allows invocations only when cluster is formed of N nodes -------------------------------------------------------------------------- Key: ISPN-928 URL: https://issues.jboss.org/browse/ISPN-928 Project: Infinispan Issue Type: Feature Request Components: Configuration, RPC Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 5.0.0.BETA1, 5.0.0.Final Following from https://github.com/pmuir/infinispan-examples/commit/f5d090092fa7b3660025b... It'd be great to have an configurable StrictCluster interceptor in Infinispan which would basically make all invocations wait until the cluster of N nodes has been formed. I think it'd be a great addition and would allow clients to verify whether the cluster actually forms without the need to verify whether data replicates...etc. In principle, the configuration would be at the CacheManager, i.e.: <transport strictNumMembers="4"... /> However, it could also be useful to configure it at the cache level. So, could maybe want to do this: I want cache X to allow invocations the moment I have 2 nodes (in spite of the cluster being formed of 4 noes), whereas I want cache Y to allow invocations once I have 3 nodes. Apart from an strict number of nodes, you could have a minimum number of nodes: allow invocations once I have 4 or more nodes. The strict value could still be useful to make sure intrusive machines don't get into the cluster, i.e. I expect 4 nodes in the cluster and if I have 5, something is wrong. I think it's an interesting concept that would get rid of cluster validation code in examples and RadarGun. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

1
4
0 / 0

[JBoss JIRA] (ISPN-2250) Handle all the remaining comments for the NBST pull reques

by Mircea Markus (JIRA)

Mircea Markus created ISPN-2250: ----------------------------------- Summary: Handle all the remaining comments for the NBST pull reques Key: ISPN-2250 URL: https://issues.jboss.org/browse/ISPN-2250 Project: Infinispan Issue Type: Bug Components: State transfer Affects Versions: 5.2.0.Alpha3 Reporter: Mircea Markus Assignee: Adrian Nistor Priority: Critical Fix For: 5.2.0.Alpha4 These are still visible even after the pull request is closed. Dan, please don't delete the t_nbst branch before handling these as we might loose them. -- 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

12 years

2
8
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues August 2012