March 2014 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-4108) Pessimistic tx for a union CH will not be forwarded to all owners.

by Erik Salter (JIRA)

Erik Salter created ISPN-4108: --------------------------------- Summary: Pessimistic tx for a union CH will not be forwarded to all owners. Key: ISPN-4108 URL: https://issues.jboss.org/browse/ISPN-4108 Project: Infinispan Issue Type: Bug Components: State Transfer Affects Versions: 5.2.7.Final Reporter: Erik Salter Assignee: Dan Berindei There is a case where transactions originating from a LockControlCommand will not be forwarded to the new owner during state transfer. If the transactions begin on the old primary owner after the tx list was sent to the new owner, the replicate the lock information to the joiner (because the originator is still the primary owner in the union CH that we use during state transfer). When state transfer ends and the joiner becomes the new primary owner, it will allow other txs to lock the same key. This leads to data loss/inconsistency We should change PessimisticLockingInterceptor to replicate the lock command to the other owners even if the originator is the primary owner, when there is a state transfer in progress. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

1
0
0 / 0

[JBoss JIRA] (ISPN-4107) Server state transfer timeout should be 4 minutes

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-4107?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-4107: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Server state transfer timeout should be 4 minutes > ------------------------------------------------- > > Key: ISPN-4107 > URL: https://issues.jboss.org/browse/ISPN-4107 > Project: Infinispan > Issue Type: Feature Request > Components: Configuration, Server > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 7.0.0.Final, 7.0.0.Alpha2 > > > Just like in library mode. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

1
0
0 / 0

[JBoss JIRA] (ISPN-4107) Server state transfer timeout should be 4 minutes

by Galder Zamarreño (JIRA)

Galder Zamarreño created ISPN-4107: -------------------------------------- Summary: Server state transfer timeout should be 4 minutes Key: ISPN-4107 URL: https://issues.jboss.org/browse/ISPN-4107 Project: Infinispan Issue Type: Feature Request Components: Configuration, Server Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 7.0.0.Final, 7.0.0.Alpha2 Just like in library mode. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

1
0
0 / 0

[JBoss JIRA] (ISPN-4107) Server state transfer timeout should be 4 minutes

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-4107?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-4107: ----------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/2321 > Server state transfer timeout should be 4 minutes > ------------------------------------------------- > > Key: ISPN-4107 > URL: https://issues.jboss.org/browse/ISPN-4107 > Project: Infinispan > Issue Type: Feature Request > Components: Configuration, Server > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 7.0.0.Final, 7.0.0.Alpha2 > > > Just like in library mode. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

1
0
0 / 0

[JBoss JIRA] (ISPN-4091) Transactions and data should prefer to be sourced from a primary owner

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-4091?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-4091: ------------------------------------ It turns out requesting the transactions from the primary owner only fixes part of the problem. For transactions that are started on the old primary owner after the tx list was sent to the joiner, we still don't replicate the lock information to the joiner (because the originator is still the primary owner in the union CH that we use during state transfer). When state transfer ends and the joiner becomes the new primary owner, it will allow other txs to lock the same key. We should change PessimisticLockingInterceptor to replicate the lock command to the other owners even if the originator is the primary owner, when there is a state transfer in progress. > Transactions and data should prefer to be sourced from a primary owner > ---------------------------------------------------------------------- > > Key: ISPN-4091 > URL: https://issues.jboss.org/browse/ISPN-4091 > Project: Infinispan > Issue Type: Bug > Components: State Transfer > Affects Versions: 5.2.7.Final > Reporter: Erik Salter > Assignee: Dan Berindei > > The current state transfer mechanism will ask the backup segments for transaction and state information. However, this breaks if there is a pessimistic transaction executing on the primary data owner, Consider the following use case: > A new owner joins and sources the ongoing transactions and data for key k from the backup. Meanwhile, a local transaction has started on the primary owner for k, but has not prepared on any remote nodes. So the new node does not know about the ongoing transaction. While that's going on, a new tx starts on the new owner. Since these are pessimistic, the new transaction will acquires the lock for the same key. > So we can have data inconsistency. > The state transfer mechanism should prefer to source the transaction and state information from the primary owner. This should cover all cases: if the originator is not the primary owner, then any (backup) locks must be replicated to all the owners, either directly during the tx or during a previous state transfer. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

1
0
0 / 0

[JBoss JIRA] (ISPN-4106) RHQ server plugin: remote store cache child creation fails

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4106?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-4106: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1076084 > RHQ server plugin: remote store cache child creation fails > ---------------------------------------------------------- > > Key: ISPN-4106 > URL: https://issues.jboss.org/browse/ISPN-4106 > Project: Infinispan > Issue Type: Bug > Components: JMX, reporting and management > Affects Versions: 6.0.1.Final, 7.0.0.Alpha1 > Reporter: Tomas Sykora > Assignee: Mircea Markus > > We are unable to configure remote cache store for a particular cache from RHQ GUI for a server. > It does not even put any configuration fragments into standalone.xml file. The only reasonable message I was able to extract was INFO from a RHQ server itself: > 09:45:16,719 INFO [org.rhq.enterprise.server.resource.ResourceFactoryServerServiceImpl] (http-/0.0.0.0:7080-6) Received create resource response: CreateResourceResponse[RequestId=10111, Status=Failure] > Unfortunately, TRACE logging says nothing there. > ISPN server and Agent logs does not contain any useful information either. > This issue needs to be investigated further and deeply. This is just the first heads up and for a proper tracing of this bug. > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

1
0
0 / 0

[JBoss JIRA] (ISPN-4106) RHQ server plugin: remote store cache child creation fails

by Tomas Sykora (JIRA)

Tomas Sykora created ISPN-4106: ---------------------------------- Summary: RHQ server plugin: remote store cache child creation fails Key: ISPN-4106 URL: https://issues.jboss.org/browse/ISPN-4106 Project: Infinispan Issue Type: Bug Components: JMX, reporting and management Affects Versions: 7.0.0.Alpha1, 6.0.1.Final Reporter: Tomas Sykora Assignee: Mircea Markus We are unable to configure remote cache store for a particular cache from RHQ GUI for a server. It does not even put any configuration fragments into standalone.xml file. The only reasonable message I was able to extract was INFO from a RHQ server itself: 09:45:16,719 INFO [org.rhq.enterprise.server.resource.ResourceFactoryServerServiceImpl] (http-/0.0.0.0:7080-6) Received create resource response: CreateResourceResponse[RequestId=10111, Status=Failure] Unfortunately, TRACE logging says nothing there. ISPN server and Agent logs does not contain any useful information either. This issue needs to be investigated further and deeply. This is just the first heads up and for a proper tracing of this bug. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

1
0
0 / 0

[JBoss JIRA] (ISPN-4105) Optimize Cluster Listener performance for Replicated Caches

by William Burns (JIRA)

William Burns created ISPN-4105: ----------------------------------- Summary: Optimize Cluster Listener performance for Replicated Caches Key: ISPN-4105 URL: https://issues.jboss.org/browse/ISPN-4105 Project: Infinispan Issue Type: Enhancement Components: Listeners Affects Versions: 7.0.0.Alpha1 Reporter: William Burns Assignee: William Burns Fix For: 7.0.0.Final Currently cluster listeners behave the same way for replicated caches as distributed caches. We should enhance this so the replicated cache only uses a local listener to improve write performance when they are installed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

1
0
0 / 0

[JBoss JIRA] (ISPN-2916) Atomic eviction/expiration support for grouped cache entries.

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/ISPN-2916?page=com.atlassian.jira.plugin.... ] Paul Ferraro commented on ISPN-2916: ------------------------------------ Is this something we can do for 7.0? > Atomic eviction/expiration support for grouped cache entries. > ------------------------------------------------------------- > > Key: ISPN-2916 > URL: https://issues.jboss.org/browse/ISPN-2916 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Affects Versions: 5.2.5.Final > Reporter: Paul Ferraro > Assignee: Mircea Markus > > While exploring the possibility of replacing single cache entries containing atomic maps with multiple cache entries using the grouping api, it occurred to me that to do this would require auto-eviction/expiration to be atomic for a group. Otherwise, we would run the risk of integrity constraint violations when cache entries are automatically expired or evicted. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

1
0
0 / 0

[JBoss JIRA] (ISPN-3900) Expose mechanism to retrieve the set of keys associated with a group

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/ISPN-3900?page=com.atlassian.jira.plugin.... ] Paul Ferraro commented on ISPN-3900: ------------------------------------ Is this something we can do for 7.0? > Expose mechanism to retrieve the set of keys associated with a group > -------------------------------------------------------------------- > > Key: ISPN-3900 > URL: https://issues.jboss.org/browse/ISPN-3900 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Affects Versions: 6.0.1.Final > Reporter: Paul Ferraro > Assignee: Mircea Markus > > The grouping API allows the association of set of keys to a group. It would be useful to be able to obtain the set of keys associated with a given group. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues March 2014