July 2014 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-4548) Revamp AbstractInfinispanTest thread handling to use pooling

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-4548?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-4548: -------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/2728 > Revamp AbstractInfinispanTest thread handling to use pooling > ------------------------------------------------------------ > > Key: ISPN-4548 > URL: https://issues.jboss.org/browse/ISPN-4548 > Project: Infinispan > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Test Suite - Core > Affects Versions: 7.0.0.Alpha5 > Reporter: William Burns > Assignee: William Burns > > Our base AbstractInfinispanTest class forks a new thread every time fork is called. It would provide better performance and memory usage if instead we used a pool for threads spawned in this way in the same the test. > Also we have support for running tests concurrently which currently don't work properly due to the usage of CountDownLatch which isn't quite sufficient for what it was trying to achieve. The usage of a CyclicBarrier would be more appropriate. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4427) ClusterListenerReplTxTest failure

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-4427?page=com.atlassian.jira.plugin.... ] Work on ISPN-4427 stopped by William Burns. > ClusterListenerReplTxTest failure > --------------------------------- > > Key: ISPN-4427 > URL: https://issues.jboss.org/browse/ISPN-4427 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Test Suite - Core > Reporter: William Burns > Assignee: William Burns > > http://ci.infinispan.org/project.html?tab=testDetails&projectId=Infinispa... -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4548) Revamp AbstractInfinispanTest thread handling to use pooling

by William Burns (JIRA)

William Burns created ISPN-4548: ----------------------------------- Summary: Revamp AbstractInfinispanTest thread handling to use pooling Key: ISPN-4548 URL: https://issues.jboss.org/browse/ISPN-4548 Project: Infinispan Issue Type: Enhancement Security Level: Public (Everyone can see) Components: Test Suite - Core Affects Versions: 7.0.0.Alpha5 Reporter: William Burns Assignee: Dan Berindei Our base AbstractInfinispanTest class forks a new thread every time fork is called. It would provide better performance and memory usage if instead we used a pool for threads spawned in this way in the same the test. Also we have support for running tests concurrently which currently don't work properly due to the usage of CountDownLatch which isn't quite sufficient for what it was trying to achieve. The usage of a CyclicBarrier would be more appropriate. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4548) Revamp AbstractInfinispanTest thread handling to use pooling

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-4548?page=com.atlassian.jira.plugin.... ] William Burns reassigned ISPN-4548: ----------------------------------- Assignee: William Burns (was: Dan Berindei) > Revamp AbstractInfinispanTest thread handling to use pooling > ------------------------------------------------------------ > > Key: ISPN-4548 > URL: https://issues.jboss.org/browse/ISPN-4548 > Project: Infinispan > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Test Suite - Core > Affects Versions: 7.0.0.Alpha5 > Reporter: William Burns > Assignee: William Burns > > Our base AbstractInfinispanTest class forks a new thread every time fork is called. It would provide better performance and memory usage if instead we used a pool for threads spawned in this way in the same the test. > Also we have support for running tests concurrently which currently don't work properly due to the usage of CountDownLatch which isn't quite sufficient for what it was trying to achieve. The usage of a CyclicBarrier would be more appropriate. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4548) Revamp AbstractInfinispanTest thread handling to use pooling

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-4548?page=com.atlassian.jira.plugin.... ] Work on ISPN-4548 started by William Burns. > Revamp AbstractInfinispanTest thread handling to use pooling > ------------------------------------------------------------ > > Key: ISPN-4548 > URL: https://issues.jboss.org/browse/ISPN-4548 > Project: Infinispan > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Test Suite - Core > Affects Versions: 7.0.0.Alpha5 > Reporter: William Burns > Assignee: William Burns > > Our base AbstractInfinispanTest class forks a new thread every time fork is called. It would provide better performance and memory usage if instead we used a pool for threads spawned in this way in the same the test. > Also we have support for running tests concurrently which currently don't work properly due to the usage of CountDownLatch which isn't quite sufficient for what it was trying to achieve. The usage of a CyclicBarrier would be more appropriate. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4547) Replication queue should replicate the first command immediately

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-4547?page=com.atlassian.jira.plugin.... ] William Burns commented on ISPN-4547: ------------------------------------- Also this would allow for removal of both max elements and interval configuration values on the replication queue. All that would be needed is essentially to enable it. The only question is do we want a dedicated thread that will do the replication (similar to how interval is done) or if we just want to do all replication in the first thread that comes in (similar to how max elements is done). > Replication queue should replicate the first command immediately > ---------------------------------------------------------------- > > Key: ISPN-4547 > URL: https://issues.jboss.org/browse/ISPN-4547 > Project: Infinispan > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Core > Affects Versions: 7.0.0.Alpha5 > Reporter: Dan Berindei > Assignee: William Burns > Priority: Minor > Fix For: 7.0.0.Final > > > The replication queue only replicates commands when the replication queue is full or the replication thread wakes up periodically. > If a new command is added to an empty replication queue, the replication thread should wake up immediately and broadcast it, otherwise it will add a significant latency to the replication under light load. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4547) Replication queue should replicate the first command immediately

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-4547?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-4547: ------------------------------- Issue Type: Enhancement (was: Bug) > Replication queue should replicate the first command immediately > ---------------------------------------------------------------- > > Key: ISPN-4547 > URL: https://issues.jboss.org/browse/ISPN-4547 > Project: Infinispan > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Core > Affects Versions: 7.0.0.Alpha5 > Reporter: Dan Berindei > Assignee: William Burns > Priority: Minor > Fix For: 7.0.0.Final > > > The replication queue only replicates commands when the replication queue is full or the replication thread wakes up periodically. > If a new command is added to an empty replication queue, the replication thread should wake up immediately and broadcast it, otherwise it will add a significant latency to the replication under light load. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4547) Replication queue should replicate the first command immediately

by Dan Berindei (JIRA)

Dan Berindei created ISPN-4547: ---------------------------------- Summary: Replication queue should replicate the first command immediately Key: ISPN-4547 URL: https://issues.jboss.org/browse/ISPN-4547 Project: Infinispan Issue Type: Bug Security Level: Public (Everyone can see) Components: Core Affects Versions: 7.0.0.Alpha5 Reporter: Dan Berindei Assignee: William Burns Priority: Minor Fix For: 7.0.0.Final The replication queue only replicates commands when the replication queue is full or the replication thread wakes up periodically. If a new command is added to an empty replication queue, the replication thread should wake up immediately and broadcast it, otherwise it will add a significant latency to the replication under light load. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4546) Possible stale lock when the primary owner leaves during rebalance

by Dan Berindei (JIRA)

Dan Berindei created ISPN-4546: ---------------------------------- Summary: Possible stale lock when the primary owner leaves during rebalance Key: ISPN-4546 URL: https://issues.jboss.org/browse/ISPN-4546 Project: Infinispan Issue Type: Bug Security Level: Public (Everyone can see) Components: Core, State Transfer Affects Versions: 7.0.0.Alpha5 Reporter: Dan Berindei Assignee: Dan Berindei Fix For: 7.0.0.Beta1 Topology T: coordinator = A, owners(k) = [C, D], pending_owners(k) = null B sends prepareCommand(tx1, put(k, v)) to C, D D adds backup locks and replies C acquires lock, ready to send reply to B A starts installing topology T+1: owners(k) = [C, D], pending_owners(k) = [C, E] A, C and E install topology T+1, B and D do not E requests and receives tx data from C, including tx1 C leaves B sees a SuspectException, sends rollbackCommand(tx1) to C, D D removes tx1 C has left, but is ignored B reports to the user that the tx has been rolled back B and D install topology T+1 (optional) A starts installing topology T+2: owners(k) = [D], pending_owners(k) = [E] A, B, D, E all install topology T+2 E requests and receives state from D, but it does not remove tx1 A starts installing topology T+3: owners(k) = [E], pending_owners(k) = null E now has a stale backup lock on k It seems very hard to reproduce in production: C would have to leave soon enough so that B and D haven't received the T+1 topology yet, but late enough for it to send its transaction data to E. A possible solution would be to catch any SuspectException during prepare/commit/rollback (without ignoring leavers), wait for a new topology, and replicate the command again on the new owners. Obviously, this wouldn't work with asynchronous prepare/commit/rollback. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4516) Upgrade Spring integration to 4.0.6

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-4516?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-4516: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/2733 > Upgrade Spring integration to 4.0.6 > ----------------------------------- > > Key: ISPN-4516 > URL: https://issues.jboss.org/browse/ISPN-4516 > Project: Infinispan > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Spring Integration > Affects Versions: 7.0.0.Alpha4 > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Priority: Minor > -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 5 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues July 2014