July 2015 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-5607) NearCache: it is possible to read stale data with a put/remove followed by a get

by Enrico Olivelli (JIRA)

[ https://issues.jboss.org/browse/ISPN-5607?page=com.atlassian.jira.plugin.... ] Enrico Olivelli updated ISPN-5607: ---------------------------------- Steps to Reproduce: It cannot be reproduced systematically, but the steps are "simple": - write an value, value=A - write an value, value=B - issue a get on the entry, it could return value=A in case of high network load (or slow network connection) it is simpler to reproduce while using a network of 2-3 servers, when the entry is hosted not on the same server that the listener is attechad to was: It cannot be reproduced systematically, but the steps are "simple": - write an value, value=A - write an value, value=B - issue a get on the entry, it could return value=A in case of high network load (or slow network connection) it is simpler to reproduce while using a network of 2-3 servers, when the entry is hosted not on the same server that the listener is atteched to > NearCache: it is possible to read stale data with a put/remove followed by a get > -------------------------------------------------------------------------------- > > Key: ISPN-5607 > URL: https://issues.jboss.org/browse/ISPN-5607 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.2.3.Final > Environment: one hotrod client with 2 hotrod servers > Reporter: Enrico Olivelli > Priority: Blocker > > Wites to the NearCache do not invalidate/update local data on put/remove operations, and so the NearCache (LAZY MODE) is invalidated using an eventlistener in an asynch way. > It is possible for a client to write a value and issue a get on the same key, and the result of the get would not be the latest value but the one which was present before the update operation. > This happens frequently when there is very much traffic on the connection of the listener which receives the events for the NearCache. > It would be better at least to invalidate locally every entry modified from the client itself -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5607) NearCache: it is possible to read stale data with a put/remove followed by a get

by Enrico Olivelli (JIRA)

[ https://issues.jboss.org/browse/ISPN-5607?page=com.atlassian.jira.plugin.... ] Enrico Olivelli updated ISPN-5607: ---------------------------------- Priority: Blocker (was: Major) > NearCache: it is possible to read stale data with a put/remove followed by a get > -------------------------------------------------------------------------------- > > Key: ISPN-5607 > URL: https://issues.jboss.org/browse/ISPN-5607 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.2.3.Final > Environment: one hotrod client with 2 hotrod servers > Reporter: Enrico Olivelli > Priority: Blocker > > Wites to the NearCache do not invalidate/update local data on put/remove operations, and so the NearCache (LAZY MODE) is invalidated using an eventlistener in an asynch way. > It is possible for a client to write a value and issue a get on the same key, and the result of the get would not be the latest value but the one which was present before the update operation. > This happens frequently when there is very much traffic on the connection of the listener which receives the events for the NearCache. > It would be better at least to invalidate locally every entry modified from the client itself -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5607) NearCache: it is possible to read stale data with a put/remove followed by a get

by Enrico Olivelli (JIRA)

Enrico Olivelli created ISPN-5607: ------------------------------------- Summary: NearCache: it is possible to read stale data with a put/remove followed by a get Key: ISPN-5607 URL: https://issues.jboss.org/browse/ISPN-5607 Project: Infinispan Issue Type: Bug Components: Core Affects Versions: 7.2.3.Final Environment: one hotrod client with 2 hotrod servers Reporter: Enrico Olivelli Wites to the NearCache do not invalidate/update local data on put/remove operations, and so the NearCache (LAZY MODE) is invalidated using an eventlistener in an asynch way. It is possible for a client to write a value and issue a get on the same key, and the result of the get would not be the latest value but the one which was present before the update operation. This happens frequently when there is very much traffic on the connection of the listener which receives the events for the NearCache. It would be better at least to invalidate locally every entry modified from the client itself -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5547) Get MarshalledValue when iterating the persistent cache with storeAsBinary set to true

by Fei Chen (JIRA)

[ https://issues.jboss.org/browse/ISPN-5547?page=com.atlassian.jira.plugin.... ] Fei Chen updated ISPN-5547: --------------------------- Priority: Blocker (was: Major) > Get MarshalledValue when iterating the persistent cache with storeAsBinary set to true > -------------------------------------------------------------------------------------- > > Key: ISPN-5547 > URL: https://issues.jboss.org/browse/ISPN-5547 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.1.1.Final > Reporter: Fei Chen > Priority: Blocker > > Please see https://developer.jboss.org/thread/258545 for details. The key issue is: > The ClassCastException happens when trying to iterator the cache: > 06:54:47,057 ERROR [org.jboss.as.ejb3.invocation] (http-localhost/127.0.0.1:8680-1) JBAS014134: EJB Invocation failed on component PublishManagerLocalBean for method public abstract java.util.Set com.test.PublishManager.getChannels(): javax.ejb.EJBException: java.lang.ClassCastException: org.infinispan.marshall.core.MarshalledValue cannot be cast to com.test.Channel > The problem is: I store only one entry into the cache. But afterwards when iterating the cache, 2 entries are returned. One entry is with type Channel which looks correct, but there is another entry with type MarshalledValue. > After a few investigation, we see this issue only happens when the 1. cache is persistent and 2. storeAsBinary is enabled. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 5 months

1
0
0 / 0

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

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5606?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5606: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/3584 > 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)

9 years, 5 months

1
0
0 / 0

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

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5606?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5606: ---------------------------------- Status: Open (was: New) > 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)

9 years, 5 months

1
0
0 / 0

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

by Tristan Tarrant (JIRA)

Tristan Tarrant created ISPN-5606: ------------------------------------- Summary: 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)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5452) Query Execution using Hibernate Search slow for large volume data

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/ISPN-5452?page=com.atlassian.jira.plugin.... ] Sanne Grinovero commented on ISPN-5452: --------------------------------------- Hi, thanks for the attachment, I'm starting to look into this. I'm not familiar with this format, which profiling tool have you used to produce it? And could you add a note to explain to which configuration each report refers too? I'm not sure what {{1.45}} and {{1.34}} are referring to. Also, it looks like you're using an extremely old version of Hibernate; I hope you'll update that ;-) > Query Execution using Hibernate Search slow for large volume data > ----------------------------------------------------------------- > > Key: ISPN-5452 > URL: https://issues.jboss.org/browse/ISPN-5452 > Project: Infinispan > Issue Type: Bug > Components: Configuration, Remote Querying > Affects Versions: 7.2.1.Final > Environment: Linux > Reporter: Prashant Thakur > Attachments: profiling_results.7z > > > While benchmarking Infinispan we found that Querying is very slow when compared with Hibernate Search in Isolation > Single node of Infinispan > Memory allocated 230GB. No GC seen throughout query operation. > Total required after full GC was 122GB. > Setup 240 million records each of avg size 330 bytes . > System has 16 cores and 40 worker threads were allocated at server side. > With Single Client thread throughput was 900 req/sec in remote and 3k per sec in embedded more same request with Hibernate Search in Isolation gives throughput of 14000 req/sec. > For 50 threads of clients the throughput was limited to 15k req/sec while hibernate search gives 80k req/sec for 10 threads. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5548) Realign JGroups subsystem with the one from WildFly

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-5548?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-5548: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Realign JGroups subsystem with the one from WildFly > --------------------------------------------------- > > Key: ISPN-5548 > URL: https://issues.jboss.org/browse/ISPN-5548 > Project: Infinispan > Issue Type: Task > Components: Server > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 8.0.0.Final > > > The JGroups subsystem in WildFly has evolved to support forked channels and has also been including the relay support which he had grafted on. > We should rebase our own on the WildFly one, add any delta (SASL), package it to make it standalone (the WildFly one depends on a variety of clustering modules) and give it its own management model name to distinguish from the WildFly one to allow parallel installation. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5605) Implement getAffectedKeys() in InvalidateCommand

by Radim Vansa (JIRA)

Radim Vansa created ISPN-5605: --------------------------------- Summary: Implement getAffectedKeys() in InvalidateCommand Key: ISPN-5605 URL: https://issues.jboss.org/browse/ISPN-5605 Project: Infinispan Issue Type: Bug Reporter: Radim Vansa Priority: Minor InvalidateCommand overloads {{getKey()}} throwing {{UnsupportedOperationException}}, but {{getAffectedKeys()}} returns collection with {{null}} or one of the invalidated keys. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues July 2015