February 2016 - infinispan-issues

[JBoss JIRA] (ISPN-6130) # Activations shows incorrect value

by Jiří Holuša (JIRA)

[ https://issues.jboss.org/browse/ISPN-6130?page=com.atlassian.jira.plugin.... ] Jiří Holuša reassigned ISPN-6130: --------------------------------- Assignee: Vladimir Blagojevic > # Activations shows incorrect value > ------------------------------------ > > Key: ISPN-6130 > URL: https://issues.jboss.org/browse/ISPN-6130 > Project: Infinispan > Issue Type: Bug > Components: Console > Affects Versions: 8.1.0.Beta1 > Reporter: Martin Vrabel > Assignee: Vladimir Blagojevic > > Page: Caches -> select cache container -> select cache. > Configuration of the cache: replicated cache, 2 nodes in the domain evictions size=10 > In the Entries lifecycle" tab, there is a field "# Activations" which should show number of Activations . When I put 10 entries in the cache and read 10, this field #Activations show 0 as is should. But when I insert another 10 entries (so the first 10 entries will evict and be stored in the cache store) and read the first 10 entries the #Activations field will show 0, but it should be 10 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-6174) Avoid calling the server after iteration is done in the remote iterator

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-6174?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-6174: ------------------------------------ Status: Open (was: New) > Avoid calling the server after iteration is done in the remote iterator > ----------------------------------------------------------------------- > > Key: ISPN-6174 > URL: https://issues.jboss.org/browse/ISPN-6174 > Project: Infinispan > Issue Type: Enhancement > Affects Versions: 8.2.0.Beta1 > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Priority: Minor > Fix For: 8.2.0.CR1 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-6174) Avoid calling the server after iteration is done in the remote iterator

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-6174?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-6174: ------------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/3987 > Avoid calling the server after iteration is done in the remote iterator > ----------------------------------------------------------------------- > > Key: ISPN-6174 > URL: https://issues.jboss.org/browse/ISPN-6174 > Project: Infinispan > Issue Type: Enhancement > Affects Versions: 8.2.0.Beta1 > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Priority: Minor > Fix For: 8.2.0.CR1 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-5811) View list of jobs status

by Pedro Zapata (JIRA)

[ https://issues.jboss.org/browse/ISPN-5811?page=com.atlassian.jira.plugin.... ] Pedro Zapata reassigned ISPN-5811: ---------------------------------- Assignee: Pedro Zapata (was: Vladimir Blagojevic) > View list of jobs status > ------------------------ > > Key: ISPN-5811 > URL: https://issues.jboss.org/browse/ISPN-5811 > Project: Infinispan > Issue Type: Sub-task > Components: Console > Reporter: Pedro Zapata > Assignee: Pedro Zapata > > As an administrator, I want to know the set of server script jobs which have completed. Info should include, start time and end time of the jobs, number of successful execution, number of failed executions. > See details in mockup screen: > https://rawgit.com/infinispan/infinispan-console-mockup/master/cache-cont... > The task output (if any), will be render (=toString()) as plain text in a pre-formatted area. Output will be trimmed down to some max size to prevent storing something too big. The default max size for output will be 64KB. > Jobs are never retried automatically. > Map/Reduce jobs are not to be displayed in this screen. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

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: ----------------------------------------------- Enrique Gonzalez Martinez <egonzale(a)redhat.com> changed the Status of [bug 1273147|https://bugzilla.redhat.com/show_bug.cgi?id=1273147] from POST to MODIFIED > 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 month

1
0
0 / 0

[JBoss JIRA] (ISPN-6190) JMX attribute cacheLoaderLoads number differs from # Loads number in management console

by Martin Vrabel (JIRA)

Martin Vrabel created ISPN-6190: ----------------------------------- Summary: JMX attribute cacheLoaderLoads number differs from # Loads number in management console Key: ISPN-6190 URL: https://issues.jboss.org/browse/ISPN-6190 Project: Infinispan Issue Type: Bug Components: Console Affects Versions: 8.1.1.Final Reporter: Martin Vrabel Page: Caches -> select cache container -> select cache. Configuration of the cache: replication cache, 2 nodes in the domain, evictions size=10 In the "Cache loader" tab, there is a field "# Loads" which should show number of Loaded entries from cache store . When I put 20 entries in the cache, the first 10 will evict and be stored in the cache store. If I read the first 10 entries the #Loads number in management console is 30 and JMX attribute cacheLoaderLoads in Jconsole is 10 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-6128) Expose ProtoBuf Manager through DMR

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-6128?page=com.atlassian.jira.plugin.... ] Adrian Nistor commented on ISPN-6128: ------------------------------------- Some of the ops were already there, so I kept their existing names. The ops are: :get-proto-schema-names() :get-proto-schema-name(file-name=myschema.proto) :unregister-proto-schemas(file-names=[]) :register-proto-schemas(file-names=[], file-contents=[]) :upload-proto-schemas(file-names=[], file-urls=[]) > Expose ProtoBuf Manager through DMR > ----------------------------------- > > Key: ISPN-6128 > URL: https://issues.jboss.org/browse/ISPN-6128 > Project: Infinispan > Issue Type: Task > Components: Remote Querying, Server > Reporter: Tristan Tarrant > Assignee: Adrian Nistor > Fix For: 8.2.0.CR1, 8.2.0.Final > > > The ProtoBuf Manager should be exposed through the DMR as a child resource under cache-container nodes. The resource should expose a number of operations to list, get, set, remove installed schemas. > Example: > .../cache-container=container/protobuf-schemas=PROTOBUF-SCHEMAS > :list-schemas() > :get-schema(name=myschema) > :remove-schema(name=myschema) > :set-schema(name=myschema, schema-source=...) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-6134) # Passivations in management show the wrong value

by Martin Vrabel (JIRA)

[ https://issues.jboss.org/browse/ISPN-6134?page=com.atlassian.jira.plugin.... ] Martin Vrabel closed ISPN-6134. ------------------------------- Resolution: Cannot Reproduce Bug > # Passivations in management show the wrong value > -------------------------------------------------- > > Key: ISPN-6134 > URL: https://issues.jboss.org/browse/ISPN-6134 > Project: Infinispan > Issue Type: Bug > Components: Console > Reporter: Martin Vrabel > > Page: Caches -> select cache container -> select cache. > Configuration of the cache: replicated cache, 2 nodes in the domain, eviction size=10 > In the Entries lifecycle" tab, there is a field "# Passivations" which should show number of Passivations . When I put 10 entries in the cache and then another 10, this field should show 10. But it show 0 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-6181) # Stores shows incorrect value

by Martin Vrabel (JIRA)

[ https://issues.jboss.org/browse/ISPN-6181?page=com.atlassian.jira.plugin.... ] Martin Vrabel closed ISPN-6181. ------------------------------- Resolution: Cannot Reproduce Bug > # Stores shows incorrect value > ------------------------------ > > Key: ISPN-6181 > URL: https://issues.jboss.org/browse/ISPN-6181 > Project: Infinispan > Issue Type: Bug > Components: Console > Reporter: Martin Vrabel > > Page: Caches -> select cache container -> select cache. > Configuration of the cache: replication cache, 2 nodes in the domain, evictions size=10 > When I put 10 entries in the cache , this field #stores show 10 but should be 0. When I insert another 10 entries the number should be 10 but is 20 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-6180) #invalidations shows incorrect value

by Martin Vrabel (JIRA)

[ https://issues.jboss.org/browse/ISPN-6180?page=com.atlassian.jira.plugin.... ] Martin Vrabel closed ISPN-6180. ------------------------------- Resolution: Cannot Reproduce Bug > #invalidations shows incorrect value > ------------------------------------ > > Key: ISPN-6180 > URL: https://issues.jboss.org/browse/ISPN-6180 > Project: Infinispan > Issue Type: Bug > Components: Console > Reporter: Martin Vrabel > > Page: Caches -> select cache container -> select cache. > Configuration of the cache: invalidation cache, 2 nodes in the domain evictions size=10 > In the Entries lifecycle" tab, there is a field "# invalidations" which should show number of invalidations . When I put 10 entries in the cache , this field #invalidations show 10 but should be 0. When I insert another 10 entries the number should be 10 but is 20 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues February 2016