March 2016 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-6381) Add more tests for js-client

by Anna Manukyan (JIRA)

[ https://issues.jboss.org/browse/ISPN-6381?page=com.atlassian.jira.plugin.... ] Anna Manukyan updated ISPN-6381: -------------------------------- Status: Open (was: New) > Add more tests for js-client > ---------------------------- > > Key: ISPN-6381 > URL: https://issues.jboss.org/browse/ISPN-6381 > Project: Infinispan > Issue Type: Task > Reporter: Anna Manukyan > Assignee: Anna Manukyan > > Add more tests for js-client. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (ISPN-6381) Add more tests for js-client

by Anna Manukyan (JIRA)

[ https://issues.jboss.org/browse/ISPN-6381?page=com.atlassian.jira.plugin.... ] Work on ISPN-6381 started by Anna Manukyan. ------------------------------------------- > Add more tests for js-client > ---------------------------- > > Key: ISPN-6381 > URL: https://issues.jboss.org/browse/ISPN-6381 > Project: Infinispan > Issue Type: Task > Reporter: Anna Manukyan > Assignee: Anna Manukyan > > Add more tests for js-client. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (ISPN-6371) Limit unboxing of Integer values in Distributed Streams

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-6371?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-6371: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done Integrated. Thanks [~william.burns]! > Limit unboxing of Integer values in Distributed Streams > ------------------------------------------------------- > > Key: ISPN-6371 > URL: https://issues.jboss.org/browse/ISPN-6371 > Project: Infinispan > Issue Type: Enhancement > Affects Versions: 8.2.0.Final > Reporter: William Burns > Assignee: William Burns > Fix For: 9.0.0.Alpha1 > > > Currently when a distributed stream filters entries it has to check the segment. Unfortunately each check of the segment requires unboxing an Integer value. If we instead unbox all of the Integers into something like a BitSet we won't incur this cost per entry and instead it will be limited by how many segments we have. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (ISPN-6380) Fix the code coverage tool to work with install command

by Anna Manukyan (JIRA)

[ https://issues.jboss.org/browse/ISPN-6380?page=com.atlassian.jira.plugin.... ] Anna Manukyan updated ISPN-6380: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/4130 > Fix the code coverage tool to work with install command > ------------------------------------------------------- > > Key: ISPN-6380 > URL: https://issues.jboss.org/browse/ISPN-6380 > Project: Infinispan > Issue Type: Task > Components: Build process > Reporter: Anna Manukyan > Assignee: Anna Manukyan > > Fix the coverage and jacocoReport profiles to generate readable jacoco coverage report. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (ISPN-6380) Fix the code coverage tool to work with install command

by Anna Manukyan (JIRA)

[ https://issues.jboss.org/browse/ISPN-6380?page=com.atlassian.jira.plugin.... ] Anna Manukyan updated ISPN-6380: -------------------------------- Status: Open (was: New) > Fix the code coverage tool to work with install command > ------------------------------------------------------- > > Key: ISPN-6380 > URL: https://issues.jboss.org/browse/ISPN-6380 > Project: Infinispan > Issue Type: Task > Components: Build process > Reporter: Anna Manukyan > Assignee: Anna Manukyan > > Fix the coverage and jacocoReport profiles to generate readable jacoco coverage report. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (ISPN-6380) Fix the code coverage tool to work with install command

by Anna Manukyan (JIRA)

Anna Manukyan created ISPN-6380: ----------------------------------- Summary: Fix the code coverage tool to work with install command Key: ISPN-6380 URL: https://issues.jboss.org/browse/ISPN-6380 Project: Infinispan Issue Type: Task Components: Build process Reporter: Anna Manukyan Assignee: Anna Manukyan Fix the coverage and jacocoReport profiles to generate readable jacoco coverage report. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

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

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5876?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5876: ----------------------------------------------- Martin Simka <msimka(a)redhat.com> changed the Status of [bug 1273147|https://bugzilla.redhat.com/show_bug.cgi?id=1273147] from ON_QA to VERIFIED > 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: Transactions > 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)

10 years

1
0
0 / 0

[JBoss JIRA] (ISPN-2103) Concurrent access after removal of an AtomicMap should NOT result in an IllegalStateException when accessed by other threads

by Endre Szasz-Revai (JIRA)

[ https://issues.jboss.org/browse/ISPN-2103?page=com.atlassian.jira.plugin.... ] Endre Szasz-Revai commented on ISPN-2103: ----------------------------------------- We are sometimes getting an issue with stale sessions when starting up JBoss EAP 6.4.0 in clustering mode. {code:java} Caused by: java.lang.IllegalStateException: AtomicMap stored under key 0pmrbdehmonywqnaupracijayleprpraqblnlqnquinobu148781457430391740 has been concurrently removed! at org.infinispan.atomic.AtomicHashMapProxy.assertValid(AtomicHashMapProxy.java:149) at org.infinispan.atomic.AtomicHashMapProxy.getDeltaMapForRead(AtomicHashMapProxy.java:92) at org.infinispan.atomic.FineGrainedAtomicHashMapProxy.get(FineGrainedAtomicHashMapProxy.java:213) at at.prod.caching.CachingServiceImpl.getSessionCache(CachingServiceImpl.java:141) [caching.jar:] at at.prod.caching.CacheStrategy.getAccounts(CacheStrategy.java:75) [account.jar:] {code} and the resulting previous error in the log: {code:java} ("subsystem" => "infinispan"), ]) - failure description: {"JBAS014671: Failed services" => {"jboss.infinispan.prodCache.prodCache" => "org.jboss.msc.service.StartException in service jboss.infinispan.prodCache.prodCache: org.infinispan.CacheException: Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete() throws java.lang.InterruptedException on object of type StateTransferManagerImpl Caused by: org.infinispan.CacheException: Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete() throws java.lang.InterruptedException on object of type StateTransferManagerImpl Caused by: org.infinispan.CacheException: Initial state transfer timed out for cache prodCache on jboss_jboss-prod.prod.at/prodCache"}} JBAS014777: Services which failed to start: service jboss.infinispan.prodCache.prodCache: org.jboss.msc.service.StartException in service jboss.infinispan.prodCache.prodCache: org.infinispan.CacheException: Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete() throws java.lang.InterruptedException on object of type StateTransferManagerImpl {code} Any ideas? > Concurrent access after removal of an AtomicMap should NOT result in an IllegalStateException when accessed by other threads > ---------------------------------------------------------------------------------------------------------------------------- > > Key: ISPN-2103 > URL: https://issues.jboss.org/browse/ISPN-2103 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 5.1.5.FINAL > Reporter: Adrian Nistor > Assignee: Galder Zamarreño > > ISPN-1121 introduces an IllegalStateException that is being thrown from AtomicMap methods once the map handle has become stale (ie. removed from cache). In case of concurrent access, the exception is thrown to all threads not just to the thread that performed the removal. This was fine-ish in older versions of Infinispan before introduction of optimistic and pessimistic locking but it should be reconsidered now because: > 1. It interferes/overlaps with transaction isolation. We should rely on the selected locking scheme (OL/PL) to detect conflicts between transactions and report the problem accordingly. Especially if the stale map is used just for reading - this should be allowed to work rather than stop it. > 2. This exception is pretty disruptive and awkward to handle. All methods of an AtomicMap can result in this exception and the current thread has to be prepared for handling it if other threads remove the map. Not much transaction isolation. > 3. Since the TreeCache is backed by AtomicMap nearly all Tree API can throw this. > The proposed fix consists of: > 1. removing AtomicHashMap.removed flag and AtomicHashMap.markRemoved() method. > 2. revising AtomicHashMapProxy.assertValid() method to check only if the map is null (ie. removed) but no longer use the removed flag. > 3. revising ReadCommittedEntry.commit() method to no longer call markRemoved() method. > The consequences of these changes are: > 1. Any further access to a stale map results in IllegalStateException ONLY in the thread that performed the removal. This thread 'knows' the map is stale so it is fine to punish it. Other threads remain unaffected until lock acquisition or commit is performed (depending on locking model). > 2. Other threads can continue to use the previously obtained map handle for reads without danger of getting an exception. > 3. If a write operation is done on the map, the results depend on the locking model: > 3.1 optimistic locking + write skew check: a WriteSkewException will stop the commit during prepare > 3.2 optimistic locking, no write skew check: the write is committed and the work of the transaction that removed the map is overwritten. The map is effectively revived. > 3.3 pessimistic locking: same as 3.2 > Please note 3.2 and 3.3 work the same as for normal values (not atomic maps). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (ISPN-6376) Task information should return parameter names

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-6376?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-6376: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done Integrated in master. Thanks [~NadirX]! > Task information should return parameter names > ---------------------------------------------- > > Key: ISPN-6376 > URL: https://issues.jboss.org/browse/ISPN-6376 > Project: Infinispan > Issue Type: Task > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 9.0.0.Final, 9.0.0.Alpha1 > > > Scripts are already knowledgeable about parameter names. Extend this to tasks so that the names can be displayed in the console -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (ISPN-6377) Rebalance start event does not include node info

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-6377?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-6377: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done Integrated. Thanks [~NadirX]! > Rebalance start event does not include node info > ------------------------------------------------ > > Key: ISPN-6377 > URL: https://issues.jboss.org/browse/ISPN-6377 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 8.2.0.Final > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 9.0.0.Final, 9.0.0.Alpha1, 8.2.1.Final > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues March 2016