September 2014 - infinispan-issues

[JBoss JIRA] (ISPN-4772) APIDistTest random failures

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-4772?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-4772: ------------------------------- Fix Version/s: 7.0.0.CR1 > APIDistTest random failures > --------------------------- > > Key: ISPN-4772 > URL: https://issues.jboss.org/browse/ISPN-4772 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Core > Affects Versions: 7.0.0.Beta2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Blocker > Labels: testsuite_stability > Fix For: 7.0.0.CR1 > > > The lock acquisition timeout is too small, because the asynchronous TxCompletionNotificationCommand can easily be delayed by more than 100ms. > Failure in CI here: http://ci.infinispan.org/viewLog.html?buildId=12250&buildTypeId=bt8&tab=b... -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4772) APIDistTest random failures

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-4772?page=com.atlassian.jira.plugin.... ] Dan Berindei reassigned ISPN-4772: ---------------------------------- Assignee: Dan Berindei (was: Mircea Markus) > APIDistTest random failures > --------------------------- > > Key: ISPN-4772 > URL: https://issues.jboss.org/browse/ISPN-4772 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Core > Affects Versions: 7.0.0.Beta2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Blocker > Labels: testsuite_stability > Fix For: 7.0.0.CR1 > > > The lock acquisition timeout is too small, because the asynchronous TxCompletionNotificationCommand can easily be delayed by more than 100ms. > Failure in CI here: http://ci.infinispan.org/viewLog.html?buildId=12250&buildTypeId=bt8&tab=b... -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4772) APIDistTest random failures

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-4772?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-4772: ------------------------------- Component/s: Test Suite - Core > APIDistTest random failures > --------------------------- > > Key: ISPN-4772 > URL: https://issues.jboss.org/browse/ISPN-4772 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Core > Affects Versions: 7.0.0.Beta2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Blocker > Labels: testsuite_stability > > The lock acquisition timeout is too small, because the asynchronous TxCompletionNotificationCommand can easily be delayed by more than 100ms. > Failure in CI here: http://ci.infinispan.org/viewLog.html?buildId=12250&buildTypeId=bt8&tab=b... -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4782) Server should use FORK instead of a Mux block

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4782?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-4782: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/2914 > Server should use FORK instead of a Mux block > --------------------------------------------- > > Key: ISPN-4782 > URL: https://issues.jboss.org/browse/ISPN-4782 > Project: Infinispan > Issue Type: Enhancement > Components: Server > Affects Versions: 7.0.0.Beta2 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 7.0.0.CR1 > > > The server jgroups subsystem uses a MuxChannel to multiplex messages to different consumers on the same channel. > We should use the FORK protocol instead since it has many advantages (i.e. it is what WildFly uses, it doesn't "dirty" the channel). -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4782) Server should use FORK instead of a Mux block

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4782?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-4782: ---------------------------------- Status: Open (was: New) > Server should use FORK instead of a Mux block > --------------------------------------------- > > Key: ISPN-4782 > URL: https://issues.jboss.org/browse/ISPN-4782 > Project: Infinispan > Issue Type: Enhancement > Components: Server > Affects Versions: 7.0.0.Beta2 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 7.0.0.CR1 > > > The server jgroups subsystem uses a MuxChannel to multiplex messages to different consumers on the same channel. > We should use the FORK protocol instead since it has many advantages (i.e. it is what WildFly uses, it doesn't "dirty" the channel). -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4782) Server should use FORK instead of a Mux block

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4782?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-4782: ---------------------------------- Description: The server jgroups subsystem uses a MuxChannel to multiplex messages to different consumers on the same channel. We should use the FORK protocol instead since it has many advantages (i.e. it is what WildFly uses, it doesn't "dirty" the channel). was: The server jgroups subsystem uses a MuxChannel to multiplex messages to different consumers on the same channel. Ideally we should use F > Server should use FORK instead of a Mux block > --------------------------------------------- > > Key: ISPN-4782 > URL: https://issues.jboss.org/browse/ISPN-4782 > Project: Infinispan > Issue Type: Enhancement > Components: Server > Affects Versions: 7.0.0.Beta2 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 7.0.0.CR1 > > > The server jgroups subsystem uses a MuxChannel to multiplex messages to different consumers on the same channel. > We should use the FORK protocol instead since it has many advantages (i.e. it is what WildFly uses, it doesn't "dirty" the channel). -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4782) Server should not use MuxChannel

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4782?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-4782: ---------------------------------- Summary: Server should not use MuxChannel (was: Server should use FORK instead of a Mux block) > Server should not use MuxChannel > -------------------------------- > > Key: ISPN-4782 > URL: https://issues.jboss.org/browse/ISPN-4782 > Project: Infinispan > Issue Type: Enhancement > Components: Server > Affects Versions: 7.0.0.Beta2 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 7.0.0.CR1 > > > The server jgroups subsystem uses a MuxChannel to multiplex messages to different consumers on the same channel. > We should use the FORK protocol instead since it has many advantages (i.e. it is what WildFly uses, it doesn't "dirty" the channel). -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4782) Server should not use MuxChannel

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4782?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-4782: ---------------------------------- Description: The server jgroups subsystem uses a MuxChannel to multiplex messages to different consumers on the same channel. Ideally we should use F was: The server jgroups subsystem uses a MuxChannel to multiplex messages to different consumers on the same channel. We should use the FORK protocol instead since it has many advantages (i.e. it is what WildFly uses, it doesn't "dirty" the channel). > Server should not use MuxChannel > -------------------------------- > > Key: ISPN-4782 > URL: https://issues.jboss.org/browse/ISPN-4782 > Project: Infinispan > Issue Type: Enhancement > Components: Server > Affects Versions: 7.0.0.Beta2 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 7.0.0.CR1 > > > The server jgroups subsystem uses a MuxChannel to multiplex messages to different consumers on the same channel. > Ideally we should use F -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4782) Server should use FORK instead of a Mux block

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4782?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-4782: ---------------------------------- Summary: Server should use FORK instead of a Mux block (was: Server should not use MuxChannel) > Server should use FORK instead of a Mux block > --------------------------------------------- > > Key: ISPN-4782 > URL: https://issues.jboss.org/browse/ISPN-4782 > Project: Infinispan > Issue Type: Enhancement > Components: Server > Affects Versions: 7.0.0.Beta2 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 7.0.0.CR1 > > > The server jgroups subsystem uses a MuxChannel to multiplex messages to different consumers on the same channel. > Ideally we should use F -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3402) Add JDBC Cache Store config to RHQ plugin

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-3402?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-3402: ----------------------------------- Fix Version/s: 7.0.0.Final > Add JDBC Cache Store config to RHQ plugin > ----------------------------------------- > > Key: ISPN-3402 > URL: https://issues.jboss.org/browse/ISPN-3402 > Project: Infinispan > Issue Type: Enhancement > Components: Loaders and Stores, Server > Reporter: William Burns > Assignee: William Burns > Fix For: 7.0.0.CR1, 7.0.0.Final > > > ISPN-3350 was added to enhance some of the RHQ endpoints to allow for better runtime configuration support. However ISPN-3290 is also concurrently changing cache stores. Some changes for ISPN-3290 were mentioned to be possibly changing how the JDBC cache stores are configured and as such this has been excluded from ISPN-3350 to not implement it twice. > This is just to add in the support JDBC cache stores as they are missing. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 2 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues September 2014