May 2014 - infinispan-issues - Jboss List Archives

[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 updated ISPN-4160: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1096466 > 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)

11 years, 11 months

1
0
0 / 0

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

by Vojtech Juranek (JIRA)

Vojtech Juranek created ISPN-4275: ------------------------------------- Summary: 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)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4274) Calling Advanced.Cache.lock with SKIP_LOCKING flag reports it locked the entry

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-4274?page=com.atlassian.jira.plugin.... ] William Burns commented on ISPN-4274: ------------------------------------- <wburns> what did you think about the exception thing btw? <dberindei> ah right, that too <dberindei> I tried to come up with a use case for passing a cache.withFlags(SKIP_LOCKING) to another method because it can't be modified to remove the locking <dberindei> but the truth is I don't see a use case for skipping locking in user code at all :) <wburns> yeah agree, but even in that case <wburns> shouldn't we be able to detect the flag and not send the lock command? <dberindei> isn't that what we do now? <dberindei> I mean what my PR does? <wburns> yes, but shouldn't that mean we are covered? <wburns> if a user does do cache.getAdvancedCache().withFlags(SKIP_LOCKING).put(...) <wburns> shouldn't it just do the put without locking? <dberindei> the user can call AdvancedCache.lock() <wburns> true, but in that case I think I would expect it to be locked <wburns> and an exception being returned seems good to me <dberindei> that's what I meant, I'm struggling to find a case where you'd want to call lock() explicitly and not lock anything :) <wburns> ah gotcha <wburns> or we could make lock always return false <wburns> lol <dberindei> nope, the javadoc says we can only return false with FAIL_SILENTLY :) <wburns> haha yeah I know but it is 7.0 :) <wburns> but you are doing this for jdg6.3 as well <dberindei> yeah, it would be nice to get it in jdg <wburns> I wonder if jdg requires us to lock it still then <dberindei> well, the old code didn't lock <dberindei> it's just that it was hidden in the LockManager, I think <wburns> unfortunately <wburns> it looks like it locked <wburns> oh nvm sorry looking at wrong spot <dberindei> yeah, LockManagerImpl:173 <wburns> I was more worried about the remote part <dberindei> I don't think it did anything except register the tx on the remote nodes <dberindei> the skip_locking flag was still used <wburns> ah true, so just performance hit then <wburns> for a weird edge case :P <wburns> but either way returning true from lock seems wrong <dberindei> that's true > Calling Advanced.Cache.lock with SKIP_LOCKING flag reports it locked the entry > ------------------------------------------------------------------------------ > > Key: ISPN-4274 > URL: https://issues.jboss.org/browse/ISPN-4274 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 6.0.2.Final > Reporter: William Burns > Assignee: Dan Berindei > > Currently when SKIP_LOCKING is used as a flag on the cache and the lock command is called it will not acquire the lock for the given keys no matter what. However the command still returns true even though it hasn't acquired the lock. We should probably throw some kind of exception or change the API documentation regarding the lock method. > https://github.com/infinispan/infinispan/pull/2484#discussion_r12478627 -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4274) Calling Advanced.Cache.lock with SKIP_LOCKING flag reports it locked the entry

by William Burns (JIRA)

William Burns created ISPN-4274: ----------------------------------- Summary: Calling Advanced.Cache.lock with SKIP_LOCKING flag reports it locked the entry Key: ISPN-4274 URL: https://issues.jboss.org/browse/ISPN-4274 Project: Infinispan Issue Type: Bug Components: Core Affects Versions: 6.0.2.Final Reporter: William Burns Assignee: Dan Berindei Currently when SKIP_LOCKING is used as a flag on the cache and the lock command is called it will not acquire the lock for the given keys no matter what. However the command still returns true even though it hasn't acquired the lock. We should probably throw some kind of exception or change the API documentation regarding the lock method. https://github.com/infinispan/infinispan/pull/2484#discussion_r12478627 -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4273) Create server integration tests for jgroups SASL auth

by Vojtech Juranek (JIRA)

Vojtech Juranek created ISPN-4273: ------------------------------------- Summary: Create server integration tests for jgroups SASL auth Key: ISPN-4273 URL: https://issues.jboss.org/browse/ISPN-4273 Project: Infinispan Issue Type: Feature Request Components: Test Suite - Server Reporter: Vojtech Juranek Assignee: Vojtech Juranek Create integration tests for jgroups SASL auth via DIGECT-MD5 and GSSAPI mechs. JGroups auth SASL auth is contained in following commits: https://github.com/belaban/JGroups/commit/01100c4730cb3cb86a686bc8b2118ed... https://github.com/belaban/JGroups/commit/fd0710f358594c1bdc73137ea05902e... -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 11 months

1
0
0 / 0

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

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-4160?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-4160: ------------------------------- Status: Pull Request Sent (was: Open) > 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)

11 years, 11 months

1
0
0 / 0

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

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-4160?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-4160: ------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > 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)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3940) Fine-grained authorization interceptor

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3940?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-3940: ---------------------------------- Fix Version/s: 8.0.0.Final (was: 7.0.0.Final) > Fine-grained authorization interceptor > -------------------------------------- > > Key: ISPN-3940 > URL: https://issues.jboss.org/browse/ISPN-3940 > Project: Infinispan > Issue Type: Sub-task > Components: Core, Security > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 8.0.0.Final > > > Introduce an AuthorizationInterceptor which can allow/deny operations based on the the current AccessControlContext -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3931) Test Infinispan within a SecurityManager and provide a security policy

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3931?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-3931: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Test Infinispan within a SecurityManager and provide a security policy > ---------------------------------------------------------------------- > > Key: ISPN-3931 > URL: https://issues.jboss.org/browse/ISPN-3931 > Project: Infinispan > Issue Type: Sub-task > Components: Core, Remote Protocols, Security, Server > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 7.0.0.Final > > -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4269) Infinispan quickstarts clustered-cache does not compile

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-4269?page=com.atlassian.jira.plugin.... ] Dan Berindei resolved ISPN-4269. -------------------------------- Fix Version/s: 7.0.0.Alpha4 Resolution: Done I replaced the usage of {{List.sort()}} with {{Collections.sort()}} > Infinispan quickstarts clustered-cache does not compile > ------------------------------------------------------- > > Key: ISPN-4269 > URL: https://issues.jboss.org/browse/ISPN-4269 > Project: Infinispan > Issue Type: Bug > Components: Demos and Tutorials > Affects Versions: 6.0.2.Final > Reporter: Shaun Appleton > Assignee: Dan Berindei > Fix For: 7.0.0.Alpha4, 6.0.2.Final > > > Using https://github.com/infinispan/infinispan-quickstart and trying to build the clustered-cache example I get the following compilation error- > [sappleto@localhost clustered-cache]$ mvn clean compile dependency:copy-dependencies -DstripVersion > [INFO] Scanning for projects... > [INFO] > [INFO] ------------------------------------------------------------------------ > [INFO] Building Infinispan Clustered Cache Quickstart 5.0.0-SNAPSHOT > [INFO] ------------------------------------------------------------------------ > [INFO] > [INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @ clustered-cache-quickstart --- > [INFO] Deleting /home/sappleto/git/infinispan-quickstart/clustered-cache/target > [INFO] > [INFO] --- maven-resources-plugin:2.4.3:resources (default-resources) @ clustered-cache-quickstart --- > [INFO] Using 'UTF-8' encoding to copy filtered resources. > [INFO] Copying 3 resources > [INFO] > [INFO] --- maven-compiler-plugin:2.3.2:compile (default-compile) @ clustered-cache-quickstart --- > [INFO] Compiling 2 source files to /home/sappleto/git/infinispan-quickstart/clustered-cache/target/classes > [INFO] ------------------------------------------------------------- > [ERROR] COMPILATION ERROR : > [INFO] ------------------------------------------------------------- > [ERROR] /home/sappleto/git/infinispan-quickstart/clustered-cache/src/main/java/org/infinispan/quickstart/clusteredcache/Node.java:[126,13] cannot find symbol > symbol : method sort(<anonymous java.util.Comparator<java.util.Map.Entry<java.lang.String,java.lang.String>>>) > location: class java.util.ArrayList<java.util.Map.Entry<java.lang.String,java.lang.String>> > [INFO] 1 error > [INFO] ------------------------------------------------------------- > [INFO] ------------------------------------------------------------------------ > [INFO] BUILD FAILURE > [INFO] ------------------------------------------------------------------------ > [INFO] Total time: 4.472s > [INFO] Finished at: Tue May 06 15:36:48 BST 2014 > [INFO] Final Memory: 10M/102M > [INFO] ------------------------------------------------------------------------ > [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile (default-compile) on project clustered-cache-quickstart: Compilation failure > [ERROR] /home/sappleto/git/infinispan-quickstart/clustered-cache/src/main/java/org/infinispan/quickstart/clusteredcache/Node.java:[126,13] cannot find symbol > [ERROR] symbol : method sort(<anonymous java.util.Comparator<java.util.Map.Entry<java.lang.String,java.lang.String>>>) > [ERROR] location: class java.util.ArrayList<java.util.Map.Entry<java.lang.String,java.lang.String>> > [ERROR] -> [Help 1] > [ERROR] > [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. > [ERROR] Re-run Maven using the -X switch to enable full debug logging. > [ERROR] > [ERROR] For more information about the errors and possible solutions, please read the following articles: > [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException -- This message was sent by Atlassian JIRA (v6.2.3#6260)

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