December 2015 - infinispan-issues

[JBoss JIRA] (ISPN-6017) Deprecate ReplicationQueue

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/ISPN-6017?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated ISPN-6017: --------------------------------- Status: Open (was: New) > Deprecate ReplicationQueue > -------------------------- > > Key: ISPN-6017 > URL: https://issues.jboss.org/browse/ISPN-6017 > Project: Infinispan > Issue Type: Task > Components: Core > Reporter: Radoslav Husar > Assignee: Radoslav Husar > > Per infinispan-dev list: > Pedro: > Can we remove the ReplicationQueue? First, it does not have any benefit > (JGroups already bundles the message and the Network can do it too) and > second, it is not more efficient (when the message is delivered, we > process the commands sequentially. So, if the first command blocks, the > other commands are not processed until it finished). Third, it is > complex if you have commands with multiple delivers orders (no order, > FIFO, total) > Dan: > +1, the replication queue has the same purpose as the bundler in > JGroups. And while the JGroups bundler has multiple options that keep > evolving, our replication queue still has the same algorithm it had in > 4.0. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6017) Deprecate ReplicationQueue

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/ISPN-6017?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated ISPN-6017: --------------------------------- Summary: Deprecate ReplicationQueue (was: Deprecate replication-queue) > Deprecate ReplicationQueue > -------------------------- > > Key: ISPN-6017 > URL: https://issues.jboss.org/browse/ISPN-6017 > Project: Infinispan > Issue Type: Task > Components: Core > Reporter: Radoslav Husar > Assignee: Radoslav Husar > > Per infinispan-dev list: > Pedro: > Can we remove the ReplicationQueue? First, it does not have any benefit > (JGroups already bundles the message and the Network can do it too) and > second, it is not more efficient (when the message is delivered, we > process the commands sequentially. So, if the first command blocks, the > other commands are not processed until it finished). Third, it is > complex if you have commands with multiple delivers orders (no order, > FIFO, total) > Dan: > +1, the replication queue has the same purpose as the bundler in > JGroups. And while the JGroups bundler has multiple options that keep > evolving, our replication queue still has the same algorithm it had in > 4.0. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6017) Deprecate replication-queue

by Radoslav Husar (JIRA)

Radoslav Husar created ISPN-6017: ------------------------------------ Summary: Deprecate replication-queue Key: ISPN-6017 URL: https://issues.jboss.org/browse/ISPN-6017 Project: Infinispan Issue Type: Task Components: Core Reporter: Radoslav Husar Assignee: Radoslav Husar Per infinispan-dev list: Pedro: Can we remove the ReplicationQueue? First, it does not have any benefit (JGroups already bundles the message and the Network can do it too) and second, it is not more efficient (when the message is delivered, we process the commands sequentially. So, if the first command blocks, the other commands are not processed until it finished). Third, it is complex if you have commands with multiple delivers orders (no order, FIFO, total) Dan: +1, the replication queue has the same purpose as the bundler in JGroups. And while the JGroups bundler has multiple options that keep evolving, our replication queue still has the same algorithm it had in 4.0. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 11 months

1
0
0 / 0

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

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5623?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5623: ----------------------------------------------- Vaclav Dedik <vdedik(a)redhat.com> changed the Status of [bug 1245500|https://bugzilla.redhat.com/show_bug.cgi?id=1245500] from POST to MODIFIED > 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.1.0.Final > > 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.4.11#64026)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3985) In BCHM traverse internal segments for parallel map/reduce execution

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3985?page=com.atlassian.jira.plugin.... ] William Burns resolved ISPN-3985. --------------------------------- Resolution: Out of Date This is already handled internally when we moved to BCHMv8 > In BCHM traverse internal segments for parallel map/reduce execution > -------------------------------------------------------------------- > > Key: ISPN-3985 > URL: https://issues.jboss.org/browse/ISPN-3985 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 7.0.0.Final > Reporter: Vladimir Blagojevic > Fix For: 8.2.0.Alpha1 > > > Currently when BoundedConcurrentHashMap is used in DataContainer we split input keys and traverse key/value pairs in parallel using executor. That is all good, however, we should optimize this solution as each segment in BCHM is a separate map we can iterate over each segment in a separate thread rather than blindly splitting input keys. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3684) Improve L1 consitency with backup owners

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3684?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-3684: -------------------------------- Fix Version/s: (was: 8.2.0.Alpha1) > Improve L1 consitency with backup owners > ---------------------------------------- > > Key: ISPN-3684 > URL: https://issues.jboss.org/browse/ISPN-3684 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 6.0.0.CR1 > Reporter: William Burns > Assignee: William Burns > > ISPN-3648 fixed an issue that can occur when a backup owner replies with an outdated value. > More details on the original issue can be found at ISPN-3426. > This JIRA is to improve this fix to be something more desirable. > There are a few ways that this could be done. > # Change it so that remote gets only go to the primary owner, which guarantees consistency with that owner (this still has issues with fail over when that primary owner goes down). Also may have performance issues since we don't have backup owners to respond faster. > # Change it so that values are only added to L1 if the value was retrieved from the primary owner. (note there is still some stuff to think about for fail over here) > # Multicast the invalidation message from the primary owner after updating the value. This is the simplest approach (no requestors map required), but may also have some performance concerns. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6008) Query DSL groupBy and orderBy should only accept single-valued properties

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-6008?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-6008: ----------------------------------------------- Adrian Nistor <anistor(a)redhat.com> changed the Status of [bug 1274769|https://bugzilla.redhat.com/show_bug.cgi?id=1274769] from ASSIGNED to POST > Query DSL groupBy and orderBy should only accept single-valued properties > ------------------------------------------------------------------------- > > Key: ISPN-6008 > URL: https://issues.jboss.org/browse/ISPN-6008 > Project: Infinispan > Issue Type: Bug > Components: Embedded Querying, Remote Querying > Affects Versions: 8.1.0.CR1, 8.0.2.Final > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 8.1.0.Final, 8.0.3.Final > > > {code} > QueryFactory qf = getQueryFactory(); > Query q = qf.from(User.class) > .select(Expression.min("name")) > .groupBy("addresses.street") > .build(); > q.list(); > {code} > Should throw an exception during query parsing because property "addresses.street" is not single-valued. > Similar behaviour should be expected for orderBy. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5682) Aggregating fields of embedded entities doesn't work

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5682?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5682: ----------------------------------------------- Adrian Nistor <anistor(a)redhat.com> changed the Status of [bug 1274769|https://bugzilla.redhat.com/show_bug.cgi?id=1274769] from ASSIGNED to POST > Aggregating fields of embedded entities doesn't work > ---------------------------------------------------- > > Key: ISPN-5682 > URL: https://issues.jboss.org/browse/ISPN-5682 > Project: Infinispan > Issue Type: Bug > Components: Embedded Querying > Affects Versions: 8.0.0.Beta3 > Reporter: Jakub Markos > Assignee: Adrian Nistor > Fix For: 8.1.0.Final > > > This query > {code} > public void testGroupBy7() { > QueryFactory qf = getQueryFactory(); > Query q = qf.from(getModelFactory().getUserImplClass()) > .select(Expression.min("addresses.street")) > .having("name").eq("Spider").toBuilder() > .build(); > List<Object[]> list = q.list(); > assertEquals(list.get(0)[0], "Bond Street"); > } > {code} > returns in the context of QueryDslConditionsTest test class (https://github.com/infinispan/infinispan/blob/7634c0996cb3a174d2a379f2096...) the street "Old Street", while "Bond Street" is expected. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6008) Query DSL groupBy and orderBy should only accept single-valued properties

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-6008?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-6008: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1274769 Bugzilla Update: Perform > Query DSL groupBy and orderBy should only accept single-valued properties > ------------------------------------------------------------------------- > > Key: ISPN-6008 > URL: https://issues.jboss.org/browse/ISPN-6008 > Project: Infinispan > Issue Type: Bug > Components: Embedded Querying, Remote Querying > Affects Versions: 8.1.0.CR1, 8.0.2.Final > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 8.1.0.Final, 8.0.3.Final > > > {code} > QueryFactory qf = getQueryFactory(); > Query q = qf.from(User.class) > .select(Expression.min("name")) > .groupBy("addresses.street") > .build(); > q.list(); > {code} > Should throw an exception during query parsing because property "addresses.street" is not single-valued. > Similar behaviour should be expected for orderBy. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPRK-17) Update to Infinispan 8.1.0.Final

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPRK-17?page=com.atlassian.jira.plugin.s... ] Gustavo Fernandes updated ISPRK-17: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Update to Infinispan 8.1.0.Final > -------------------------------- > > Key: ISPRK-17 > URL: https://issues.jboss.org/browse/ISPRK-17 > Project: Infinispan Spark > Issue Type: Component Upgrade > Affects Versions: 0.1 > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Fix For: 0.2 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 11 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues December 2015