September 2013 - infinispan-issues

[JBoss JIRA] (ISPN-3533) Design HotRod protocol version 1.3

by Galder Zamarreño (JIRA)

Galder Zamarreño created ISPN-3533: -------------------------------------- Summary: Design HotRod protocol version 1.3 Key: ISPN-3533 URL: https://issues.jboss.org/browse/ISPN-3533 Project: Infinispan Issue Type: Enhancement Reporter: Galder Zamarreño Assignee: Mircea Markus Umbrella JIRA for Hot Rod improvements for version 1.3 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3529) Add support for the segment-based CH in the HotRod protocol

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-3529?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-3529: ----------------------------------- Assignee: Dan Berindei (was: Galder Zamarreño) > Add support for the segment-based CH in the HotRod protocol > ----------------------------------------------------------- > > Key: ISPN-3529 > URL: https://issues.jboss.org/browse/ISPN-3529 > Project: Infinispan > Issue Type: Feature Request > Components: Remote protocols > Affects Versions: 6.0.0.Alpha4 > Reporter: Dan Berindei > Assignee: Dan Berindei > Labels: hotrod, hotrod-java-client > Fix For: 6.0.0.Final > > > The server CH changed in version 5.2 from virtual-nodes-based to segment-based, but the client CH stayed the same. The server is able to translate the server CH into a client CH, but the translation is imperfect: > 1. Sometimes the client CH computes a different primary owner than the server CH. > 2. The client CH gets slower as the number of segments increases, the server CH performance stays the same. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2205) Design HotRod protocol version 1.2

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-2205?page=com.atlassian.jira.plugin.... ] Galder Zamarreño resolved ISPN-2205. ------------------------------------ Fix Version/s: 5.3.0.Final Resolution: Done > Design HotRod protocol version 1.2 > ---------------------------------- > > Key: ISPN-2205 > URL: https://issues.jboss.org/browse/ISPN-2205 > Project: Infinispan > Issue Type: Task > Components: Remote protocols > Affects Versions: 5.2.0.ALPHA2 > Reporter: Dan Berindei > Assignee: Galder Zamarreño > Labels: hotrod > Fix For: 5.3.0.Final > > > The consistent hash representation is changing in 5.2, and we need to modify the HotRod protocol to incorporate those changes. We preserved compatibility with 1.0/1.1 clients with a workaround on the server, but is not as efficient as it could be. > The new version could also incorporate fixes for older issues like ISPN-1293. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2205) Design HotRod protocol version 1.2

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-2205?page=com.atlassian.jira.plugin.... ] Galder Zamarreño commented on ISPN-2205: ---------------------------------------- [~mircea.markus], [~dan.berindei] is probably more suited to design the protocol part since he knows the inner details and gotchas of the new segments and routing table better than I do. I can for sure help with the implementation. Also, Hot Rod protocol version 1.2 was already released in [Infinispan 5.3.0.Final|https://github.com/infinispan/infinispan/blob/5.3.0.Final/cli...], so any further enhancements should really be included in another version of the protocol, maybe 1.3? This JIRA should be closed and marked as resolve in 5.3.0.Final, deferring ISPN-3529. > Design HotRod protocol version 1.2 > ---------------------------------- > > Key: ISPN-2205 > URL: https://issues.jboss.org/browse/ISPN-2205 > Project: Infinispan > Issue Type: Task > Components: Remote protocols > Affects Versions: 5.2.0.ALPHA2 > Reporter: Dan Berindei > Assignee: Galder Zamarreño > Labels: hotrod > > The consistent hash representation is changing in 5.2, and we need to modify the HotRod protocol to incorporate those changes. We preserved compatibility with 1.0/1.1 clients with a workaround on the server, but is not as efficient as it could be. > The new version could also incorporate fixes for older issues like ISPN-1293. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3532) AsyncStore has only one live AsyncStoreProcessor (thread) in one time

by Laszlo Hadadi (JIRA)

[ https://issues.jboss.org/browse/ISPN-3532?page=com.atlassian.jira.plugin.... ] Laszlo Hadadi updated ISPN-3532: -------------------------------- Git Pull Request: https://github.com/infinispan/infinispan/pull/2084 > AsyncStore has only one live AsyncStoreProcessor (thread) in one time > --------------------------------------------------------------------- > > Key: ISPN-3532 > URL: https://issues.jboss.org/browse/ISPN-3532 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 5.3.0.Final > Reporter: Laszlo Hadadi > Assignee: Mircea Markus > > AsyncStore cache modifications processed asynchronously only on one thread in one time. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3532) AsyncStore has only one live AsyncStoreProcessor (thread) in one time

by Laszlo Hadadi (JIRA)

Laszlo Hadadi created ISPN-3532: ----------------------------------- Summary: AsyncStore has only one live AsyncStoreProcessor (thread) in one time Key: ISPN-3532 URL: https://issues.jboss.org/browse/ISPN-3532 Project: Infinispan Issue Type: Bug Components: Loaders and Stores Affects Versions: 5.3.0.Final Reporter: Laszlo Hadadi Assignee: Mircea Markus AsyncStore cache modifications processed asynchronously only on one thread in one time. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3455) Cache replication not warranted under load

by Lukasz Szelag (JIRA)

[ https://issues.jboss.org/browse/ISPN-3455?page=com.atlassian.jira.plugin.... ] Lukasz Szelag commented on ISPN-3455: ------------------------------------- I was not able to replicate this issue using 5.2.7.Final version. It appears that this bug was introduced in 5.3.0.Final. > Cache replication not warranted under load > ------------------------------------------ > > Key: ISPN-3455 > URL: https://issues.jboss.org/browse/ISPN-3455 > Project: Infinispan > Issue Type: Feature Request > Affects Versions: 5.3.0.Final, 6.0.0.Alpha3 > Environment: JSE 1.6.0_45; Windows 7 > Reporter: Lukasz Szelag > Assignee: Mircea Markus > Attachments: infinispan.zip > > > Problem: > When running a replicated cache and repeatedly calling a cacheable method (using Spring cache abstraction), Infinispan enters an infinite replication loop. This can be confirmed by observing replication counts growing over time, where there are no cache misses. > Expected behavior: > Caches shouldn't be replicated when there is a cache hit. > Test case: > - 3 cluster members; asynchronous replication with a replication queue > - a cacheable method is executed repeatedly using 2 different keys > Notes: > - for some reason, this issue only occurs when using Enum arguments for a cache key; I was not able to replicate this when using int or String types (see com.designamus.infinispan.Main.works()) > - the behavior is not deterministic (random), which points to a race condition > - the problem does not seem to be related to the Spring's default cache key generator; I was able to reproduce the same behavior with a custom cache key generator, which was thread-safe > - the cacheable method is executed only twice (once both keys are stored in the cache); subsequent invocations retrieve stored values from the cache; this can be confirmed by inspecting the log file > - the cache doesn't expire and entries are not evicted > - the memory usage grows over time, eventually causing OOM on a heavily loaded system > - since the issue is random in nature it may take a 3-4 attempts to reproduce it; I was successful in reproducing this behavior numerous times > Steps to reproduce: > 1. Build a test project (mvn clean compile) > 2. Execute /run.sh (this will spawn 3 JVMs) > 3. Start JConsole to monitor 3 cluster members (jconsole localhost:17001 localhost:17002 localhost:17003) > 4. Monitor "replicationCount" attribute under RpcManager for cache "MyCache" for all JVMs (see /replication-counts.png) > 5. Observe that replication counts grow over time > 6. Observe that all caches are of size 2 and there are no cache misses (see /cache-statistics.png) > If the issue cannot be reproduced (replication counts stay at the same level): > 5. Terminate all 3 JVM processes (as a convenience you can execute /stop.sh) > 6. Repeat steps 2 through 5 above > When testing the above scenario using a distributed mode, I observed some other anomalies (i.e. the cacheable method was executed multiple times, as if the value was not there). While this may be related, it deserves a separate JIRA. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-962) Entries not committed w/ DistLockingInterceptor and L1 caching disabled.

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-962?page=com.atlassian.jira.plugin.s... ] William Burns resolved ISPN-962. -------------------------------- Fix Version/s: (was: 6.0.0.CR1) Resolution: Duplicate Issue This was fixed in ISPN-1012 > Entries not committed w/ DistLockingInterceptor and L1 caching disabled. > ------------------------------------------------------------------------ > > Key: ISPN-962 > URL: https://issues.jboss.org/browse/ISPN-962 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache, Locking and Concurrency > Affects Versions: 4.2.0.Final > Reporter: Shane Johnson > Assignee: William Burns > Priority: Critical > Labels: Invalidation, Rehash > > If you choose to disable the L1 cache (enabled=false AND onRehash=false) in distributed mode, the DistLockingInterceptor will NOT commit any invalidations due to a rehash back to the data container. > The problem is in the commitEntry method. > boolean doCommit = true; > if (!dm.isLocal(entry.getKey())) { > if (configuration.isL1CacheEnabled()) { > dm.transformForL1(entry); > } else { > doCommit = false; > } > } > if (doCommit) > entry.commit(dataContainer); > else > entry.rollback(); > For most commands, dm.isLocal returns TRUE and so the execution proceeds to commit. However, invalidation commands are unique in that they are executed on a remote node even though that node is NOT the owner of the entry. For that reason, the dm.isLocal returns FALSE and the execution proceeds to the L1 cache enabled check. If the L1 cache is disabled, the execution proceeds to set doCommit to false and rollback the invalidation. > We have temporarily fixed this by updating the else block to check and see if the entry has been removed. If it has not, we set doCommit to false like it does now. Otherwise, we set it to true. > To be honest, that was a safeguard in case we are missing something. I'm still not sure why we would ever want to set doCommit to false just because the L1 cache has been disabled. However, this change has fixed our problem with entries not being deleted from the original owners on a rehash. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3531) LifecycleManager of query module keeps references to per cache manager resources (jmx related)

by Adrian Nistor (JIRA)

Adrian Nistor created ISPN-3531: ----------------------------------- Summary: LifecycleManager of query module keeps references to per cache manager resources (jmx related) Key: ISPN-3531 URL: https://issues.jboss.org/browse/ISPN-3531 Project: Infinispan Issue Type: Bug Components: Querying Affects Versions: 6.0.0.Alpha4 Reporter: Adrian Nistor Assignee: Adrian Nistor Fix For: 6.0.0.Beta2 The resources in question are gathered when a cache manager is started and are used again when it is stopped. This does not work well if there are multiple cache managers that have different jmx domains. Cache stop event also does not seem to be processed correctly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2898) Web Cache fails to start when multiple apps are trying to create it

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-2898?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-2898: ----------------------------------------------- Paul Ferraro <paul.ferraro(a)redhat.com> changed the Status of [bug 918791|https://bugzilla.redhat.com/show_bug.cgi?id=918791] from POST to ON_QA > Web Cache fails to start when multiple apps are trying to create it > ------------------------------------------------------------------- > > Key: ISPN-2898 > URL: https://issues.jboss.org/browse/ISPN-2898 > Project: Infinispan > Issue Type: Bug > Affects Versions: 5.1.7.Final > Reporter: Shay Matasaro > Assignee: Dan Berindei > Fix For: 6.0.0.CR1 > > > When multiple apps are trying to create/connect to the web cache , the fist one get a lock on the cache manager, and prevents the others from starting it in a timely manner -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues September 2013