July 2014 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-4469) StateConsumerImpl segment change tracing is incorrect

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-4469?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-4469: -------------------------------- Status: Resolved (was: Pull Request Sent) Assignee: Dan Berindei (was: Mircea Markus) Fix Version/s: 7.0.0.Alpha5 Resolution: Done > StateConsumerImpl segment change tracing is incorrect > ----------------------------------------------------- > > Key: ISPN-4469 > URL: https://issues.jboss.org/browse/ISPN-4469 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 7.0.0.Alpha4 > Reporter: William Burns > Assignee: Dan Berindei > Fix For: 7.0.0.Alpha5 > > > StateConsumerImpl has some tracing to tell you what segments had changed. Unfortunately the arguments are in the wrong order and can cause some confusion. > {code} > if (trace) { > log.tracef("On cache %s we have: new segments: %s; old segments: %s; removed segments: %s; added segments: %s", > cacheName, removedSegments, newSegments, previousSegments, addedSegments); > } > {code} > It should be newSegments, previousSegments, removedSegments, addedSegments instead. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4479) Remote executor thread pool configuration is ignored

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-4479?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-4479: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Remote executor thread pool configuration is ignored > ---------------------------------------------------- > > Key: ISPN-4479 > URL: https://issues.jboss.org/browse/ISPN-4479 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Core > Affects Versions: 7.0.0.Alpha4 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 7.0.0.Alpha5 > > > Currently NamedExecutorsFactory uses the replication queue executor's configuration to build the remote executor's thread pool. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4154) Cancelled segment transfer causes future entry transfer to be ignored

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-4154?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-4154: -------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 7.0.0.Alpha5 Resolution: Done > Cancelled segment transfer causes future entry transfer to be ignored > --------------------------------------------------------------------- > > Key: ISPN-4154 > URL: https://issues.jboss.org/browse/ISPN-4154 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: State Transfer > Affects Versions: 7.0.0.Alpha1 > Reporter: Radim Vansa > Assignee: Dan Berindei > Priority: Critical > Fix For: 7.0.0.Alpha5 > > > Distributed transactional cache. > 1) Coordinator is gracefully leaving the cluster, sends a REBALANCE_START with topologyId 14, ST begins. > 2) Node receives chunk from segment X, writes entry K=V to the container. > 3) New coordinator jumps in with CH_UPDATE topology 16 > 4) Node receives CANCEL_STATE_TRANSFER and cancels transfer of segment X, invalidating K. In CommitManager, this operation is tracked and DiscardPolicy is set to DISCARD_STATE_TRANSFER for key K. > 5) New coordinator starts rebalance with topology 17 > 6) Node starts new ST for segment X > 7) Node receives the X: K=V, but in CommitManager it finds out that the policy is set to DISCARD_STATE_TRANSFER and ignores this update. > Result: entry value is lost on some node. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4491) Cluste rListener Event Batching

by William Burns (JIRA)

William Burns created ISPN-4491: ----------------------------------- Summary: Cluste rListener Event Batching Key: ISPN-4491 URL: https://issues.jboss.org/browse/ISPN-4491 Project: Infinispan Issue Type: Enhancement Security Level: Public (Everyone can see) Components: Listeners Reporter: William Burns Assignee: Dan Berindei Currently when a local listener which was installed for a cluster listener finds an event to send back to the parent it does this 1 message per listener. It might be more beneficial if we had batching so that it wouldn't send 1 message per. There are 2 cases I can think of which this would benefit. # When the underlying transport is UDP. In this case we can send just 1 message to all the nodes for the event instead of N Unicasts # When a node has more than 1 cluster listener installed we could send a single message to notifiy more than 1 listener. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4491) Cluste rListener Event Batching

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-4491?page=com.atlassian.jira.plugin.... ] William Burns reassigned ISPN-4491: ----------------------------------- Assignee: William Burns (was: Dan Berindei) > Cluste rListener Event Batching > ------------------------------- > > Key: ISPN-4491 > URL: https://issues.jboss.org/browse/ISPN-4491 > Project: Infinispan > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Listeners > Affects Versions: 7.0.0.Alpha4 > Reporter: William Burns > Assignee: William Burns > > Currently when a local listener which was installed for a cluster listener finds an event to send back to the parent it does this 1 message per listener. It might be more beneficial if we had batching so that it wouldn't send 1 message per. > There are 2 cases I can think of which this would benefit. > # When the underlying transport is UDP. In this case we can send just 1 message to all the nodes for the event instead of N Unicasts > # When a node has more than 1 cluster listener installed we could send a single message to notifiy more than 1 listener. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4491) Cluster Listener Event Batching

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-4491?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-4491: -------------------------------- Summary: Cluster Listener Event Batching (was: Cluste rListener Event Batching) > Cluster Listener Event Batching > ------------------------------- > > Key: ISPN-4491 > URL: https://issues.jboss.org/browse/ISPN-4491 > Project: Infinispan > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Listeners > Affects Versions: 7.0.0.Alpha4 > Reporter: William Burns > Assignee: William Burns > > Currently when a local listener which was installed for a cluster listener finds an event to send back to the parent it does this 1 message per listener. It might be more beneficial if we had batching so that it wouldn't send 1 message per. > There are 2 cases I can think of which this would benefit. > # When the underlying transport is UDP. In this case we can send just 1 message to all the nodes for the event instead of N Unicasts > # When a node has more than 1 cluster listener installed we could send a single message to notifiy more than 1 listener. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4491) Cluster Listener Event Batching

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-4491?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-4491: -------------------------------- Affects Version/s: 7.0.0.Alpha4 > Cluster Listener Event Batching > ------------------------------- > > Key: ISPN-4491 > URL: https://issues.jboss.org/browse/ISPN-4491 > Project: Infinispan > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Listeners > Affects Versions: 7.0.0.Alpha4 > Reporter: William Burns > Assignee: William Burns > > Currently when a local listener which was installed for a cluster listener finds an event to send back to the parent it does this 1 message per listener. It might be more beneficial if we had batching so that it wouldn't send 1 message per. > There are 2 cases I can think of which this would benefit. > # When the underlying transport is UDP. In this case we can send just 1 message to all the nodes for the event instead of N Unicasts > # When a node has more than 1 cluster listener installed we could send a single message to notifiy more than 1 listener. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4200) ExampleConfigsTest.testRestRollingUpgrades fails

by Tomas Sykora (JIRA)

[ https://issues.jboss.org/browse/ISPN-4200?page=com.atlassian.jira.plugin.... ] Tomas Sykora commented on ISPN-4200: ------------------------------------ This really might be affected by the fact, that (for this test) compatibility mode is enabled on both: new and old server. ^ I used CLI for my former investigation, but it looks like we ALSO have a bug in CLI codec encoder for REST. It looks like 2 different issues actually. "Pure" REST rolling upgrades (using REST Helper) are working fine, so compatibility or/and accessing cache not using REST Helper in this example config test has to affect behaviour. We need to look on it closely. > ExampleConfigsTest.testRestRollingUpgrades fails > ------------------------------------------------ > > Key: ISPN-4200 > URL: https://issues.jboss.org/browse/ISPN-4200 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Test Suite - Server > Reporter: Jakub Markos > Assignee: Mircea Markus > > Fails in the latest snapshot on line 240 with > {code} > Can't access etries stored in source node (target's RestCacheStore). expected:<value1> but was:<[B@19676adb> > {code} > you can run the test from /server/integration/testsuite with this command: > mvn clean test -Psuite.examples -Dtest=ExampleConfigsTest#testRestRollingUpgrades > The configs used are /server/integration/testsuite/target/server/node1/standalone/configuration/examples/{standalone-rest-rolling-upgrade.xml, standalone-compatibility-mode.xml} -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4490) Members can miss the rebalance cancellation on coordinator change

by Dan Berindei (JIRA)

Dan Berindei created ISPN-4490: ---------------------------------- Summary: Members can miss the rebalance cancellation on coordinator change Key: ISPN-4490 URL: https://issues.jboss.org/browse/ISPN-4490 Project: Infinispan Issue Type: Bug Security Level: Public (Everyone can see) Components: Core, State Transfer Affects Versions: 7.0.0.Alpha4 Reporter: Dan Berindei Assignee: Dan Berindei Fix For: 7.0.0.Alpha5 The new coordinator sends first a CH_UPDATE command to cancel the existing rebalance, and then a REBALANCE_START command to start a new rebalance. But the CH_UPDATE command is sent asynchronously, so it's possible for some members to receive it after the REBALANCE_START command. If that happens, that node will assume that it will receive the segments it requested for the previous rebalance. But with the ISPN-4484 fix, the provider node cancels the outbound transfer tasks when receiving a CH_UPDATE without a pendingCH, so the state requestor will never receive its segments. Even without the ISPN-4484 fix this is a problem, although less obvious. Between the provider node receiving the CH_UPDATE and the REBALANCE_START commands, it won't have the requestor in its write CH, so the requestor can miss transactions. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3717) Add support for index-less queries using the EntryRetriever

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3717?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3717: ----------------------------------------------- Vojtech Juranek <vjuranek(a)redhat.com> changed the Status of [bug 1104667|https://bugzilla.redhat.com/show_bug.cgi?id=1104667] from ON_QA to VERIFIED > 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 > Security Level: Public(Everyone can see) > Components: Embedded Querying, Remote Querying > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Labels: 6.3remotequeries, 630, roadmap > Fix For: 7.0.0.Alpha5, 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.6#6264)

11 years, 9 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues July 2014