July 2015 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-5619) Deprecate EntryRetriever with distributed streams

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-5619?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-5619: ------------------------------------ Status: Resolved (was: Pull Request Sent) Resolution: Done > Deprecate EntryRetriever with distributed streams > ------------------------------------------------- > > Key: ISPN-5619 > URL: https://issues.jboss.org/browse/ISPN-5619 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 8.0.0.Beta1 > Reporter: William Burns > Assignee: William Burns > Fix For: 8.0.0.CR1, 8.0.0.Final > > > Distributed streams were added for ISPN-5293. However segment completion listeners are not yet added and thus EntryRetriever is still required for that case. This is to add support for listener completion so we can remove EntryRetriever references. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5625) Distributed stream iterator should try to stay local if possible

by William Burns (JIRA)

William Burns created ISPN-5625: ----------------------------------- Summary: Distributed stream iterator should try to stay local if possible Key: ISPN-5625 URL: https://issues.jboss.org/browse/ISPN-5625 Project: Infinispan Issue Type: Enhancement Components: Core Reporter: William Burns Assignee: William Burns Distributed streams currently go to the node that owns a segment as a primary. We should in some cases (iterator) stay local if this node owns all of the segments as a backup as well. This can be a big win for cases when numOwners >= numNodes or if a user specifies a subset of segments. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5624) Local segment listener support for distribtued streams

by William Burns (JIRA)

William Burns created ISPN-5624: ----------------------------------- Summary: Local segment listener support for distribtued streams Key: ISPN-5624 URL: https://issues.jboss.org/browse/ISPN-5624 Project: Infinispan Issue Type: Enhancement Components: Core Reporter: William Burns Assignee: William Burns Distributed streams can be forced to be local with Flag.CACHE_MODE_LOCAL. When this occurs we should still track segments, but basically only complete segments that were fully iterated upon. The other segments could then be suspected implicitly since they were never completed but the iterator did. This can be helpful for implementations that don't ever want to have the stream contact a remote node for data, since it could do the redirection itself (ie. remote iterator). -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5606) Integrate management console into server distribution

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-5606?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-5606: ------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Integrate management console into server distribution > ----------------------------------------------------- > > Key: ISPN-5606 > URL: https://issues.jboss.org/browse/ISPN-5606 > Project: Infinispan > Issue Type: Task > Components: JMX, reporting and management, Server > Affects Versions: 8.0.0.Beta1 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 8.0.0.Beta2 > > > Add a dependency to the management console jar. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5538) Implement test for properties-based CallbackHandler for the SASL protocol

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-5538?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-5538: ------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 8.0.0.Beta2 Resolution: Done > Implement test for properties-based CallbackHandler for the SASL protocol > ------------------------------------------------------------------------- > > Key: ISPN-5538 > URL: https://issues.jboss.org/browse/ISPN-5538 > Project: Infinispan > Issue Type: Task > Components: Test Suite - Core > Reporter: Vojtech Juranek > Assignee: Vojtech Juranek > Fix For: 8.0.0.Beta2 > > > Implement test for properties-based CallbackHandler for the SASL protocol. This handler was implemented in JGRP-1929. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5611) Make the remote iterator to respect the RequestBalancingStrategy in the Hot Rod client

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5611?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5611: ------------------------------ Status: Resolved (was: Pull Request Sent) Resolution: Done > Make the remote iterator to respect the RequestBalancingStrategy in the Hot Rod client > -------------------------------------------------------------------------------------- > > Key: ISPN-5611 > URL: https://issues.jboss.org/browse/ISPN-5611 > Project: Infinispan > Issue Type: Enhancement > Components: Remote Protocols > Affects Versions: 8.0.0.Beta1 > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Fix For: 8.0.0.Beta2 > > > Currently the initial server that will hold the iteration state is automatically chosen based on segment ownership. If data location is known beforehand, it's more efficient to hint the iteration to start on a certain node. > The {{FailoverRequestBalancingStrategy}} is a mechanism in place to do that. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5611) Make the remote iterator to respect the RequestBalancingStrategy in the Hot Rod client

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5611?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5611: ------------------------------ Status: Open (was: New) > Make the remote iterator to respect the RequestBalancingStrategy in the Hot Rod client > -------------------------------------------------------------------------------------- > > Key: ISPN-5611 > URL: https://issues.jboss.org/browse/ISPN-5611 > Project: Infinispan > Issue Type: Enhancement > Components: Remote Protocols > Affects Versions: 8.0.0.Beta1 > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Fix For: 8.0.0.Beta2 > > > Currently the initial server that will hold the iteration state is automatically chosen based on segment ownership. If data location is known beforehand, it's more efficient to hint the iteration to start on a certain node. > The {{FailoverRequestBalancingStrategy}} is a mechanism in place to do that. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5611) Make the remote iterator to respect the RequestBalancingStrategy in the Hot Rod client

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5611?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5611: ------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/3592 > Make the remote iterator to respect the RequestBalancingStrategy in the Hot Rod client > -------------------------------------------------------------------------------------- > > Key: ISPN-5611 > URL: https://issues.jboss.org/browse/ISPN-5611 > Project: Infinispan > Issue Type: Enhancement > Components: Remote Protocols > Affects Versions: 8.0.0.Beta1 > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Fix For: 8.0.0.Beta2 > > > Currently the initial server that will hold the iteration state is automatically chosen based on segment ownership. If data location is known beforehand, it's more efficient to hint the iteration to start on a certain node. > The {{FailoverRequestBalancingStrategy}} is a mechanism in place to do that. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5623) Retried prepare commands do not wait for backup locks

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-5623?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-5623: ------------------------------------ We should probably waiting for backup/pending locks based on the current topology id, not the transaction's topology id. It might be necessary to clean the list of backup locks, in order to avoid 2 txs both acquiring only backup locks and waiting for each other on retry. > Retried prepare commands do not wait for backup locks > ----------------------------------------------------- > > Key: ISPN-5623 > URL: https://issues.jboss.org/browse/ISPN-5623 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.2.3.Final, 8.0.0.Beta1 > Reporter: Dan Berindei > Fix For: 8.0.0.Beta2 > > Attachments: OptimisticPrimaryOwnerCrashDuringPrepareTest.java > > > When the primary owner crashes during prepare, the prepare command is retried on the new primary owner. But because the transaction topology id stays the same, the new primary owner does not check for backup locks owned by other transactions from the previous topology. > That makes it possible for the retried prepare command to lock a key that was already locked by another transaction on the primary owner. > This wasn't a problem before the ISPN-4546 fix, because a primary owner crash would have forced the transaction to roll back. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5623) Retried prepare commands do not wait for backup locks

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-5623?page=com.atlassian.jira.plugin.... ] Dan Berindei reassigned ISPN-5623: ---------------------------------- Assignee: Pedro Ruivo > Retried prepare commands do not wait for backup locks > ----------------------------------------------------- > > Key: ISPN-5623 > URL: https://issues.jboss.org/browse/ISPN-5623 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.2.3.Final, 8.0.0.Beta1 > Reporter: Dan Berindei > Assignee: Pedro Ruivo > Fix For: 8.0.0.Beta2 > > Attachments: OptimisticPrimaryOwnerCrashDuringPrepareTest.java > > > When the primary owner crashes during prepare, the prepare command is retried on the new primary owner. But because the transaction topology id stays the same, the new primary owner does not check for backup locks owned by other transactions from the previous topology. > That makes it possible for the retried prepare command to lock a key that was already locked by another transaction on the primary owner. > This wasn't a problem before the ISPN-4546 fix, because a primary owner crash would have forced the transaction to roll back. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 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 2015