November 2014 - infinispan-issues

[JBoss JIRA] (ISPN-4972) Two concurrent replaceWithVersions may both succeed

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-4972?page=com.atlassian.jira.plugin.... ] Radim Vansa commented on ISPN-4972: ----------------------------------- It's not a bug of Infinispan internal operation, but HotRod API is based on the version, you're not providing the old value. Logically, one replace request had to change the version, and therefore, the second one should fail. > Two concurrent replaceWithVersions may both succeed > --------------------------------------------------- > > Key: ISPN-4972 > URL: https://issues.jboss.org/browse/ISPN-4972 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols > Affects Versions: 7.0.0.Final > Reporter: Radim Vansa > > Cache contains entry {{K = V}}. Two concurrent threads, that execute: > {code} > long version = cache.getVersioned(K).getVersion(); > boolean succeeded = cache.replaceWithVersion(K, V, version); > {code} > Both of these threads can get {{succeeded = true}}. > Reason: > When the server receives the operation ReplaceIfUnmodified=replaceWithVersion, it retrieves the entry (key + value + metadata) from the cache and checks that the version stored (in metadata) is the same as the version in the request. If so, it creates conditional ReplaceCommand which contains the value (retrieved atomically with version from the cache) and executes this one. Therefore, as the value is in both requests identical (and is not changed by the replace), two concurrent ReplaceCommands can both succeed, and this value is returned to the HotRod client. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3729) Minimize the number of moved segments for SyncConsistentHashFactory

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3729?page=com.atlassian.jira.plugin.... ] Dan Berindei reassigned ISPN-3729: ---------------------------------- Assignee: Dan Berindei > Minimize the number of moved segments for SyncConsistentHashFactory > ------------------------------------------------------------------- > > Key: ISPN-3729 > URL: https://issues.jboss.org/browse/ISPN-3729 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 6.0.0.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 7.1.0.Final > > > SyncConsistentHash uses an algorithm that's similar to consistent hashing, but when there is a collision (two nodes map to the same segment), the second node is moved to the next segment. Since the nodes are ordered by their UUID, that means it's possible for a joiner to change the mapping of existing nodes. > In order to make the load distribution more even, SyncConsistentHash also uses "virtual nodes": each node actually maps to multiple segments. This makes the number of collisions much higher (and implicitly, the number of extra moved segments). > Reading the original [consistent hashing paper|http://thor.cs.ucsb.edu/~ravenben/papers/coreos/kll%2B97.pdf], it looks like the collision handling should be done differently: a joiner should replace an existing node when it's "closer" to the segment boundary, but the existing node should never "move" to another segment (the property of monotonicity mentioned in the paper). We should investigate whether changing this would allow us to achieve better load balancing by using a much higher number of "virtual nodes" (without moving extra segments). If successful, we could even use SyncConsistentHashFactory as the default hash algorithm. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2133) Provide a context for object de-serialization

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/ISPN-2133?page=com.atlassian.jira.plugin.... ] Sanne Grinovero updated ISPN-2133: ---------------------------------- Labels: SLOWING_OGM (was: ) > Provide a context for object de-serialization > --------------------------------------------- > > Key: ISPN-2133 > URL: https://issues.jboss.org/browse/ISPN-2133 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Reporter: Sanne Grinovero > Labels: SLOWING_OGM > > See proposal description at > http://lists.jboss.org/pipermail/infinispan-dev/2012-June/010925.html -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3729) Minimize the number of moved segments for SyncConsistentHashFactory

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3729?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-3729: ---------------------------------- Fix Version/s: 7.1.0.Final (was: 7.1.0.Alpha1) > Minimize the number of moved segments for SyncConsistentHashFactory > ------------------------------------------------------------------- > > Key: ISPN-3729 > URL: https://issues.jboss.org/browse/ISPN-3729 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 6.0.0.Final > Reporter: Dan Berindei > Fix For: 7.1.0.Final > > > SyncConsistentHash uses an algorithm that's similar to consistent hashing, but when there is a collision (two nodes map to the same segment), the second node is moved to the next segment. Since the nodes are ordered by their UUID, that means it's possible for a joiner to change the mapping of existing nodes. > In order to make the load distribution more even, SyncConsistentHash also uses "virtual nodes": each node actually maps to multiple segments. This makes the number of collisions much higher (and implicitly, the number of extra moved segments). > Reading the original [consistent hashing paper|http://thor.cs.ucsb.edu/~ravenben/papers/coreos/kll%2B97.pdf], it looks like the collision handling should be done differently: a joiner should replace an existing node when it's "closer" to the segment boundary, but the existing node should never "move" to another segment (the property of monotonicity mentioned in the paper). We should investigate whether changing this would allow us to achieve better load balancing by using a much higher number of "virtual nodes" (without moving extra segments). If successful, we could even use SyncConsistentHashFactory as the default hash algorithm. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4972) Two concurrent replaceWithVersions may both succeed

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-4972?page=com.atlassian.jira.plugin.... ] Galder Zamarreño commented on ISPN-4972: ---------------------------------------- I’m not sure this is a bug at all. If the values are equal, ReplaceIfUnmodified returning true could be valid. IOW, it’s replaced the value and the value is... the same one :|. To take a CHM as an example: {code} ConcurrentMap chm = new ConcurrentHashMap[Integer, String]() chm.put(1, "v1”) chm.replace(1, "v1", "v1”) // returns true {code} > Two concurrent replaceWithVersions may both succeed > --------------------------------------------------- > > Key: ISPN-4972 > URL: https://issues.jboss.org/browse/ISPN-4972 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols > Affects Versions: 7.0.0.Final > Reporter: Radim Vansa > > Cache contains entry {{K = V}}. Two concurrent threads, that execute: > {code} > long version = cache.getVersioned(K).getVersion(); > boolean succeeded = cache.replaceWithVersion(K, V, version); > {code} > Both of these threads can get {{succeeded = true}}. > Reason: > When the server receives the operation ReplaceIfUnmodified=replaceWithVersion, it retrieves the entry (key + value + metadata) from the cache and checks that the version stored (in metadata) is the same as the version in the request. If so, it creates conditional ReplaceCommand which contains the value (retrieved atomically with version from the cache) and executes this one. Therefore, as the value is in both requests identical (and is not changed by the replace), two concurrent ReplaceCommands can both succeed, and this value is returned to the HotRod client. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2133) Provide a context for object de-serialization

by Emmanuel Bernard (JIRA)

[ https://issues.jboss.org/browse/ISPN-2133?page=com.atlassian.jira.plugin.... ] Emmanuel Bernard commented on ISPN-2133: ---------------------------------------- Another issue that is making OGM a bit less efficient than it should. Should we create a tag SLOWING_OGM? > Provide a context for object de-serialization > --------------------------------------------- > > Key: ISPN-2133 > URL: https://issues.jboss.org/browse/ISPN-2133 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Reporter: Sanne Grinovero > > See proposal description at > http://lists.jboss.org/pipermail/infinispan-dev/2012-June/010925.html -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4969) Stopping a cache will stop all KeyAffinityServices created for other caches in the cache manager

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-4969?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-4969: ----------------------------------- Assignee: Paul Ferraro (was: Galder Zamarreño) > Stopping a cache will stop all KeyAffinityServices created for other caches in the cache manager > ------------------------------------------------------------------------------------------------ > > Key: ISPN-4969 > URL: https://issues.jboss.org/browse/ISPN-4969 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 5.2.8.Final, 6.0.2.Final, 7.0.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Critical > Fix For: 7.0.1.Final > > > We've had several reports in the WildFly forums of application runtime failures following undeployment of a separate application. > WF creates a cache instance for each web application within the same cache container. However, KeyAffinityServiceImpl registers a cache manager listener that calls stop() on a @CacheStoppedEvent. However, this event might be triggered by any cache, not necessarily the cache with to which the KeyAffinityService is associated. > The KeyAffinityServiceImpl.handleCacheStopped(CacheStoppedEvent) should only call stop() if the event.getCacheName() equals the name of the cache to which the affinity service is associated. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4920) CancelledKeyException should stop client event reader

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4920?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4920: ----------------------------------------------- Sebastian Łaskawiec <slaskawi(a)redhat.com> changed the Status of [bug 1158499|https://bugzilla.redhat.com/show_bug.cgi?id=1158499] from NEW to MODIFIED > CancelledKeyException should stop client event reader > ----------------------------------------------------- > > Key: ISPN-4920 > URL: https://issues.jboss.org/browse/ISPN-4920 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols > Affects Versions: 7.0.0.CR2 > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 7.0.0.Final > > > {code} > 04:13:05,785 INFO [TestsuiteListener] (main) Running org.infinispan.server.test.client.hotrod.HotRodRemoteCacheIT#testCustomEventsDynamic > 04:13:06,005 WARN [ClientListenerNotifier] (HotRod-client-async-pool-2) ISPN004039: Unable to complete reading event from server null > java.nio.channels.CancelledKeyException > at sun.nio.ch.SelectionKeyImpl.ensureValid(SelectionKeyImpl.java:73) > at sun.nio.ch.SelectionKeyImpl.readyOps(SelectionKeyImpl.java:87) > at java.nio.channels.SelectionKey.isReadable(SelectionKey.java:289) > at sun.nio.ch.SocketAdaptor$SocketInputStream.read(SocketAdaptor.java:222) > at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:103) > at java.io.BufferedInputStream.fill(BufferedInputStream.java:235) > at java.io.BufferedInputStream.read(BufferedInputStream.java:254) > at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransport.readByte(TcpTransport.java:179) > at org.infinispan.client.hotrod.impl.protocol.Codec20.readMagic(Codec20.java:245) > at org.infinispan.client.hotrod.impl.protocol.Codec20.readEvent(Codec20.java:101) > at org.infinispan.client.hotrod.event.ClientListenerNotifier$EventDispatcher.run(ClientListenerNotifier.java:229) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask.run(FutureTask.java:262) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:745) > 04:13:06,011 INFO [TestsuiteListener] (main) Running org.infinispan.server.test.client.hotrod.HotRodRemoteCacheIT#testRemoveWithVersionAsync > 04:13:06,030 WARN [ClientListenerNotifier] (HotRod-client-async-pool-2) ISPN004039: Unable to complete reading event from server null > java.nio.channels.IllegalBlockingModeException > at sun.nio.ch.SocketAdaptor$SocketInputStream.read(SocketAdaptor.java:201) > at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:103) > at java.io.BufferedInputStream.fill(BufferedInputStream.java:235) > at java.io.BufferedInputStream.read(BufferedInputStream.java:254) > at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransport.readByte(TcpTransport.java:179) > at org.infinispan.client.hotrod.impl.protocol.Codec20.readMagic(Codec20.java:245) > at org.infinispan.client.hotrod.impl.protocol.Codec20.readEvent(Codec20.java:101) > at org.infinispan.client.hotrod.event.ClientListenerNotifier$EventDispatcher.run(ClientListenerNotifier.java:229) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask.run(FutureTask.java:262) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:745) > {code} > The IllegalBlockingModeException then repeats for several tens/hundreds of MB of lines > {code} > Also fails in HotRodCustomMarshallerEventIT: > 05:39:05,133 INFO [TestsuiteListener] (main) Running org.infinispan.server.test.client.hotrod.HotRodCustomMarshallerEventIT#testEventReceiveBasic > 05:39:05,267 INFO [RemoteCacheManager] (main) ISPN004021: Infinispan version: 6.2.0.ER2-redhat-1 > 05:39:05,313 WARN [ClientListenerNotifier] (HotRod-client-async-pool-0) ISPN004039: Unable to complete reading event from server null > java.nio.channels.CancelledKeyException > at sun.nio.ch.SelectionKeyImpl.ensureValid(SelectionKeyImpl.java:73) > at sun.nio.ch.SelectionKeyImpl.readyOps(SelectionKeyImpl.java:87) > at java.nio.channels.SelectionKey.isReadable(SelectionKey.java:289) > at sun.nio.ch.SocketAdaptor$SocketInputStream.read(SocketAdaptor.java:222) > at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:103) > at java.io.BufferedInputStream.fill(BufferedInputStream.java:235) > at java.io.BufferedInputStream.read(BufferedInputStream.java:254) > at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransport.readByte(TcpTransport.java:179) > at org.infinispan.client.hotrod.impl.protocol.Codec20.readMagic(Codec20.java:245) > at org.infinispan.client.hotrod.impl.protocol.Codec20.readEvent(Codec20.java:101) > at org.infinispan.client.hotrod.event.ClientListenerNotifier$EventDispatcher.run(ClientListenerNotifier.java:229) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask.run(FutureTask.java:262) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:745) > 05:39:05,315 WARN [ClientListenerNotifier] (HotRod-client-async-pool-0) ISPN004039: Unable to complete reading event from server null > java.nio.channels.IllegalBlockingModeException > at sun.nio.ch.SocketAdaptor$SocketInputStream.read(SocketAdaptor.java:201) > at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:103) > at java.io.BufferedInputStream.fill(BufferedInputStream.java:235) > at java.io.BufferedInputStream.read(BufferedInputStream.java:254) > at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransport.readByte(TcpTransport.java:179) > at org.infinispan.client.hotrod.impl.protocol.Codec20.readMagic(Codec20.java:245) > at org.infinispan.client.hotrod.impl.protocol.Codec20.readEvent(Codec20.java:101) > at org.infinispan.client.hotrod.event.ClientListenerNotifier$EventDispatcher.run(ClientListenerNotifier.java:229) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask.run(FutureTask.java:262) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:745) > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4967) Deprecate ProtobufMetadataManagerMBean.registerProtofiles(String... classPathResources)

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4967?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4967: ----------------------------------------------- Sebastian Łaskawiec <slaskawi(a)redhat.com> changed the Status of [bug 1163031|https://bugzilla.redhat.com/show_bug.cgi?id=1163031] from POST to MODIFIED > Deprecate ProtobufMetadataManagerMBean.registerProtofiles(String... classPathResources) > --------------------------------------------------------------------------------------- > > Key: ISPN-4967 > URL: https://issues.jboss.org/browse/ISPN-4967 > Project: Infinispan > Issue Type: Task > Components: Remote Querying > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 7.1.0.Alpha1 > > > This method should no longer be used as there are better alternatives in ProtobufMetadataManagerMBean. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4873) Statetransfer thread pool deadlock

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4873?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4873: ----------------------------------------------- Sebastian Łaskawiec <slaskawi(a)redhat.com> changed the Status of [bug 1156332|https://bugzilla.redhat.com/show_bug.cgi?id=1156332] from ON_QA to MODIFIED > Statetransfer thread pool deadlock > ---------------------------------- > > Key: ISPN-4873 > URL: https://issues.jboss.org/browse/ISPN-4873 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 6.0.2.Final > Reporter: Takayoshi Kimura > Assignee: Dan Berindei > Fix For: 7.1.0.Alpha1 > > > During massive state transfer with 300 nodes and 3000 caches, the OOB and/or infinispan thread pool gets deadlock, similar to ISPN-2808. > The thread pool is configured with max 1400 threads now and increasing them is not a realistic workaround as the user is planning to add more caches. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 5 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues November 2014