June 2014 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-4236) RHQ JMX plugin causes Cache/CacheManager to report as not available

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4236?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4236: ----------------------------------------------- William Burns <wburns(a)redhat.com> changed the Status of [bug 1054165|https://bugzilla.redhat.com/show_bug.cgi?id=1054165] from ASSIGNED to POST > RHQ JMX plugin causes Cache/CacheManager to report as not available > ------------------------------------------------------------------- > > Key: ISPN-4236 > URL: https://issues.jboss.org/browse/ISPN-4236 > Project: Infinispan > Issue Type: Bug > Components: JMX, reporting and management > Affects Versions: 6.0.2.Final, 7.0.0.Alpha3 > Reporter: William Burns > Assignee: William Burns > Labels: 630betablocker > Fix For: 7.0.0.Alpha4, 7.0.0.Final > > > With the update to use newer RHQ, the CacheManager and Cache sometimes report as being down when using library JMX plugin. It looks like RHQ added some additional checks which just pushes the operation time over the default of 5 seconds. This is to clean up our code a bit to make the availability check for efficient. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4346) Refactoring of Clustered Queries and tests

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-4346?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-4346: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done Integrated. Thanks Sanne! > Refactoring of Clustered Queries and tests > ------------------------------------------ > > Key: ISPN-4346 > URL: https://issues.jboss.org/browse/ISPN-4346 > Project: Infinispan > Issue Type: Enhancement > Components: Embedded Querying > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Priority: Optional > Fix For: 7.0.0.Alpha5 > > > I'm backporting some cleanup in Clustered Queries to minimize the soon to follow changes needed for Lucene 4 -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4343) Rest rolling upgrades, distributed -- new cluster can't load from old cluster properly

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4343?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-4343: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1104659 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1104657, https://bugzilla.redhat.com/show_bug.cgi?id=1104658, https://bugzilla.redhat.com/show_bug.cgi?id=1104659) > Rest rolling upgrades, distributed -- new cluster can't load from old cluster properly > -------------------------------------------------------------------------------------- > > Key: ISPN-4343 > URL: https://issues.jboss.org/browse/ISPN-4343 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores, Server > Affects Versions: 7.0.0.Alpha4 > Reporter: Tomas Sykora > Assignee: Dan Berindei > Priority: Critical > Labels: rolling_upgrade > Attachments: ISPN-4343.txt, ISPN-4343.zip > > > A try to mimic the process of REST Rolling Upgrades for one old and new server in a clustered environment failed. > Scenario is quite simple, we start 2 old servers, store some data in, start 2 new servers and point clients to that new cluster. > When issuing a get on a new cluster (want to fetch old entry from old store), the operation fails with attached stack trace. > I also include current ISPN testsuite where is added testRestRollingUpgradesDiffVersionsDist test as a reproducer. > Respective changes are mirrored in my remote branch: https://github.com/tsykora/infinispan/tree/ISPN-4330 > You can run test like: > mvn clean verify -P suite.rolling.upgrades -Dzip.dist.old=/home/you/servers/previous-ispn-server-version.zip -Dtest=RestRollingUpgradesTest#testRestRollingUpgradesDiffVersionsDist -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3981) Enhance grouping API to support group manipulation methods

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3981?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-3981: ------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/2603 > Enhance grouping API to support group manipulation methods > ---------------------------------------------------------- > > Key: ISPN-3981 > URL: https://issues.jboss.org/browse/ISPN-3981 > Project: Infinispan > Issue Type: Feature Request > Reporter: Mircea Markus > Assignee: Pedro Ruivo > Fix For: 7.0.0.Alpha5 > > > The following methods: > - getGroup(goup): Map<K,V> > - removeGroup(groupId); -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3981) Enhance grouping API to support group manipulation methods

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3981?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-3981: ------------------------------ Fix Version/s: 7.0.0.Alpha5 > Enhance grouping API to support group manipulation methods > ---------------------------------------------------------- > > Key: ISPN-3981 > URL: https://issues.jboss.org/browse/ISPN-3981 > Project: Infinispan > Issue Type: Feature Request > Reporter: Mircea Markus > Assignee: Pedro Ruivo > Fix For: 7.0.0.Alpha5 > > > The following methods: > - getGroup(goup): Map<K,V> > - removeGroup(groupId); -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4343) Rest rolling upgrades, distributed -- new cluster can't load from old cluster properly

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4343?page=com.atlassian.jira.plugin.... ] Tristan Tarrant commented on ISPN-4343: --------------------------------------- Tomas, I see something very dangerous there: JGRP000010: packet from 10.200.136.193:45688 has different version (3.4.3) than ours (3.5.0); packet is discarded which means that both clusters are on the same multicast address. This MUST NOT be. > Rest rolling upgrades, distributed -- new cluster can't load from old cluster properly > -------------------------------------------------------------------------------------- > > Key: ISPN-4343 > URL: https://issues.jboss.org/browse/ISPN-4343 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores, Server > Affects Versions: 7.0.0.Alpha4 > Reporter: Tomas Sykora > Assignee: Dan Berindei > Priority: Critical > Labels: rolling_upgrade > Attachments: ISPN-4343.txt, ISPN-4343.zip > > > A try to mimic the process of REST Rolling Upgrades for one old and new server in a clustered environment failed. > Scenario is quite simple, we start 2 old servers, store some data in, start 2 new servers and point clients to that new cluster. > When issuing a get on a new cluster (want to fetch old entry from old store), the operation fails with attached stack trace. > I also include current ISPN testsuite where is added testRestRollingUpgradesDiffVersionsDist test as a reproducer. > Respective changes are mirrored in my remote branch: https://github.com/tsykora/infinispan/tree/ISPN-4330 > You can run test like: > mvn clean verify -P suite.rolling.upgrades -Dzip.dist.old=/home/you/servers/previous-ispn-server-version.zip -Dtest=RestRollingUpgradesTest#testRestRollingUpgradesDiffVersionsDist -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 4 months

1
0
0 / 0

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

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4108?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4108: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1102048|https://bugzilla.redhat.com/show_bug.cgi?id=1102048] from MODIFIED to ON_QA > 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 > Fix For: 7.0.0.Beta1 > > > 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 lock information may not be replicated 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 was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4346) Refactoring of Clustered Queries and tests

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-4346?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-4346: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/2600 > Refactoring of Clustered Queries and tests > ------------------------------------------ > > Key: ISPN-4346 > URL: https://issues.jboss.org/browse/ISPN-4346 > Project: Infinispan > Issue Type: Enhancement > Components: Embedded Querying > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Priority: Optional > Fix For: 7.0.0.Alpha5 > > > I'm backporting some cleanup in Clustered Queries to minimize the soon to follow changes needed for Lucene 4 -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 4 months

1
0
0 / 0

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

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4091?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4091: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1102048|https://bugzilla.redhat.com/show_bug.cgi?id=1102048] from MODIFIED to ON_QA > 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 > Fix For: 7.0.0.Beta1 > > > 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 was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4294) Upgrade hibernate-hql-parser/hibernate-hql-lucene to 1.0.0.CR1

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4294?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4294: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1099959|https://bugzilla.redhat.com/show_bug.cgi?id=1099959] from MODIFIED to ON_QA > Upgrade hibernate-hql-parser/hibernate-hql-lucene to 1.0.0.CR1 > -------------------------------------------------------------- > > Key: ISPN-4294 > URL: https://issues.jboss.org/browse/ISPN-4294 > Project: Infinispan > Issue Type: Component Upgrade > Affects Versions: 7.0.0.Alpha4 > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Labels: 630 > Fix For: 7.0.0.Beta1, 7.0.0.Final > > -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 4 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues June 2014