June 2014 - infinispan-issues - Jboss List Archives

[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: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1101512|https://bugzilla.redhat.com/show_bug.cgi?id=1101512] from MODIFIED to ON_QA > 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 > > 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, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4070) Server plugin for RHQ needs extensions in management/monitoring

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4070?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4070: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1072349|https://bugzilla.redhat.com/show_bug.cgi?id=1072349] from MODIFIED to ON_QA > Server plugin for RHQ needs extensions in management/monitoring > --------------------------------------------------------------- > > Key: ISPN-4070 > URL: https://issues.jboss.org/browse/ISPN-4070 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JMX, reporting and management > Affects Versions: 6.0.1.Final > Reporter: Tomas Sykora > Assignee: William Burns > Labels: 630, 63gablocker > > InVM plugin for RHQ is generated automatically. However, the plugin for server is not and those are results of deeper analysis of RHQ ISPN server plugin (missing) possibilities. > JCONSOLE is showing number of statistics, traits and operations which are not incorporated in RHQ-plugin (*server* plugin). Some are quite important (start and stop ops for cache for example) and some might be only additional, not necessary - but still pleasant, information about a cluster/cache. > *Missing Cache traits:* > cacheName > version > configurationAsProperties > statisticsEnabled > *Missing from Cache statistics:* > averageRemoveTime > *Missing cache operations:* > START and STOP are missing!! > synchronizeData, disconnectSource, recordKnownGlobalKeyset - rolling upgrades related ops > *Missing cache manager traits:* > definedCacheCount > globalConfigurationAsProperties > clusterMembers > createdCacheCounts > definedCacheNames > clusterSize > version > runningCacheCount -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4420) Allow configuring keepalive for hotrod connections

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4420?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4420: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1111221|https://bugzilla.redhat.com/show_bug.cgi?id=1111221] from MODIFIED to ON_QA > Allow configuring keepalive for hotrod connections > -------------------------------------------------- > > Key: ISPN-4420 > URL: https://issues.jboss.org/browse/ISPN-4420 > Project: Infinispan > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Mircea Markus > Assignee: Mircea Markus > Fix For: 7.0.0.Alpha5, 7.0.0.Final > > > Also consider making the Tcp connections pluggable. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4424) ReplaceIfUnmodified is broken under concurrent execution

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 MODIFIED to ON_QA > ReplaceIfUnmodified is broken under concurrent execution > -------------------------------------------------------- > > 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)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4112) RHQ library plugin: restart cache -- availability report DOWN but cache running

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4112?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4112: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1076486|https://bugzilla.redhat.com/show_bug.cgi?id=1076486] from MODIFIED to ON_QA > RHQ library plugin: restart cache -- availability report DOWN but cache running > ------------------------------------------------------------------------------- > > Key: ISPN-4112 > URL: https://issues.jboss.org/browse/ISPN-4112 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JMX, reporting and management > Affects Versions: 6.0.1.Final, 7.0.0.Alpha1 > Reporter: Tomas Sykora > Assignee: William Burns > Labels: 63gablocker > Fix For: 7.0.0.Alpha5, 7.0.0.Final > > > When we explicitly call STOP operation on particular cache using RHQ UI, this operation is successfully issued and cache is stopped. > Then, we can issue START operation as well. > Cache is started but RHQ is still not-correctly reporting that cache is DOWN and unavailable. > I will investigate this issue, this is just for proper heads up and for tracking purposes. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4291) Poor REPL state transfer performance with cache stores

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4291?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4291: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1111188|https://bugzilla.redhat.com/show_bug.cgi?id=1111188] from MODIFIED to ON_QA > Poor REPL state transfer performance with cache stores > ------------------------------------------------------ > > Key: ISPN-4291 > URL: https://issues.jboss.org/browse/ISPN-4291 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: State Transfer > Affects Versions: 6.0.2.Final > Reporter: Dennis Reed > Assignee: Dan Berindei > Fix For: 7.0.0.Alpha5 > > > During a state transfer every single key is loaded from the cache store to determine whether it's still owned by the local node. > This is an extremely slow operation, and doesn't even make sense for a REPL cache. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3936) State transfer should not modify or iterate shared cache stores

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3936?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3936: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1113259|https://bugzilla.redhat.com/show_bug.cgi?id=1113259] from MODIFIED to ON_QA > State transfer should not modify or iterate shared cache stores > --------------------------------------------------------------- > > Key: ISPN-3936 > URL: https://issues.jboss.org/browse/ISPN-3936 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Core, State Transfer > Affects Versions: 6.0.0.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > Fix For: 7.0.0.Alpha3, 7.0.0.Final > > > When installing a new topology, we invalidate the cache entries that are no longer mapped to the local node. We also iterate over the entries in the cache stores and delete the ones that are no longer local, but this should only happen if the cache store is not shared. > We had similar issues in the past, but this seems to be related to the new cache store API introduced in 6.0. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2956) putIfAbsent on Hot Rod Java client doesn't reliably fulfil contract

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-2956?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-2956: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1004193|https://bugzilla.redhat.com/show_bug.cgi?id=1004193] from MODIFIED to ON_QA > putIfAbsent on Hot Rod Java client doesn't reliably fulfil contract > ------------------------------------------------------------------- > > Key: ISPN-2956 > URL: https://issues.jboss.org/browse/ISPN-2956 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Remote Protocols > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Labels: 63gablocker, hotrod-java-client, remote-clients > Fix For: 7.0.0.Beta1 > > > Hot Rod's putIfAbsent might have issues on some edge cases: > {quote}I want to know whether the putting entry already exists in the remote > cache cluster, or not. > I thought that RemoteCache.putIfAbsent() would be useful for that > purpose, i.e., > {code} > if (remoteCache.putIfAbsent(k,v) == null) { > // new entry. > } else { > // k already exists. > } > {code} > But no. > The putIfAbsent() for new entry may return non-null value, if one of the > server crushed while putting. > The behavior is like the following: > 1. Client do putIfAbsent(k,v). > 2. The server receives the request and sends replication requests to > other servers. If the server crushed before completing replication, some > servers own that (k,v), but others not. > 3. Client receives the error. The putIfAbsent() internally retries the > same request to the next server in the cluster server list. > 4. If the next server owns the (k,v), the putIfAbsent() returns the > replicated (k,v) at the step 2, without any error. > So, putIfAbsent() is not reliable for knowing whether the putting entry > is *exactly* new or not. > Does anyone have any idea/workaround for this purpose?{quote} > A workaround is to do this: > {quote}We got a simple solution, which can be applied to our customer's application. > If each value part of putting (k,v) is unique or contains unique value, > the client can do *double check* wether the entry is new. > {code} > val = System.nanoTime(); // or uuid is also useful. > if ((ret = cache.putIfAbsent(key, val)) == null > || ret.equals(val)) { > // new entry, if the return value is just the same. > } else { > // key already exists. > } > {code} > We are proposing this workaround which almost works fine.{quote} > However, this is a bit of a cludge. > Hot Rod should be improved with an operation that allows a version to be passed when entry is created, instead of relying on the client generating it. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4311) Security tests, Windows, access denied (java.security.SecurityPermission setPolicy)

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4311?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4311: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1100259|https://bugzilla.redhat.com/show_bug.cgi?id=1100259] from MODIFIED to ON_QA > Security tests, Windows, access denied (java.security.SecurityPermission setPolicy) > ----------------------------------------------------------------------------------- > > Key: ISPN-4311 > URL: https://issues.jboss.org/browse/ISPN-4311 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Security > Affects Versions: 7.0.0.Alpha4 > Reporter: Tomas Sykora > Assignee: Tristan Tarrant > Labels: 63gablocker, testsuite_stability > > A pile of Security tests has problems with denied access when running the test suite on Windows environment. > Stacktrace > java.security.AccessControlException: access denied (javax.security.auth.AuthPermission doAs) > at java.security.AccessControlContext.checkPermission(AccessControlContext.java:374) > at java.security.AccessController.checkPermission(AccessController.java:549) > at java.lang.SecurityManager.checkPermission(SecurityManager.java:532) > at javax.security.auth.Subject.doAs(Subject.java:326) > at org.infinispan.security.QueryAuthorizationTest.createCacheManager(QueryAuthorizationTest.java:44) > at org.infinispan.test.SingleCacheManagerTest.setup(SingleCacheManagerTest.java:31) > at org.infinispan.test.SingleCacheManagerTest.createBeforeClass(SingleCacheManagerTest.java:44) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80) > at org.testng.internal.Invoker.invokeConfigurationMethod(Invoker.java:564) > at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:213) > at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:138) > at org.testng.internal.TestMethodWorker.invokeBeforeClassMethods(TestMethodWorker.java:175) > at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:107) > at org.testng.TestRunner.privateRun(TestRunner.java:767) > at org.testng.TestRunner.run(TestRunner.java:617) > at org.testng.SuiteRunner.runTest(SuiteRunner.java:334) > at org.testng.SuiteRunner.access$000(SuiteRunner.java:37) > at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368) > at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) > at java.util.concurrent.FutureTask.run(FutureTask.java:138) > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) > at java.lang.Thread.run(Thread.java:662) > *Affected tests:* > org.infinispan.security.ExecutionAuthorizationTest.testExecMapReduce > org.infinispan.security.QueryAuthorizationTest.createBeforeClass > org.infinispan.security.ExecutionAuthorizationTest.testExecDistExec -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4265) Make it possible to deploy c3p0 in OSGi

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4265?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4265: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1112177|https://bugzilla.redhat.com/show_bug.cgi?id=1112177] from MODIFIED to ON_QA > Make it possible to deploy c3p0 in OSGi > --------------------------------------- > > Key: ISPN-4265 > URL: https://issues.jboss.org/browse/ISPN-4265 > Project: Infinispan > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Ion Savin > Assignee: Ion Savin > Fix For: 7.0.0.Alpha5 > > > * dynamic import "*" for driver loading (or look for a service-based approach) - check how drivers are loaded in OSGi usually > * use contextClassLoaderSource = library (instead of the default "caller" which maps to the TCCL > * check that c3p0.properties can be loaded properly or a) load through the file lookup or b) move to non-default package > * update version from 0.9.1.2 to latest (0.9.2.1 at the moment) if possible -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 11 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues June 2014