July 2014 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-4424) getCacheEntry is not safe

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4424?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4424: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1110647|https://bugzilla.redhat.com/show_bug.cgi?id=1110647] from POST to MODIFIED > getCacheEntry is not safe > ------------------------- > > Key: ISPN-4424 > URL: https://issues.jboss.org/browse/ISPN-4424 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Remote Protocols > Affects Versions: 6.0.2.Final, 7.0.0.Alpha4 > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 7.0.0.Alpha5, 7.0.0.Final > > > Versioned update with a multi threaded Hot Rod client results in inconsistency. Some replaceWithVersion return true ignoring a version update executed in another thread. Here's a log excerpt of a concurrency stress test: > ``` > 2014-06-20 16:16:56,798 INFO [PutFromNull] (pool-7-thread-10) count=462,prev=462,new=463 > 2014-06-20 16:16:56,820 INFO [PutFromNull] (pool-7-thread-9) count=463,prev=463,new=464 > 2014-06-20 16:16:56,831 INFO [PutFromNull] (pool-7-thread-2) count=464,prev=463,new=464 > 2014-06-20 16:16:56,845 INFO [PutFromNull] (pool-7-thread-9) count=465,prev=464,new=465 > ``` > Here you see two threads applying the same replacement, from 463 to 464. > The issue appears a result of a race condition in Hot Rod server's protocol decoder. When replaceIfUmodified is received, the cache entry is retrieved to verify whether the version in the server and the version sent in the command match. However, the cache entry retrieved is mutable, and the value could change midway through this operation as a result of another thread updating the value. Please find below some log snippets showing this. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4451) Missing ACCESS right

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4451?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4451: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1113872|https://bugzilla.redhat.com/show_bug.cgi?id=1113872] from NEW to MODIFIED > Missing ACCESS right > -------------------- > > Key: ISPN-4451 > URL: https://issues.jboss.org/browse/ISPN-4451 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Security > Reporter: Vojtech Juranek > Assignee: Tristan Tarrant > > When security is turned on ({{cacheConfig.security().authorization().enable()}}), any user can obtain/create a cache, even unauthorized users. This should be allowed only for users with right {{ACCESS}}. This right is actually not present in {{AuthorizationPermission}}. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4431) CLI codecs do set entry version in metadata

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4431?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4431: ----------------------------------------------- Misha H. Ali <mhusnain(a)redhat.com> changed the Status of [bug 1116246|https://bugzilla.redhat.com/show_bug.cgi?id=1116246] from ASSIGNED to POST > CLI codecs do set entry version in metadata > ------------------------------------------- > > Key: ISPN-4431 > URL: https://issues.jboss.org/browse/ISPN-4431 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: CLI > Affects Versions: 7.0.0.Alpha4 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 7.0.0.Alpha5 > > > When the CLI writes to the cache using one of the server codecs it must set a version, because the server protocol handlers expect to find it -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4431) CLI codecs do set entry version in metadata

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4431?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4431: ----------------------------------------------- Misha H. Ali <mhusnain(a)redhat.com> changed the Status of [bug 1116246|https://bugzilla.redhat.com/show_bug.cgi?id=1116246] from NEW to ASSIGNED > CLI codecs do set entry version in metadata > ------------------------------------------- > > Key: ISPN-4431 > URL: https://issues.jboss.org/browse/ISPN-4431 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: CLI > Affects Versions: 7.0.0.Alpha4 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 7.0.0.Alpha5 > > > When the CLI writes to the cache using one of the server codecs it must set a version, because the server protocol handlers expect to find it -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4431) CLI codecs do set entry version in metadata

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4431?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-4431: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1101512, https://bugzilla.redhat.com/show_bug.cgi?id=1116246 > CLI codecs do set entry version in metadata > ------------------------------------------- > > Key: ISPN-4431 > URL: https://issues.jboss.org/browse/ISPN-4431 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: CLI > Affects Versions: 7.0.0.Alpha4 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 7.0.0.Alpha5 > > > When the CLI writes to the cache using one of the server codecs it must set a version, because the server protocol handlers expect to find it -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4482) Upgrade JGroups to 3.5.0.Beta9

by Vojtech Juranek (JIRA)

Vojtech Juranek created ISPN-4482: ------------------------------------- Summary: Upgrade JGroups to 3.5.0.Beta9 Key: ISPN-4482 URL: https://issues.jboss.org/browse/ISPN-4482 Project: Infinispan Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Core Reporter: Vojtech Juranek Assignee: Vojtech Juranek It contains various SASL fixes, like [JGRP-1848|https://issues.jboss.org/browse/JGRP-1848], [JGRP-1849|https://issues.jboss.org/browse/JGRP-1849], [JGRP-1852|https://issues.jboss.org/browse/JGRP-1852], [JGRP-1853|https://issues.jboss.org/browse/JGRP-1853] and other fixes. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4481) Use UNICAST3 in the default server configuration

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4481?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-4481: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1116105 > Use UNICAST3 in the default server configuration > ------------------------------------------------ > > Key: ISPN-4481 > URL: https://issues.jboss.org/browse/ISPN-4481 > Project: Infinispan > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Server > Affects Versions: 6.0.2.Final, 7.0.0.Alpha4 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 7.0.0.Alpha5 > > > We switched to UNICAST3 a while back in the default embedded configuration, we should switch the server configuration as well. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4481) Use UNICAST3 in the default server configuration

by Dan Berindei (JIRA)

Dan Berindei created ISPN-4481: ---------------------------------- Summary: Use UNICAST3 in the default server configuration Key: ISPN-4481 URL: https://issues.jboss.org/browse/ISPN-4481 Project: Infinispan Issue Type: Enhancement Security Level: Public (Everyone can see) Components: Server Affects Versions: 7.0.0.Alpha4, 6.0.2.Final Reporter: Dan Berindei Assignee: Dan Berindei Fix For: 7.0.0.Alpha5 We switched to UNICAST3 a while back in the default embedded configuration, we should switch the server configuration as well. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4471) MapReduceTask: memory leak with useIntermediateSharedCache = true

by Vladimir Blagojevic (JIRA)

[ https://issues.jboss.org/browse/ISPN-4471?page=com.atlassian.jira.plugin.... ] Vladimir Blagojevic commented on ISPN-4471: ------------------------------------------- Ready for integration. PR is https://github.com/infinispan/infinispan/pull/2693 > MapReduceTask: memory leak with useIntermediateSharedCache = true > ----------------------------------------------------------------- > > Key: ISPN-4471 > URL: https://issues.jboss.org/browse/ISPN-4471 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Distributed Execution and Map/Reduce > Affects Versions: 6.0.2.Final > Reporter: Rich DiCroce > Assignee: Vladimir Blagojevic > > When using an intermediate shared cache for the reduce phase, MapReduceTask puts the entries into the cache with no expiration and apparently never removes them. This eventually results in OutOfMemoryErrors. > One workaround is to disable use of the intermediate shared cache, which causes a new cache to be created and destroyed for every task, which "fixes" the problem of not removing intermediate values. However, it causes a ton of log spam: > {noformat} > 2014-07-02 11:55:10,014 INFO [org.infinispan.jmx.CacheJmxRegistration] (transport-thread-21) ISPN000031: MBeans were successfully registered to the platform MBean server. > 2014-07-02 11:55:10,016 INFO [org.jboss.as.clustering.infinispan] (transport-thread-21) JBAS010281: Started e71dddc0-60ce-4cb9-ac8c-615d60866393 cache from GamingPortal container > 2014-07-02 11:55:10,023 INFO [org.infinispan.jmx.CacheJmxRegistration] (transport-thread-5) ISPN000031: MBeans were successfully registered to the platform MBean server. > 2014-07-02 11:55:10,024 INFO [org.infinispan.jmx.CacheJmxRegistration] (transport-thread-4) ISPN000031: MBeans were successfully registered to the platform MBean server. > 2014-07-02 11:55:10,025 INFO [org.jboss.as.clustering.infinispan] (transport-thread-5) JBAS010281: Started 22d387d6-69c6-48b2-9701-ea64c08d66ad cache from GamingPortal container > 2014-07-02 11:55:10,026 INFO [org.jboss.as.clustering.infinispan] (transport-thread-4) JBAS010281: Started bfaf92a0-a030-4624-93a7-0fee097415d7 cache from NMS container > 2014-07-02 11:55:10,037 INFO [org.jboss.as.clustering.infinispan] (EJB default - 2) JBAS010282: Stopped 22d387d6-69c6-48b2-9701-ea64c08d66ad cache from GamingPortal container > 2014-07-02 11:55:10,040 INFO [org.jboss.as.clustering.infinispan] (EJB default - 1) JBAS010282: Stopped bfaf92a0-a030-4624-93a7-0fee097415d7 cache from NMS container > 2014-07-02 11:55:10,047 INFO [org.jboss.as.clustering.infinispan] (EJB default - 6) JBAS010282: Stopped e71dddc0-60ce-4cb9-ac8c-615d60866393 cache from GamingPortal container > 2014-07-02 11:55:10,047 INFO [org.infinispan.jmx.CacheJmxRegistration] (transport-thread-0) ISPN000031: MBeans were successfully registered to the platform MBean server. > 2014-07-02 11:55:10,048 INFO [org.jboss.as.clustering.infinispan] (transport-thread-0) JBAS010281: Started bed74bd3-a227-43e0-b262-62c19dd444a7 cache from GamingPortal container > 2014-07-02 11:55:10,052 INFO [org.jboss.as.clustering.infinispan] (EJB default - 2) JBAS010282: Stopped bed74bd3-a227-43e0-b262-62c19dd444a7 cache from GamingPortal container > 2014-07-02 11:55:10,063 INFO [org.infinispan.jmx.CacheJmxRegistration] (transport-thread-7) ISPN000031: MBeans were successfully registered to the platform MBean server. > 2014-07-02 11:55:10,064 INFO [org.jboss.as.clustering.infinispan] (transport-thread-7) JBAS010281: Started 63cce570-0169-40c2-bc9f-e045c2864702 cache from GamingPortal container > 2014-07-02 11:55:10,068 INFO [org.jboss.as.clustering.infinispan] (EJB default - 2) JBAS010282: Stopped 63cce570-0169-40c2-bc9f-e045c2864702 cache from GamingPortal container > 2014-07-02 11:55:10,072 INFO [org.infinispan.jmx.CacheJmxRegistration] (transport-thread-19) ISPN000031: MBeans were successfully registered to the platform MBean server. > 2014-07-02 11:55:10,073 INFO [org.jboss.as.clustering.infinispan] (transport-thread-19) JBAS010281: Started 83f7b355-d4c6-4a0a-aade-ce2509293d77 cache from GamingPortal container > 2014-07-02 11:55:10,077 INFO [org.jboss.as.clustering.infinispan] (EJB default - 2) JBAS010282: Stopped 83f7b355-d4c6-4a0a-aade-ce2509293d77 cache from GamingPortal container > {noformat} > I also observed one NullPointerException with distributeReducePhase = true and useIntermediateSharedCache = false. This could be related to ISPN-4460, but I'm not sure. > {noformat} > Caused by: org.infinispan.commons.CacheException: java.util.concurrent.ExecutionException: org.infinispan.commons.CacheException: java.lang.NullPointerException > at org.infinispan.distexec.mapreduce.MapReduceTask.execute(MapReduceTask.java:348) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > at org.infinispan.distexec.mapreduce.MapReduceTask.execute(MapReduceTask.java:634) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > at org.infinispan.distexec.mapreduce.MapReduceTask$3.call(MapReduceTask.java:652) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > at org.infinispan.distexec.mapreduce.MapReduceTask$MapReduceTaskFuture.get(MapReduceTask.java:760) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > ... 63 more > Caused by: java.util.concurrent.ExecutionException: org.infinispan.commons.CacheException: java.lang.NullPointerException > at java.util.concurrent.FutureTask.report(FutureTask.java:122) [rt.jar:1.7.0_45] > at java.util.concurrent.FutureTask.get(FutureTask.java:188) [rt.jar:1.7.0_45] > at org.infinispan.distexec.mapreduce.MapReduceTask$TaskPart.get(MapReduceTask.java:845) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > at org.infinispan.distexec.mapreduce.MapReduceTask.executeMapPhase(MapReduceTask.java:439) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > at org.infinispan.distexec.mapreduce.MapReduceTask.execute(MapReduceTask.java:342) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > ... 66 more > Caused by: org.infinispan.commons.CacheException: java.lang.NullPointerException > at org.infinispan.distexec.mapreduce.MapReduceManagerImpl.mapAndCombineForDistributedReduction(MapReduceManagerImpl.java:100) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > at org.infinispan.distexec.mapreduce.MapReduceTask$MapTaskPart.invokeMapCombineLocally(MapReduceTask.java:967) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > at org.infinispan.distexec.mapreduce.MapReduceTask$MapTaskPart.access$200(MapReduceTask.java:894) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > at org.infinispan.distexec.mapreduce.MapReduceTask$MapTaskPart$1.call(MapReduceTask.java:916) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > at org.infinispan.distexec.mapreduce.MapReduceTask$MapTaskPart$1.call(MapReduceTask.java:912) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > at java.util.concurrent.FutureTask.run(FutureTask.java:262) [rt.jar:1.7.0_45] > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_45] > at java.util.concurrent.FutureTask.run(FutureTask.java:262) [rt.jar:1.7.0_45] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45] > Caused by: java.lang.NullPointerException > at org.infinispan.distexec.mapreduce.MapReduceManagerImpl.mapKeysToNodes(MapReduceManagerImpl.java:355) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > at org.infinispan.distexec.mapreduce.MapReduceManagerImpl.migrateIntermediateKeys(MapReduceManagerImpl.java:264) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > at org.infinispan.distexec.mapreduce.MapReduceManagerImpl.combine(MapReduceManagerImpl.java:258) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > at org.infinispan.distexec.mapreduce.MapReduceManagerImpl.mapAndCombineForDistributedReduction(MapReduceManagerImpl.java:98) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > ... 10 more > {noformat} -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4480) Messages sent to leavers can clog the JGroups bundler thread

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4480?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4480: ----------------------------------------------- Dan Berindei <dberinde(a)redhat.com> changed the Status of [bug 1104045|https://bugzilla.redhat.com/show_bug.cgi?id=1104045] from NEW to ASSIGNED > Messages sent to leavers can clog the JGroups bundler thread > ------------------------------------------------------------ > > Key: ISPN-4480 > URL: https://issues.jboss.org/browse/ISPN-4480 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Core > Affects Versions: 6.0.2.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > > In a stress test that repeatedly kills nodes while performing read/write operations, the TransferQueueBundler thread seems to spend a lot of time waiting for physical addresses: > {noformat} > 06:40:10,316 WARN [org.radargun.utils.Utils] (pool-5-thread-1) Stack for thread TransferQueueBundler,default,apex953-14666: > java.lang.Thread.sleep(Native Method) > org.jgroups.util.Util.sleep(Util.java:1504) > org.jgroups.util.Util.sleepRandom(Util.java:1574) > org.jgroups.protocols.TP.sendToSingleMember(TP.java:1685) > org.jgroups.protocols.TP.doSend(TP.java:1670) > org.jgroups.protocols.TP$TransferQueueBundler.sendBundledMessages(TP.java:2476) > org.jgroups.protocols.TP$TransferQueueBundler.sendMessages(TP.java:2392) > org.jgroups.protocols.TP$TransferQueueBundler.run(TP.java:2383) > java.lang.Thread.run(Thread.java:744) > {noformat} > There are 2 bugs related to this already fixed in JGroups 3.5.0.Beta2+: JGRP-1814, JGRP-1815 > There is also a special case where the physical address could be removed from the cache too soon, exacerbating the effect of JGRP-1815: JGRP-1858 > We can work around the problem by changing the JGroups configuration: > * TP.logical_addr_cache_expiration=86400000 > ** Only expire addresses after 1 day > * TP.physical_addr_max_fetch_attempts=1 > ** Sleep for only 20ms waiting for the physical address (default 3 - 1500ms) > * UNICAST3_conn_close_timeout=10000 > ** Drop the pending messages to leavers sooner -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 9 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 July 2014