March 2014 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-4094) Memory leak in RemoteQueryDslConditionsTest

by Dan Berindei (JIRA)

Dan Berindei created ISPN-4094: ---------------------------------- Summary: Memory leak in RemoteQueryDslConditionsTest Key: ISPN-4094 URL: https://issues.jboss.org/browse/ISPN-4094 Project: Infinispan Issue Type: Bug Components: Test Suite - Server Affects Versions: 7.0.0.Alpha1 Reporter: Dan Berindei Assignee: Dan Berindei Fix For: 7.0.0.Alpha2 A {{RemoteCacheManager}} instance is created for each test method in {{RemoteQueryDslConditionsTest}}, because of the {{@CleanupAfterMethod}} annotation. But the {{@AfterTest}} method that stops the remote cache is only once for the entire class, so all but one of the remote cache managers are not stopped properly. {{GenericKeyedObjectPool}} registers a timer in {{EvictionTimer}}, which keeps the pool and the {{TcpTransport}} objects in it alive. And because the size of the buffer used by the transport is very big (1838kb on my system), {{RemoteQueryDslConditionsTest}} and its subclasses can quickly fill up the heap. -- 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

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4094) Memory leak in RemoteQueryDslConditionsTest

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-4094?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-4094: ------------------------------- Labels: testsuite_stability (was: ) > Memory leak in RemoteQueryDslConditionsTest > ------------------------------------------- > > Key: ISPN-4094 > URL: https://issues.jboss.org/browse/ISPN-4094 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Server > Affects Versions: 7.0.0.Alpha1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Labels: testsuite_stability > Fix For: 7.0.0.Alpha2 > > > A {{RemoteCacheManager}} instance is created for each test method in {{RemoteQueryDslConditionsTest}}, because of the {{@CleanupAfterMethod}} annotation. But the {{@AfterTest}} method that stops the remote cache is only once for the entire class, so all but one of the remote cache managers are not stopped properly. > {{GenericKeyedObjectPool}} registers a timer in {{EvictionTimer}}, which keeps the pool and the {{TcpTransport}} objects in it alive. And because the size of the buffer used by the transport is very big (1838kb on my system), {{RemoteQueryDslConditionsTest}} and its subclasses can quickly fill up the heap. -- 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

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4025) Cross-Site State Transfer: failure scenarios

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-4025?page=com.atlassian.jira.plugin.... ] Work on ISPN-4025 started by Pedro Ruivo. > Cross-Site State Transfer: failure scenarios > -------------------------------------------- > > Key: ISPN-4025 > URL: https://issues.jboss.org/browse/ISPN-4025 > Project: Infinispan > Issue Type: Sub-task > Components: Cross-Site Replication > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Fix For: 7.0.0.Final > > > Needs to handle the following scenarios (at least): > * join/leave in the consumer site (i.e. site that receives the the state) > I think NBST will handle most of join scenario. However, the leave scenario needs to be handle carefully or we can loose some key chunks. (easy solution: resend all the chunk?) > * join/leave in the producer site (i.e. site that sends the state) > trick scenario. we have to be sure that all keys are really sent! (naive solution: restart the state transfer) > * state transfer coordinator dies > the coordinator node is the one that receives the acks when all members has finished sending the keys. Or we replicate its state or we restart the state transfer... > * site master dies in consumer site > No idea which keys was already applied or not. need to resend the chunks... -- 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

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3797) DataContainer should interact atomically with Persistence

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3797?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-3797: ------------------------------ Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/2432 > DataContainer should interact atomically with Persistence > --------------------------------------------------------- > > Key: ISPN-3797 > URL: https://issues.jboss.org/browse/ISPN-3797 > Project: Infinispan > Issue Type: Enhancement > Components: Eviction, Loaders and Stores > Affects Versions: 6.0.0.Final > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Fix For: 7.0.0.Final > > > DataContainer should handle atomically all the interactions with the Persistence. This includes all the eviction/passivation. > Main points: > * In DataContainer load/store will avoid any lose of data during concurrent operations > * Take advantage of CHMv8 > * CacheLoader and Writer Interceptors are no longer needed. > Check the mailling list for more info. -- 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

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4092) ViewChangedEvent.getOldMembers() and getNewMembers() should never be null

by Eric Bonnot (JIRA)

[ https://issues.jboss.org/browse/ISPN-4092?page=com.atlassian.jira.plugin.... ] Eric Bonnot commented on ISPN-4092: ----------------------------------- Well, yes, I haven't noticed that when I cloned the previous issue... But it reveals that Infinispan issues are strongly monitored (thank you for your quick reply) ! So maybe : @Override public List<Address> getNewMembers() { if(this.newMembers == null){ this.setNewMembers(InfinispanCollections.emptyList()); } return this.newMembers; } public synchronized void setNewMembers(List<Address> newMembers) { this.newMembers = newMembers; } public synchronized void setOldMembers(List<Address> oldMembers) { this.oldMembers = oldMembers; } @Override public List<Address> getOldMembers() { if(this.oldMembers == null){ this.setOldMembers(InfinispanCollections.emptyList()); } return this.oldMembers; } And maybe : public synchronized void setSubgroupsMerged(List<List<Address>> subgroupsMerged) { this.subgroupsMerged = subgroupsMerged; } @Override public List<List<Address>> getSubgroupsMerged() { if(this.subgroupsMerged== null){ this.setSubgroupsMerged(InfinispanCollections.emptyList()); } return this.subgroupsMerged; } > ViewChangedEvent.getOldMembers() and getNewMembers() should never be null > ------------------------------------------------------------------------- > > Key: ISPN-4092 > URL: https://issues.jboss.org/browse/ISPN-4092 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 6.0.1.Final > Reporter: Eric Bonnot > Assignee: Thomas Fromm > Priority: Minor > > Simply for more comfort at usage I'd like to have ViewChangedEvent changed, that the list-getter never return null. -- 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

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-1342) Support for Near-Cache Pattern

by Mikolaj Gierulski (JIRA)

[ https://issues.jboss.org/browse/ISPN-1342?page=com.atlassian.jira.plugin.... ] Mikolaj Gierulski commented on ISPN-1342: ----------------------------------------- I think I was able to achieve this in a patched version of 6.0.0.Final. I created a dist cache with L1 enabled and nearcache nodes having capacityFactor="0" configured (this required patching, as capacityFactor configuration doesn't work in 6.0.0.Final). > Support for Near-Cache Pattern > ------------------------------ > > Key: ISPN-1342 > URL: https://issues.jboss.org/browse/ISPN-1342 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Affects Versions: 5.0.0.FINAL > Reporter: Peter Novak > Assignee: Manik Surtani > > Please create some support for near-cache pattern for distributed cache. Some detailed description could be found in Oracle Coherence documentation http://download.oracle.com/docs/cd/E13924_01/coh.340/e13819/nearcache.htm or in Cameron Purdy presentation http://frech.info/themen/CameronPurdy-DistributedCachingEssentialLessons.pdf > It is based on combination of L1 caching in local JVM of application with combination of L2 cache based on distributed cache cluster on other servers. I tried to implement this myself, but HotRod does not support Client-side listeners (The UnsupportedOperationException is thrown). It could be cool, if I could register some kind of eviction listener on client side and use it for invalidation of records in local cache based on event from remote distributed cache (L2). > Some kind of workaround was described in http://community.jboss.org/thread/166993 : "We don't have L1s yet, but you could implement Cache Listeners on the server side and use JMS to notify your clients and build an L1 that way." > Thanks for so great cache like infinispan is. -- 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

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4093) Inefficient implementation of containsKey in distribute cache for large entries

by Mikolaj Gierulski (JIRA)

Mikolaj Gierulski created ISPN-4093: --------------------------------------- Summary: Inefficient implementation of containsKey in distribute cache for large entries Key: ISPN-4093 URL: https://issues.jboss.org/browse/ISPN-4093 Project: Infinispan Issue Type: Enhancement Components: Core Affects Versions: 6.0.0.Final Reporter: Mikolaj Gierulski Assignee: Dan Berindei Priority: Minor As far as I understand, containsKey on distributed cache performs a GetKeyValueCommand (which may be executed remotedly) and checks if the result was null. This results in loading the whole entry, which may be expensive when dealing with large entries. In our system we introduced a KeyExistsTask implementing DistributedCallable, which we submit with distributed execution framework. This task performs cache.containsKey on keys local node avoiding unnecessary transfer of possibly large amount of data. In our case this brought a significant improvement of containsKey operation. Best regards, Mikolaj -- 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

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-833) Revisit cache name predefinition limitation for cache servers

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-833?page=com.atlassian.jira.plugin.s... ] Galder Zamarreño updated ISPN-833: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/2431 > Revisit cache name predefinition limitation for cache servers > ------------------------------------------------------------- > > Key: ISPN-833 > URL: https://issues.jboss.org/browse/ISPN-833 > Project: Infinispan > Issue Type: Feature Request > Components: Remote Protocols > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 7.0.0.Final, 7.0.0.Alpha2 > > > There're are two primary reasons why Infinispan servers require predefined caches to be started up on startup, and do not allow invocations to undefined caches: > 1. Concurrent cache startups were resulting in NPEs (ISPN-635) - This is already solved since the 4.2.x days. > 2. Infinispan has issues dealing with asymmetric clusters (ISPN-658). > Once these two issues have been resolved, revisit the limitation. -- 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

10 years, 10 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: ----------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/2431 > 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: Galder Zamarreño > Labels: hotrod, hotrod-java-client > Fix For: 7.0.0.Alpha2 > > > 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

10 years, 10 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: ----------------------------------- Fix Version/s: 7.0.0.Final > 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: Galder Zamarreño > Labels: hotrod, hotrod-java-client > Fix For: 7.0.0.Final, 7.0.0.Alpha2 > > > 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

10 years, 10 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues March 2014