July 2014 - infinispan-issues - Jboss List Archives

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

9 years, 10 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)

9 years, 10 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)

9 years, 10 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)

9 years, 10 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)

9 years, 10 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)

9 years, 10 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)

9 years, 10 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)

9 years, 10 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)

9 years, 10 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 updated ISPN-4480: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1104045 > 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)

9 years, 10 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues July 2014