[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:…
[View More]
{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)
[View Less]
9 years, 7 months
[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 …
[View More]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)
[View Less]
9 years, 7 months
[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.…
[View More]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)
[View Less]
9 years, 7 months
[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 …
[View More]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)
[View Less]
9 years, 7 months
[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
> …
[View More]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)
[View Less]
9 years, 7 months