June 2014 - infinispan-issues - Jboss List Archives

[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=1104657, https://bugzilla.redhat.com/show_bug.cgi?id=1104658, 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) > 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-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 Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1104657 > 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-4343) Rest rolling upgrades, distributed -- new cluster can't load from old cluster properly

by Tomas Sykora (JIRA)

[ https://issues.jboss.org/browse/ISPN-4343?page=com.atlassian.jira.plugin.... ] Tomas Sykora updated ISPN-4343: ------------------------------- Attachment: ISPN-4343.txt ISPN-4343.zip Server output and attached packed test-suite containing new added test as a reproducer. > 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-4343) Rest rolling upgrades, distributed -- new cluster can't load from old cluster properly

by Tomas Sykora (JIRA)

Tomas Sykora created ISPN-4343: ---------------------------------- Summary: 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 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-3717) Add support for index-less queries using the EntryRetriever

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-3717?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-3717: -------------------------------- Component/s: Remote Querying > Add support for index-less queries using the EntryRetriever > ----------------------------------------------------------- > > Key: ISPN-3717 > URL: https://issues.jboss.org/browse/ISPN-3717 > Project: Infinispan > Issue Type: Feature Request > Components: Embedded Querying, Remote Querying > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Labels: 6.3remotequeries, 630, roadmap > Fix For: 7.0.0.Beta1, 7.0.0.Final > > > The current Lucene-based search implementation requires indexes for all fields that are referenced in queries. > Need to be able to query also for non-indexed fields. M/R is a potential implementation idea. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3910) HotRod authentication

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3910?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3910: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1096898|https://bugzilla.redhat.com/show_bug.cgi?id=1096898] from NEW to ON_QA > HotRod authentication > --------------------- > > Key: ISPN-3910 > URL: https://issues.jboss.org/browse/ISPN-3910 > Project: Infinispan > Issue Type: Sub-task > Components: Remote Protocols, Security > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Labels: 630, roadmap > Fix For: 7.0.0.Alpha4, 7.0.0.Final > > -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4299) Authentication configuration builder requires CallbackHandle also when subject it set

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4299?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4299: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1099055|https://bugzilla.redhat.com/show_bug.cgi?id=1099055] from NEW to MODIFIED > Authentication configuration builder requires CallbackHandle also when subject it set > ------------------------------------------------------------------------------------- > > Key: ISPN-4299 > URL: https://issues.jboss.org/browse/ISPN-4299 > Project: Infinispan > Issue Type: Bug > Components: Server > Reporter: Vojtech Juranek > Assignee: Tristan Tarrant > Priority: Minor > Fix For: 7.0.0.Alpha5 > > > Authentication configuration builder allows to setup direcly subject under which action are performed. In this case there's no need for any additional authentication. However authentication configuration builder requires {{CallbackHandler}} also in this case and without it it fails with > {noformat} > org.infinispan.commons.CacheConfigurationException: ISPN004030: Cannot enable authentication without specifying a Callback Handler > at org.infinispan.client.hotrod.configuration.AuthenticationConfigurationBuilder.validate(AuthenticationConfigurationBuilder.java:86) > at org.infinispan.client.hotrod.configuration.SecurityConfigurationBuilder.validate(SecurityConfigurationBuilder.java:43) > at org.infinispan.client.hotrod.configuration.ConfigurationBuilder.validate(ConfigurationBuilder.java:280) > at org.infinispan.client.hotrod.configuration.ConfigurationBuilder.build(ConfigurationBuilder.java:314) > at org.infinispan.client.hotrod.configuration.ConfigurationBuilder.build(ConfigurationBuilder.java:309) > at org.infinispan.server.test.client.hotrod.security.HotRodSaslAuthTestBase.getRemoteCacheManagerConfig(HotRodSaslAuthTestBase.java:104) > {noformat} -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4296) Restore predefined cache limitation for Hot Rod servers

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4296?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-4296: ---------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 7.0.0.Alpha5 Resolution: Done > Restore predefined cache limitation for Hot Rod servers > ------------------------------------------------------- > > Key: ISPN-4296 > URL: https://issues.jboss.org/browse/ISPN-4296 > Project: Infinispan > Issue Type: Enhancement > Components: Remote Protocols > Affects Versions: 7.0.0.Alpha3 > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 7.0.0.Alpha5, 7.0.0.Beta1 > > > Even after asymmetric cluster support was implemented, each node still does not know which other nodes contain which caches. The coordinator of the cluster knows, but no one else. This is because the aim has never really been to have different nodes containing different caches, but more about making sure that caches can be started lazily. With this in mind, the limitation in ISPN-833 will be reinstated. > Being able to work only with predefined caches also simplifies a solution for ISPN-3530 because we can safely assume that all servers contain the defined caches. Each cache might have a different consistent hash (see dev list discussion on why this can easily happen - http://lists.jboss.org/pipermail/infinispan-dev/2014-April/014870.html) but at least knowing that the nodes that have it is the same makes it easier to come up with a solution. > Finally, restoring the limitation avoids other can of worms such as the edge cases discovered by Jakub in ISPN-4212. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4342) Use correct surefire syntax for not running tests in parallel

by Tristan Tarrant (JIRA)

Tristan Tarrant created ISPN-4342: ------------------------------------- Summary: Use correct surefire syntax for not running tests in parallel Key: ISPN-4342 URL: https://issues.jboss.org/browse/ISPN-4342 Project: Infinispan Issue Type: Bug Components: Build process Affects Versions: 7.0.0.Alpha4 Reporter: Tristan Tarrant Assignee: Tristan Tarrant Fix For: 7.0.0.Alpha5 Some poms erroneously define <parallel>false</parallel> instead of <parallel>none</parallel> -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4341) Verify Query functionality in OSGi

by Martin Gencur (JIRA)

[ https://issues.jboss.org/browse/ISPN-4341?page=com.atlassian.jira.plugin.... ] Martin Gencur reassigned ISPN-4341: ----------------------------------- Assignee: Martin Gencur (was: Sanne Grinovero) > Verify Query functionality in OSGi > ---------------------------------- > > Key: ISPN-4341 > URL: https://issues.jboss.org/browse/ISPN-4341 > Project: Infinispan > Issue Type: Task > Components: Test Suite - Query > Reporter: Martin Gencur > Assignee: Martin Gencur > > The goal is to migrate tests for Query into Karaf and find out which tests are passing/failing, whether there are problems with class loading etc. This task should help assess the feasIbility of running queries in embedded mode in OSGi. -- 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