May 2014 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-4277) ISPN server is not able to laod login modules

by Vojtech Juranek (JIRA)

Vojtech Juranek created ISPN-4277: ------------------------------------- Summary: ISPN server is not able to laod login modules Key: ISPN-4277 URL: https://issues.jboss.org/browse/ISPN-4277 Project: Infinispan Issue Type: Bug Components: Server Reporter: Vojtech Juranek Assignee: Mircea Markus JGroups within ISPN server with security turned on is not able to load login standard java login modules like Krb5LoginModule, resulting into exception {noformat} Caused by: javax.security.auth.login.LoginException: unable to find LoginModule class: com.sun.security.auth.module.Krb5LoginModule from [Module "org.jboss.as.clustering.jgroups:main" from local module loader @35ed35e0 (finder: local module finder @686c20c8 (roots: /infinispan/server/integration/testsuite/target/server/node1/modules,/infinispan/server/integration/testsuite/target/server/node1/modules/system/layers/base))] at javax.security.auth.login.LoginContext.invoke(LoginContext.java:822) [rt.jar:1.7.0_45] at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203) [rt.jar:1.7.0_45] at javax.security.auth.login.LoginContext$4.run(LoginContext.java:698) [rt.jar:1.7.0_45] at javax.security.auth.login.LoginContext$4.run(LoginContext.java:696) [rt.jar:1.7.0_45] at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_45] at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:695) [rt.jar:1.7.0_45] at javax.security.auth.login.LoginContext.login(LoginContext.java:594) [rt.jar:1.7.0_45] at org.jgroups.protocols.SASL.init(SASL.java:153) at org.jgroups.stack.ProtocolStack.initProtocolStack(ProtocolStack.java:861) at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:481) at org.jgroups.JChannel.init(JChannel.java:849) at org.jgroups.JChannel.<init>(JChannel.java:159) at org.jboss.as.clustering.jgroups.MuxChannel.<init>(MuxChannel.java:37) at org.jboss.as.clustering.jgroups.JChannelFactory.createChannel(JChannelFactory.java:81) at org.jboss.as.clustering.jgroups.subsystem.ChannelService.start(ChannelService.java:69) {noformat} Besides JDK login modules, th server should see also other standard JBoss login modules so that users can use whatever they are used to use in WildFly. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4240) Migrate one intermediate key/value per maxCollectorSize threshold

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-4240?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-4240: ------------------------------- Status: Pull Request Sent (was: Open) > Migrate one intermediate key/value per maxCollectorSize threshold > ----------------------------------------------------------------- > > Key: ISPN-4240 > URL: https://issues.jboss.org/browse/ISPN-4240 > Project: Infinispan > Issue Type: Enhancement > Components: Distributed Execution and Map/Reduce > Reporter: Vladimir Blagojevic > Assignee: Vladimir Blagojevic > Fix For: 7.0.0.Alpha4 > > > When we hit the maxCollectorSize threshold, we remove all the values from the collector and we start transferring them into the intermediary cache. But the other mapper threads keep working, and event with large collector sizes, it's very likely that the collector will be full again before we finished sending the previous batch. So we could end up with a lot of threads trying to insert maxCollectorSize values in the intermediary cache in parallel, and a lot more intermediary values in memory on each mapper node than the user would expect. > In order to alleviate this observed phenomena Dan proposed an idea to keep the maxCollectorSize threshold, but to only move a single key at a time from the collector to the intermediary cache when the threshold is hit (the least recently used one). That way, the other keys would have time to collect more values (or just run the combiner a few more times). > This way we still transfer some intermediate keys/values during map/combine phase rather than all at once at the end of that phase thus alleviating possibility of OOM. At the end of map/combine phase all remaining keys/values are of course transferred. Application users can fine tune their requirements and a specific use case using maxCollectorSize threshold. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4240) Migrate one intermediate key/value per maxCollectorSize threshold

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-4240?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-4240: ------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 7.0.0.Alpha4 Resolution: Done > Migrate one intermediate key/value per maxCollectorSize threshold > ----------------------------------------------------------------- > > Key: ISPN-4240 > URL: https://issues.jboss.org/browse/ISPN-4240 > Project: Infinispan > Issue Type: Enhancement > Components: Distributed Execution and Map/Reduce > Reporter: Vladimir Blagojevic > Assignee: Vladimir Blagojevic > Fix For: 7.0.0.Alpha4 > > > When we hit the maxCollectorSize threshold, we remove all the values from the collector and we start transferring them into the intermediary cache. But the other mapper threads keep working, and event with large collector sizes, it's very likely that the collector will be full again before we finished sending the previous batch. So we could end up with a lot of threads trying to insert maxCollectorSize values in the intermediary cache in parallel, and a lot more intermediary values in memory on each mapper node than the user would expect. > In order to alleviate this observed phenomena Dan proposed an idea to keep the maxCollectorSize threshold, but to only move a single key at a time from the collector to the intermediary cache when the threshold is hit (the least recently used one). That way, the other keys would have time to collect more values (or just run the combiner a few more times). > This way we still transfer some intermediate keys/values during map/combine phase rather than all at once at the end of that phase thus alleviating possibility of OOM. At the end of map/combine phase all remaining keys/values are of course transferred. Application users can fine tune their requirements and a specific use case using maxCollectorSize threshold. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4240) Migrate one intermediate key/value per maxCollectorSize threshold

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4240?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4240: ----------------------------------------------- Dan Berindei <dberinde(a)redhat.com> changed the Status of [bug 1096467|https://bugzilla.redhat.com/show_bug.cgi?id=1096467] from NEW to POST > Migrate one intermediate key/value per maxCollectorSize threshold > ----------------------------------------------------------------- > > Key: ISPN-4240 > URL: https://issues.jboss.org/browse/ISPN-4240 > Project: Infinispan > Issue Type: Enhancement > Components: Distributed Execution and Map/Reduce > Reporter: Vladimir Blagojevic > Assignee: Vladimir Blagojevic > > When we hit the maxCollectorSize threshold, we remove all the values from the collector and we start transferring them into the intermediary cache. But the other mapper threads keep working, and event with large collector sizes, it's very likely that the collector will be full again before we finished sending the previous batch. So we could end up with a lot of threads trying to insert maxCollectorSize values in the intermediary cache in parallel, and a lot more intermediary values in memory on each mapper node than the user would expect. > In order to alleviate this observed phenomena Dan proposed an idea to keep the maxCollectorSize threshold, but to only move a single key at a time from the collector to the intermediary cache when the threshold is hit (the least recently used one). That way, the other keys would have time to collect more values (or just run the combiner a few more times). > This way we still transfer some intermediate keys/values during map/combine phase rather than all at once at the end of that phase thus alleviating possibility of OOM. At the end of map/combine phase all remaining keys/values are of course transferred. Application users can fine tune their requirements and a specific use case using maxCollectorSize threshold. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4160) Do not allow the state transfer chunk size to be <= 0

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4160?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4160: ----------------------------------------------- Dan Berindei <dberinde(a)redhat.com> changed the Status of [bug 1096466|https://bugzilla.redhat.com/show_bug.cgi?id=1096466] from NEW to POST > Do not allow the state transfer chunk size to be <= 0 > ----------------------------------------------------- > > Key: ISPN-4160 > URL: https://issues.jboss.org/browse/ISPN-4160 > Project: Infinispan > Issue Type: Task > Components: Configuration, State Transfer > Affects Versions: 7.0.0.Alpha1 > Reporter: Dan Berindei > Assignee: Vladimir Blagojevic > Fix For: 7.0.0.Alpha4 > > > The state transfer chunk size is used in other places as well, and the case of {{chunkSize <= 0}} has to be handled everywhere independently. StateTransferConfigurationBuilder should validate that {{chunkSize > 0}}, so that users of the chunk size setting don't need a default value. > The users will still be able to force state transfer to transfer everything at once with {{chunkSize == Integer.MAX_VALUE}}. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4218) Increase default maxCollectorSize for MapReduceTask

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4218?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4218: ----------------------------------------------- Dan Berindei <dberinde(a)redhat.com> changed the Status of [bug 1096468|https://bugzilla.redhat.com/show_bug.cgi?id=1096468] from NEW to POST > Increase default maxCollectorSize for MapReduceTask > --------------------------------------------------- > > Key: ISPN-4218 > URL: https://issues.jboss.org/browse/ISPN-4218 > Project: Infinispan > Issue Type: Enhancement > Components: Distributed Execution and Map/Reduce > Reporter: Vladimir Blagojevic > Assignee: Vladimir Blagojevic > Priority: Minor > Fix For: 7.0.0.Alpha4, 7.0.0.Final > > > During performance testing we have found that the value of around 10K leads to a better performance of large map/reduce tasks containing more than 100K of cache entries. We have concluded that the current default value of 1024 is too small. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3894) SingleFileStore can optimize space usage by coalescing adjacent free entry blocks.

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3894?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-3894: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1096727 > SingleFileStore can optimize space usage by coalescing adjacent free entry blocks. > ---------------------------------------------------------------------------------- > > Key: ISPN-3894 > URL: https://issues.jboss.org/browse/ISPN-3894 > Project: Infinispan > Issue Type: Patch > Components: Loaders and Stores > Affects Versions: 6.0.0.Final > Environment: Oracle JDK 1.7, Windows Server 2008 R2 > Reporter: Rajesh Jangam > Assignee: Dan Berindei > Fix For: 7.0.0.Alpha4 > > Attachments: CoalesceEntries.java > > > This issue is related to issue ISPN-3877. > Here we have a use case where the size of the entries gradually keeps on increasing and then finally those entries expire. > 1. Smaller entries expire and new bigger entries start getting added > 2. These new bigger entries will not fit into the free slots (entries) created due to the expiry of smaller entries. > 3. Thus, these new bigger entries only get allocated at the end of the file resulting in growth of file size. > The optimization proposed is to: > 1. Coalesce/Combine adjacent free entries during the periodic purge cycle to create bigger/larger free entries. > 2. While allocating from an existing free entry, check if the size of the free entry is more than required for the new request being allocated. If yes, then, split the free entry into two free entries: > a. First part equal to the length being requested > This is returned as a part of the allocation activity. > b. Second part equal to the remainder of the space. > This added back as a free entry to the freeList. > Thus free space created due to expiry of smaller entries becomes available for consumption for the larger entries to some extent. > This reduces file size of the store. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3877) SingleFileStore continues to consume space on the disk even if the free entries at end of the file are not in use. This space can be released back to the filesystem

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3877?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-3877: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1096726 > SingleFileStore continues to consume space on the disk even if the free entries at end of the file are not in use. This space can be released back to the filesystem > -------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: ISPN-3877 > URL: https://issues.jboss.org/browse/ISPN-3877 > Project: Infinispan > Issue Type: Patch > Components: Loaders and Stores > Affects Versions: 6.0.0.Final > Environment: Oracle JDK 1.7, Windows Server 2008 R2 x64 > Reporter: Rajesh Jangam > Assignee: Dan Berindei > Fix For: 7.0.0.Alpha4 > > Attachments: PersistentQueue.java > > > We are testing the latest Infinispan 6.0 SingleFileStore version for our application. > We tend to create a lot of entries in the store and remove them when not required. > However, what we have observed is that the size of the file keeps on increasing as more data is being added/removed and that it does not get reclaimed. > > This was not seen with earlier versions like 5.3.0. There the size of the cache folder would reduce as entries got removed. > We have attempted to create a fix for this issue and tested it in our environment. It keeps the space usage under control as compared to the original implementation. > As a part of this fix, we truncate the file (as a part of purge cycle) if there are free entries found towards the end of the file. Also these free entries are removed from the freeList. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4275) Create server integration tests for HotRod SASL auth

by Vojtech Juranek (JIRA)

[ https://issues.jboss.org/browse/ISPN-4275?page=com.atlassian.jira.plugin.... ] Vojtech Juranek commented on ISPN-4275: --------------------------------------- The HR auth should be implemented following commits: https://github.com/infinispan/infinispan/commit/5eaf65b98839e685a26b5564e... https://github.com/infinispan/infinispan/commit/5797b2dcd9734a11165db675f... https://github.com/infinispan/infinispan/commit/2af64c9cdc42e73c27c98c0a9... > Create server integration tests for HotRod SASL auth > ---------------------------------------------------- > > Key: ISPN-4275 > URL: https://issues.jboss.org/browse/ISPN-4275 > Project: Infinispan > Issue Type: Feature Request > Components: Test Suite - Server > Reporter: Vojtech Juranek > Assignee: Vojtech Juranek > > Create server integration tests for HotRod SASL auth. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4250) PR for ISPN-4190 causes a performance drop in repl mode

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-4250?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-4250: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > PR for ISPN-4190 causes a performance drop in repl mode > ------------------------------------------------------- > > Key: ISPN-4250 > URL: https://issues.jboss.org/browse/ISPN-4250 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.0.0.Alpha4 > Reporter: Jakub Markos > Assignee: William Burns > Fix For: 7.0.0.Alpha4 > > -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues May 2014