June 2015 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-3797) DataContainer should interact atomically with Persistence

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3797?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-3797: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1229105 > DataContainer should interact atomically with Persistence > --------------------------------------------------------- > > Key: ISPN-3797 > URL: https://issues.jboss.org/browse/ISPN-3797 > Project: Infinispan > Issue Type: Enhancement > Components: Eviction, Loaders and Stores > Affects Versions: 6.0.0.Final, 5.2.10.Final > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Fix For: 7.0.0.Alpha3, 7.0.0.Final, 5.2.11.Final > > > DataContainer should handle atomically all the interactions with the Persistence. This includes all the eviction/passivation. > Main points: > * In DataContainer load/store will avoid any lose of data during concurrent operations > * Take advantage of CHMv8 > * CacheLoader and Writer Interceptors are no longer needed. > Check the mailling list for more info. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5527) Java system properties no longer supported in leveldb expiration path

by Paul Richardson (JIRA)

Paul Richardson created ISPN-5527: ------------------------------------- Summary: Java system properties no longer supported in leveldb expiration path Key: ISPN-5527 URL: https://issues.jboss.org/browse/ISPN-5527 Project: Infinispan Issue Type: Bug Components: Configuration Affects Versions: 7.2.0.Final Reporter: Paul Richardson In 6.0, it was possible to create a leveldb cache configuration like: {code} <leveldbStore xmlns="urn:infinispan:config:store:leveldb:6.0" location="${user.home}/.komodo/db/data" expiredLocation="${user.home}/.komodo/db/expired" implementationType="JAVA"> </leveldbStore> {code} Both the location and expiredLocation paths could contain java system properties and these would be substituted when the configuration was parsed. In 7.2, the same configuration successfully substitutes the path attribute but NOT the expiration path attribute: {code} <leveldb-store xmlns="urn:infinispan:config:store:leveldb:7.2" path="${user.home}/.komodo/db/data"> <expiration path="${user.home}/.komodo/db/expired"/> <implementation type="JAVA"/> </leveldb-store> {code} Looking at the [LevelDBStoreConfigurationParser72|https://github.com/infinispan/infinispa...] class, the method parseLevelDBCacheStore() (line 55) has a call to: {code} String value = StringPropertyReplacer.replaceProperties(attributeValue); {code} while the parseLevelDBCacheStoreExpiry() method does not contain any call. Given the expiry attribute used to be part of the <leveldbStore>, it would seem the replace-properties support has not been carried over into the expiration tag handling. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5442) Integration tests for Lucene Directory need an H2 database available to multiple nodes

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-5442?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-5442: ------------------------------------ Status: Resolved (was: Pull Request Sent) Resolution: Done > Integration tests for Lucene Directory need an H2 database available to multiple nodes > -------------------------------------------------------------------------------------- > > Key: ISPN-5442 > URL: https://issues.jboss.org/browse/ISPN-5442 > Project: Infinispan > Issue Type: Task > Components: Test Suite - Query > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Fix For: 8.0.0.Alpha2 > > > The clustered Hibernate Search tests are meant to share state using a single (external) relational database. > The current integration tests use H2, but the tests have to be carefully written to consider the two nodes can not actually share state but only share the index. > I'll change this to use a shared H2 instance so that people writing new tests won't have to keep these hacks in mind. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5398) Run integration tests against WildFly 9.0.0.CR1

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-5398?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-5398: ------------------------------------ Status: Resolved (was: Pull Request Sent) Resolution: Done > Run integration tests against WildFly 9.0.0.CR1 > ----------------------------------------------- > > Key: ISPN-5398 > URL: https://issues.jboss.org/browse/ISPN-5398 > Project: Infinispan > Issue Type: Component Upgrade > Components: Test Suite - Core, Test Suite - Query > Affects Versions: 7.2.0.CR1 > Reporter: Tristan Tarrant > Assignee: Sanne Grinovero > Fix For: 8.0.0.Alpha2 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5339) Port improvements to Hibernate Search integration tests from the Hibernate Search codebase

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-5339?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-5339: ------------------------------------ Status: Resolved (was: Pull Request Sent) Resolution: Done > Port improvements to Hibernate Search integration tests from the Hibernate Search codebase > ------------------------------------------------------------------------------------------ > > Key: ISPN-5339 > URL: https://issues.jboss.org/browse/ISPN-5339 > Project: Infinispan > Issue Type: Task > Components: Test Suite - Query > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Fix For: 8.0.0.Alpha2 > > > As a follow up on ISPN-5255, unfortunately we found some needed fixes in the Hibernate Search integration tests with the Infinispan Directory in the Hibernate Search codebase, just while we were migrating it to Infinispan. > I've rejected the PR as the module is to be considered "frozen" in Hibernate Search, we should see if there is something of value to be applied to the migrated tests: > https://github.com/hibernate/hibernate-search/pull/797#issuecomment-87802467 -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5526) Replication: The DELTA_WRITE flag should force a remote get during state transfer

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5526?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-5526: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1228780 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1024920) > Replication: The DELTA_WRITE flag should force a remote get during state transfer > --------------------------------------------------------------------------------- > > Key: ISPN-5526 > URL: https://issues.jboss.org/browse/ISPN-5526 > Project: Infinispan > Issue Type: Bug > Affects Versions: 5.2.10.Final > Reporter: Dennis Reed > Assignee: Dan Berindei > Priority: Critical > > Same issue as ISPN-3184, but for repl caches in Infinispan 5.2.x. > (ISPN-3184 only fixed dist caches, since repl uses the same code in 5.3+). > AtomicHashMap and FineGrainedAtomicHashMap, as well as custom DeltaAware implementations, use PutKeyValueCommands with the DELTA_WRITE flag to execute incremental updates. These commands need the previous value of the entry in order to work. > If a node is joining and it receives a PutKeyValueCommand with the DELTA_WRITE flag before it has received the value of the affected key, it should do a remote get to retrieve the previous value and apply the change on top of that value, just like we do for conditional commands. Not doing so leads to data loss. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5526) Replication: The DELTA_WRITE flag should force a remote get during state transfer

by Dennis Reed (JIRA)

[ https://issues.jboss.org/browse/ISPN-5526?page=com.atlassian.jira.plugin.... ] Dennis Reed updated ISPN-5526: ------------------------------ Fix Version/s: (was: 7.0.0.Final) (was: 6.0.1.Final) Description: Same issue as ISPN-3184, but for repl caches in Infinispan 5.2.x. (ISPN-3184 only fixed dist caches, since repl uses the same code in 5.3+). AtomicHashMap and FineGrainedAtomicHashMap, as well as custom DeltaAware implementations, use PutKeyValueCommands with the DELTA_WRITE flag to execute incremental updates. These commands need the previous value of the entry in order to work. If a node is joining and it receives a PutKeyValueCommand with the DELTA_WRITE flag before it has received the value of the affected key, it should do a remote get to retrieve the previous value and apply the change on top of that value, just like we do for conditional commands. Not doing so leads to data loss. was: AtomicHashMap and FineGrainedAtomicHashMap, as well as custom DeltaAware implementations, use PutKeyValueCommands with the DELTA_WRITE flag to execute incremental updates. These commands need the previous value of the entry in order to work. If a node is joining and it receives a PutKeyValueCommand with the DELTA_WRITE flag before it has received the value of the affected key, it should do a remote get to retrieve the previous value and apply the change on top of that value, just like we do for conditional commands. Not doing so leads to data loss. Labels: (was: 620 630) Git Pull Request: (was: https://github.com/infinispan/infinispan/pull/2272) Affects Version/s: 5.2.10.Final (was: 5.3.0.Final) Does not affect 5.3+ with ISPN-3184. > Replication: The DELTA_WRITE flag should force a remote get during state transfer > --------------------------------------------------------------------------------- > > Key: ISPN-5526 > URL: https://issues.jboss.org/browse/ISPN-5526 > Project: Infinispan > Issue Type: Bug > Affects Versions: 5.2.10.Final > Reporter: Dennis Reed > Assignee: Dan Berindei > Priority: Critical > > Same issue as ISPN-3184, but for repl caches in Infinispan 5.2.x. > (ISPN-3184 only fixed dist caches, since repl uses the same code in 5.3+). > AtomicHashMap and FineGrainedAtomicHashMap, as well as custom DeltaAware implementations, use PutKeyValueCommands with the DELTA_WRITE flag to execute incremental updates. These commands need the previous value of the entry in order to work. > If a node is joining and it receives a PutKeyValueCommand with the DELTA_WRITE flag before it has received the value of the affected key, it should do a remote get to retrieve the previous value and apply the change on top of that value, just like we do for conditional commands. Not doing so leads to data loss. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5526) Replication: The DELTA_WRITE flag should force a remote get during state transfer

by Dennis Reed (JIRA)

Dennis Reed created ISPN-5526: --------------------------------- Summary: Replication: The DELTA_WRITE flag should force a remote get during state transfer Key: ISPN-5526 URL: https://issues.jboss.org/browse/ISPN-5526 Project: Infinispan Issue Type: Bug Affects Versions: 5.3.0.Final Reporter: Dennis Reed Assignee: Dan Berindei Priority: Critical Fix For: 6.0.1.Final, 7.0.0.Final AtomicHashMap and FineGrainedAtomicHashMap, as well as custom DeltaAware implementations, use PutKeyValueCommands with the DELTA_WRITE flag to execute incremental updates. These commands need the previous value of the entry in order to work. If a node is joining and it receives a PutKeyValueCommand with the DELTA_WRITE flag before it has received the value of the affected key, it should do a remote get to retrieve the previous value and apply the change on top of that value, just like we do for conditional commands. Not doing so leads to data loss. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5525) Server deadlock on stop

by Gustavo Fernandes (JIRA)

Gustavo Fernandes created ISPN-5525: --------------------------------------- Summary: Server deadlock on stop Key: ISPN-5525 URL: https://issues.jboss.org/browse/ISPN-5525 Project: Infinispan Issue Type: Bug Components: Server, Test Suite - Server Affects Versions: 8.0.0.Alpha1, 7.2.2.Final Reporter: Gustavo Fernandes Infinispan server is hanging intermittently during stop causing the build to timeout after 3h. This can be seen in the CI builds, for example: http://ci.infinispan.org/viewLog.html?buildId=27005&tab=buildResultsDiv&b... http://ci.infinispan.org/viewLog.html?buildId=26651&buildTypeId=Infinispa... In all case the deadlock is detected: {code} Found one Java-level deadlock: ============================= "undefined": waiting to lock monitor 0x00007fbaa806d448 (object 0x00000000e0a5a6f8, a org.jboss.as.threads.ScheduledThreadPoolService), which is held by "MSC service thread 1-2" "MSC service thread 1-2": waiting for ownable synchronizer 0x00000000e0a5a680, (a java.util.concurrent.locks.ReentrantLock$NonfairSync), which is held by "undefined" Java stack information for the threads listed above: =================================================== "undefined": at org.jboss.as.threads.ScheduledThreadPoolService$ExecutorImpl.terminated(ScheduledThreadPoolService.java:121) - waiting to lock <0x00000000e0a5a6f8> (a org.jboss.as.threads.ScheduledThreadPoolService) at java.util.concurrent.ThreadPoolExecutor.tryTerminate(ThreadPoolExecutor.java:706) at java.util.concurrent.ThreadPoolExecutor.processWorkerExit(ThreadPoolExecutor.java:1007) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1160) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) at org.jboss.threads.JBossThread.run(JBossThread.java:122) "MSC service thread 1-2": at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000000e0a5a680> (a java.util.concurrent.locks.ReentrantLock$NonfairSync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199) at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:209) at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285) at java.util.concurrent.ThreadPoolExecutor.interruptIdleWorkers(ThreadPoolExecutor.java:783) at java.util.concurrent.ThreadPoolExecutor.tryTerminate(ThreadPoolExecutor.java:697) at java.util.concurrent.ThreadPoolExecutor.shutdown(ThreadPoolExecutor.java:1394) at java.util.concurrent.ScheduledThreadPoolExecutor.shutdown(ScheduledThreadPoolExecutor.java:761) at org.jboss.as.threads.ManagedScheduledExecutorService.internalShutdown(ManagedScheduledExecutorService.java:53) at org.jboss.as.threads.ScheduledThreadPoolService.stop(ScheduledThreadPoolService.java:67) - locked <0x00000000e0a5a6f8> (a org.jboss.as.threads.ScheduledThreadPoolService) at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:2056) at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:2017) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) Found 1 deadlock. {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5524) Race condition in SemaphoreCompletionService.executeFront()

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-5524?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-5524: ------------------------------- Status: Open (was: New) > Race condition in SemaphoreCompletionService.executeFront() > ----------------------------------------------------------- > > Key: ISPN-5524 > URL: https://issues.jboss.org/browse/ISPN-5524 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.2.2.Final, 8.0.0.Alpha1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Blocker > Labels: testsuite_stability > Fix For: 8.0.0.Alpha2, 7.2.3.Final > > > If two threads call {{executeFront()}} at the same time, it's possible that none of them executes any task, although there are permits available, and one of the threads just added a task in the queue. This scenario causes random initial state transfer timeouts in the testsuite: > # T1: continueTaskInBackground(): queue = empty, permits = 0 > # T1: backgroundTaskFinished() > # T1: = semaphore.release(): queue = empty, permits = 1 > # T1: = executeFront() > # T1: == semaphore.acquire() -> true: queue = empty, permits = 0 > # T2: == queue.poll() -> null > # T2: submit(task) > # T2: = executeFront() > # T2: == semaphore.acquire() -> false > # T2: return without executing any task > # T1: return without executing any task > Failure example: http://ci.infinispan.org/viewLog.html?buildId=27153&tab=buildResultsDiv&b... -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 12 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues June 2015