October 2015 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-5878) Deprecate MurmurHash2 and remove MurmurHash2Compat

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-5878?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-5878: ------------------------------- Status: Open (was: New) > Deprecate MurmurHash2 and remove MurmurHash2Compat > -------------------------------------------------- > > Key: ISPN-5878 > URL: https://issues.jboss.org/browse/ISPN-5878 > Project: Infinispan > Issue Type: Task > Components: Core > Affects Versions: 8.0.1.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 8.1.0.Beta1, 8.1.0.Final > > > {{MurmurHash3}} was introduced in version 5.0, obsoleting {{MurmurHash2}}. > {{MurmurHash2Compat}} was only introduced to preserve compatibility with the pre-4.2.1 {{MurmurHash2}} implementation. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5465) Replace the Hash function with a segment mapper

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-5465?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-5465: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/3779 > Replace the Hash function with a segment mapper > ----------------------------------------------- > > Key: ISPN-5465 > URL: https://issues.jboss.org/browse/ISPN-5465 > Project: Infinispan > Issue Type: Feature Request > Components: Configuration, Core > Affects Versions: 7.2.1.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 8.1.0.Final > > > Currently, we allow the user to customize the mapping of keys to CH segments with a custom {{Hash}} function. But the Hash function doesn't give the user direct control over where a key is mapped, the ultimate location depends on the CH implementation. The CH implementation is also customizable, but it's much harder for the user to get right. > We should replace the Hash with something like this: > {code:java} > public interface SegmentMapper { > public int getSegment(Object key, int numSegments); > {code} > This should also be easier to implement than the {{Grouper}} interface we have now, when the user only needs co-location and doesn't need additional grouping features like {{cache.getGroup(name)}}. > I think this should also help internally, e.g. to replace the {{GroupingConsistentHash}} that needs to be re-created on every topology update with a constant {{SegmentMapper}} wrapper. It might also help to compute the segment of a key only once and save it in the context, instead of computing it every time we need to know the location of a key. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5882) XSite replication - take-offline.after-failures property is ignored

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5882?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-5882: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1274800 Bugzilla Update: Perform > XSite replication - take-offline.after-failures property is ignored > ------------------------------------------------------------------- > > Key: ISPN-5882 > URL: https://issues.jboss.org/browse/ISPN-5882 > Project: Infinispan > Issue Type: Bug > Components: Cross-Site Replication > Reporter: Matej Čimbora > Assignee: Pedro Ruivo > > Let's say I use the following backup settings and start the server in site LON: > <backup site="BRN" strategy="SYNC"> > <take-offline after-failures="5"/> > </backup> > The following code snipped should cause BRN site to go offline after 5 failures, however the site is still remains online and tries to back up the data to BRN. > RemoteCacheManager remoteCacheManager = new RemoteCacheManager(); > RemoteCache<Object, Object> cache = remoteCacheManager.getCache(); > for (int i = 0; i < 10; i++) { > cache.put(i, i); > } > Server-side error message example: > 16:05:19,121 ERROR [org.jgroups.protocols.relay.RELAY2] (HotRodServerWorker-5-2) localhost: no route to BRN: dropping message > 16:05:29,121 WARN [org.infinispan.xsite.BackupSenderImpl] (HotRodServerWorker-5-2) ISPN000202: Problems backing up data for cache default to site BRN: org.infinispan.util.concurrent.TimeoutException: Timed out after 10 seconds waiting for a response from BRN (sync, timeout=10000) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5882) XSite replication - take-offline.after-failures property is ignored

by Matej Čimbora (JIRA)

Matej Čimbora created ISPN-5882: ----------------------------------- Summary: XSite replication - take-offline.after-failures property is ignored Key: ISPN-5882 URL: https://issues.jboss.org/browse/ISPN-5882 Project: Infinispan Issue Type: Bug Components: Cross-Site Replication Reporter: Matej Čimbora Assignee: Pedro Ruivo Let's say I use the following backup settings and start the server in site LON: <backup site="BRN" strategy="SYNC"> <take-offline after-failures="5"/> </backup> The following code snipped should cause BRN site to go offline after 5 failures, however the site is still remains online and tries to back up the data to BRN. RemoteCacheManager remoteCacheManager = new RemoteCacheManager(); RemoteCache<Object, Object> cache = remoteCacheManager.getCache(); for (int i = 0; i < 10; i++) { cache.put(i, i); } Server-side error message example: 16:05:19,121 ERROR [org.jgroups.protocols.relay.RELAY2] (HotRodServerWorker-5-2) localhost: no route to BRN: dropping message 16:05:29,121 WARN [org.infinispan.xsite.BackupSenderImpl] (HotRodServerWorker-5-2) ISPN000202: Problems backing up data for cache default to site BRN: org.infinispan.util.concurrent.TimeoutException: Timed out after 10 seconds waiting for a response from BRN (sync, timeout=10000) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5682) The minimum aggregation function doesn't work with Strings

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5682?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-5682: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1274769 Bugzilla Update: Perform > The minimum aggregation function doesn't work with Strings > ---------------------------------------------------------- > > 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)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5876) Pre-commit cache invalidation creates stale cache vulnerability

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-5876?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-5876: ----------------------------------- Fix Version/s: 5.2.15.Final > Pre-commit cache invalidation creates stale cache vulnerability > --------------------------------------------------------------- > > Key: ISPN-5876 > URL: https://issues.jboss.org/browse/ISPN-5876 > Project: Infinispan > Issue Type: Bug > Components: Eviction > Affects Versions: 5.2.7.Final > Reporter: Stephen Fikes > Assignee: Galder Zamarreño > Fix For: 5.2.15.Final, 8.1.0.Beta1, 8.1.0.Final > > > In a cluster where Infinispan serves as the level 2 cache for Hibernate (configured for invalidation), because invalidation requests for modified entities are sent *before* database commit, it is possible for nodes receiving the invalidation request to perform eviction and then (due to "local" read requests) reload the evicted entities prior to the time the database commit takes place in the server where the entity was modified. > Consequently, other servers in the cluster may contain data that remains stale until a subsequent change in another server or until the entity times out from lack of use. > It isn't easy to write a testcase for this - it required manual intervention to reproduce - but can be seen with any entity class, cluster, etc. (at least using Oracle - results may vary with specific databases) so I've not attached a testcase. The issue can be seen/understood by code inspection (i.e. the timing of invalidation vs. database commit). That said, my test consisted of a two node cluster and I used Byteman rules to delay database commit of a change to an entity (with an optimistic version property) long enough in "server 1" for eviction to complete and a subsequent re-read (by a worker thread on behalf of an EJB) to take place in "server 2". Following the re-read in "server 2", I the database commit proceeds in "server 1" and "server 2" now has a stale copy of the entity in cache. > One option is pessimistic locking which will block any read attempt until the DB commit completes. It is not feasible, however, for many applications to use pessimistic locking for all reads as this can have a severe impact on concurrency - and is the reason for using optimistic version control. But due to the early timing of invalidation broadcast (*before* database commit, while the data is not yet stale), optimistic locking is insufficient to guard against "permanently" stale data. We did see that some databases default to blocking repeatable reads even outside of transactions and without explicit lock requests. Oracle does not provide such a mode. So, all reads must be implemented to use pessimistic locks (which must be enclosed in explicit transactions - (b)locking reads are disallowed when autocommit=true in Oracle) and this could require significant effort (re-writes) to use pessimistic reads throughout - in addition to the performance issues this can introduce. > If broadcast of an invalidation message always occurs *after* database commit, optimistic control attributes are sufficient to block attempts to write stale data and though a few failures may occur (as they would in a single server with multiple active threads), it can be known that the stale data will be removed in some finite period. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5876) Pre-commit cache invalidation creates stale cache vulnerability

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-5876?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-5876: ----------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/3778, https://github.com/infinispan/infinispan/pull/3777 > Pre-commit cache invalidation creates stale cache vulnerability > --------------------------------------------------------------- > > Key: ISPN-5876 > URL: https://issues.jboss.org/browse/ISPN-5876 > Project: Infinispan > Issue Type: Bug > Components: Eviction > Affects Versions: 5.2.7.Final > Reporter: Stephen Fikes > Assignee: Galder Zamarreño > Fix For: 5.2.15.Final, 8.1.0.Beta1, 8.1.0.Final > > > In a cluster where Infinispan serves as the level 2 cache for Hibernate (configured for invalidation), because invalidation requests for modified entities are sent *before* database commit, it is possible for nodes receiving the invalidation request to perform eviction and then (due to "local" read requests) reload the evicted entities prior to the time the database commit takes place in the server where the entity was modified. > Consequently, other servers in the cluster may contain data that remains stale until a subsequent change in another server or until the entity times out from lack of use. > It isn't easy to write a testcase for this - it required manual intervention to reproduce - but can be seen with any entity class, cluster, etc. (at least using Oracle - results may vary with specific databases) so I've not attached a testcase. The issue can be seen/understood by code inspection (i.e. the timing of invalidation vs. database commit). That said, my test consisted of a two node cluster and I used Byteman rules to delay database commit of a change to an entity (with an optimistic version property) long enough in "server 1" for eviction to complete and a subsequent re-read (by a worker thread on behalf of an EJB) to take place in "server 2". Following the re-read in "server 2", I the database commit proceeds in "server 1" and "server 2" now has a stale copy of the entity in cache. > One option is pessimistic locking which will block any read attempt until the DB commit completes. It is not feasible, however, for many applications to use pessimistic locking for all reads as this can have a severe impact on concurrency - and is the reason for using optimistic version control. But due to the early timing of invalidation broadcast (*before* database commit, while the data is not yet stale), optimistic locking is insufficient to guard against "permanently" stale data. We did see that some databases default to blocking repeatable reads even outside of transactions and without explicit lock requests. Oracle does not provide such a mode. So, all reads must be implemented to use pessimistic locks (which must be enclosed in explicit transactions - (b)locking reads are disallowed when autocommit=true in Oracle) and this could require significant effort (re-writes) to use pessimistic reads throughout - in addition to the performance issues this can introduce. > If broadcast of an invalidation message always occurs *after* database commit, optimistic control attributes are sufficient to block attempts to write stale data and though a few failures may occur (as they would in a single server with multiple active threads), it can be known that the stale data will be removed in some finite period. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5881) AbstractControlledLocalTopologyManager.setCacheRebalancingEnabled() loops infinitely

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5881?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5881: ------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/3776 > AbstractControlledLocalTopologyManager.setCacheRebalancingEnabled() loops infinitely > ------------------------------------------------------------------------------------ > > Key: ISPN-5881 > URL: https://issues.jboss.org/browse/ISPN-5881 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Core > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Priority: Minor > Fix For: 8.1.0.Beta1 > > > the method is recursively invoked and looping forever. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5881) AbstractControlledLocalTopologyManager.setCacheRebalancingEnabled() loops infinitely

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5881?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5881: ------------------------------ Status: Open (was: New) > AbstractControlledLocalTopologyManager.setCacheRebalancingEnabled() loops infinitely > ------------------------------------------------------------------------------------ > > Key: ISPN-5881 > URL: https://issues.jboss.org/browse/ISPN-5881 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Core > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Priority: Minor > Fix For: 8.1.0.Beta1 > > > the method is recursively invoked and looping forever. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5881) AbstractControlledLocalTopologyManager.setCacheRebalancingEnabled() loops infinitely

by Pedro Ruivo (JIRA)

Pedro Ruivo created ISPN-5881: --------------------------------- Summary: AbstractControlledLocalTopologyManager.setCacheRebalancingEnabled() loops infinitely Key: ISPN-5881 URL: https://issues.jboss.org/browse/ISPN-5881 Project: Infinispan Issue Type: Bug Components: Test Suite - Core Reporter: Pedro Ruivo Assignee: Pedro Ruivo Priority: Minor Fix For: 8.1.0.Beta1 the method is recursively invoked and looping forever. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 2 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues October 2015