April 2015 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-5265) Optimize Getall operations over Hot Rod

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5265?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-5265: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1198556, https://bugzilla.redhat.com/show_bug.cgi?id=1194509, https://bugzilla.redhat.com/show_bug.cgi?id=1213367 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1198556, https://bugzilla.redhat.com/show_bug.cgi?id=1194509) > Optimize Getall operations over Hot Rod > --------------------------------------- > > Key: ISPN-5265 > URL: https://issues.jboss.org/browse/ISPN-5265 > Project: Infinispan > Issue Type: Enhancement > Reporter: Pedro Zapata > Assignee: William Burns > > - GetAll operation: to ensure that there’s a way to batch get multiple objects together. > - Improve performance for large data sets. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2183) Add the ability to fetch a set of keys at once (getAll)

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-2183?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-2183: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1198556, https://bugzilla.redhat.com/show_bug.cgi?id=1213367 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1198556) > Add the ability to fetch a set of keys at once (getAll) > ------------------------------------------------------- > > Key: ISPN-2183 > URL: https://issues.jboss.org/browse/ISPN-2183 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Reporter: Mircea Markus > Assignee: William Burns > Priority: Minor > Fix For: 7.2.0.CR1 > > > When a transaction knows in advance about the set of keys it needs to read, this cache.getAll(k1,k2,..kn) method can bring a some performance improvement: > 1. all the keys can be fetched from remote nodes in parallel > 2. keys that map to the same node can be grouped and fetched in the same RPC request > > Note that 1. can be be achieved even at this time by using Cache.getAsync(K) method - that's not as elegant though as it requires the user to write the code the code that waits on the Future objects that are returned. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5264) Optimize PutAll operations (library mode)

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5264?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-5264: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1198556, https://bugzilla.redhat.com/show_bug.cgi?id=1194509, https://bugzilla.redhat.com/show_bug.cgi?id=1213367 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1198556, https://bugzilla.redhat.com/show_bug.cgi?id=1194509) > Optimize PutAll operations (library mode) > ----------------------------------------- > > Key: ISPN-5264 > URL: https://issues.jboss.org/browse/ISPN-5264 > Project: Infinispan > Issue Type: Enhancement > Reporter: Pedro Zapata > Assignee: William Burns > Fix For: 7.2.0.CR1, 7.2.0.Final > > > - PutAll: to ensure that users can load massive amount of data into the grid quickly in Library mode > - Performance improvement over large data sets. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5266) Optimize PutAll operations (Hot Rod)

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5266?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-5266: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1198556, https://bugzilla.redhat.com/show_bug.cgi?id=1194509, https://bugzilla.redhat.com/show_bug.cgi?id=1213367 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1198556, https://bugzilla.redhat.com/show_bug.cgi?id=1194509) > Optimize PutAll operations (Hot Rod) > ------------------------------------ > > Key: ISPN-5266 > URL: https://issues.jboss.org/browse/ISPN-5266 > Project: Infinispan > Issue Type: Enhancement > Reporter: Pedro Zapata > Assignee: William Burns > Fix For: 7.2.0.CR1, 7.2.0.Final > > > - PutAll: to ensure that users can load massive amount of data into the grid quickly over Hot Rod. > - Performance improvement over large data sets. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5286) JSR-107 Support for clustered caches in HotRod implementation

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5286?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5286: ----------------------------------------------- Martin Gencur <mgencur(a)redhat.com> changed the Status of [bug 1200822|https://bugzilla.redhat.com/show_bug.cgi?id=1200822] from ON_QA to ASSIGNED > JSR-107 Support for clustered caches in HotRod implementation > -------------------------------------------------------------- > > Key: ISPN-5286 > URL: https://issues.jboss.org/browse/ISPN-5286 > Project: Infinispan > Issue Type: Bug > Components: JCache > Reporter: Matej Čimbora > Assignee: Ion Savin > > Current implementation supports only using local caches - usage of different cache types leads to the following exceptions (when using cache which is included in configuration file): > Client: > {code} > javax.cache.CacheException: ISPN021027: Failed to add local cache 'default' on the server > at org.infinispan.jcache.remote.ServerManager$3.run(ServerManager.java:118) > at org.infinispan.jcache.remote.ServerManager.withManagementClient(ServerManager.java:171) > at org.infinispan.jcache.remote.ServerManager.addCache(ServerManager.java:104) > at org.infinispan.jcache.remote.JCacheManager.create(JCacheManager.java:65) > at org.infinispan.jcache.AbstractJCacheManager.createCache(AbstractJCacheManager.java:94) > at org.infinispan.server.test.jcache.JCacheRemoteIT.testCachingConfiguration(JCacheRemoteIT.java:78) > {code} > Server: > {code} > 10:47:29,896 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) JBAS014612: Operation ("add") failed - address: ([ > ("subsystem" => "infinispan"), > ("cache-container" => "clustered"), > ("local-cache" => "default") > ]): org.jboss.msc.service.DuplicateServiceException: Service jboss.infinispan.clustered.default.config is already registered > at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158) > {code} > Furthermore, when using multiple nodes in the cluster and the cache is not amongst configured caches, it is created as 'local' only on one node (this relates to fact org.infinispan.jcache.remote.ServerManager is configured to use one specific management interface - which is btw hardcoded and cannot be changed). Exception can occur when trying to write into cache. > > Client > {code} > javax.cache.CacheException: ISPN021022: Cache named 'custom' was not found. > at org.infinispan.jcache.remote.JCacheManager.create(JCacheManager.java:75) > at org.infinispan.jcache.AbstractJCacheManager.createCache(AbstractJCacheManager.java:94) > at org.infinispan.server.test.jcache.JCacheRemoteIT.testCachingConfiguration(JCacheRemoteIT.java:78) > {code} > Server > {code} > 10:59:01,034 ERROR [org.infinispan.server.hotrod.HotRodDecoder] (HotRodServerWorker-1) ISPN005003: Exception reported: org.infinispan.server.hotrod.CacheNotFoundException: Cache with name 'custom' not found amongst the configured caches > at org.infinispan.server.hotrod.HotRodDecoder.getCache(HotRodDecoder.scala:102) > {code} > For full logs pease see linked BZ. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5392) ComparisonExpr.Type.negate() returns wrong value

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-5392?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-5392: -------------------------------- Status: Open (was: New) > ComparisonExpr.Type.negate() returns wrong value > ------------------------------------------------ > > Key: ISPN-5392 > URL: https://issues.jboss.org/browse/ISPN-5392 > Project: Infinispan > Issue Type: Bug > Components: Embedded Querying > Affects Versions: 7.2.0.CR1 > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 7.2.0.Final > > > The value returned for Type.GREATER should be LESS_OR_EQUAL but it wrongly returns LESS. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5392) ComparisonExpr.Type.negate() returns wrong value

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-5392?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-5392: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/3396 > ComparisonExpr.Type.negate() returns wrong value > ------------------------------------------------ > > Key: ISPN-5392 > URL: https://issues.jboss.org/browse/ISPN-5392 > Project: Infinispan > Issue Type: Bug > Components: Embedded Querying > Affects Versions: 7.2.0.CR1 > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 7.2.0.Final > > > The value returned for Type.GREATER should be LESS_OR_EQUAL but it wrongly returns LESS. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5392) ComparisonExpr.Type.negate() returns wrong value

by Adrian Nistor (JIRA)

Adrian Nistor created ISPN-5392: ----------------------------------- Summary: ComparisonExpr.Type.negate() returns wrong value Key: ISPN-5392 URL: https://issues.jboss.org/browse/ISPN-5392 Project: Infinispan Issue Type: Bug Components: Embedded Querying Affects Versions: 7.2.0.CR1 Reporter: Adrian Nistor Assignee: Adrian Nistor Fix For: 7.2.0.Final The value returned for Type.GREATER should be LESS_OR_EQUAL but it wrongly returns LESS. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5222) Perform Remote Filtering/Conversion in a single step

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-5222?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-5222: ----------------------------------- Status: Open (was: New) > Perform Remote Filtering/Conversion in a single step > ---------------------------------------------------- > > Key: ISPN-5222 > URL: https://issues.jboss.org/browse/ISPN-5222 > Project: Infinispan > Issue Type: Feature Request > Components: Listeners > Affects Versions: 7.1.0.Final > Reporter: Stylianos Koussouris > Assignee: Galder Zamarreño > Fix For: 7.2.0.Final > > > I want to have filter and convert take place in one step ie. do filtering and conversion applied to REMOTE LISTENERS in one step > a) I define CacheEventConverterFactory which implements CacheEventConverterFactory, Serializable > b) I register on the server org.infinispan.notifications.cachelistener.filter.CacheEventConverterFactory the cache event converter > which returns (CacheEventConverter<K, V, C>) new SharesDynamicFilterConverter(params); > c) I then define CacheEventFilterFactory which implements CacheEventFilterFactory, Serializable { > and returns(CacheEventFilter<K, V>) new SharesDynamicFilterConverter(params); > d) The CustomeDynamicFilterConverter extends AbstractCacheEventFilterConverter<String, Share, ShareProgress> implements Serializable { > and has the implementation of > public Share filterAndConvert(String key, Share oldValue, Metadata oldMetadata, Share newValue, Metadata newMetadata, EventType eventType) { > e) finally I define a listener binding it to the filter and converter > @ClientListener(filterFactoryName = "custom-dynamic-filter", > converterFactoryName = "custom-dynamic-converter", > includeCurrentState = true) > and register it along with params for the filter on the client side > cache.addClientListener(listener, new Object[]{"NYX", 50f}, null); > The result of this is that certainly both accept and convert methods are run and both call the same filterAndConvert method on SharesDynamicFilterConverter > However, this is not desirable as I don't want 2 steps which will effectively do the same thing but a single step. TBH I am not happy with the solution but what I did (in absence of better understanding of how to combine the steps -NOTE there is no single Factory for both Converter and Filter and even if it did we would probably have to implement accept & convert inside so the end result would have been the same) > So what I did was to change the last step > ie. > e) finally I define a listener binding ONLY the converter > @ClientListener(converterFactoryName = "murex-dynamic-converter", includeCurrentState = true) > and register it along with params ONLY for the converter on the client side > cache.addClientListener(listener, null, new Object[]{"NYX", 50f}); > This works as it actually does the filter during the convert step BUT is there another way and am I missing something? If not this would be a feature request -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5222) Perform Remote Filtering/Conversion in a single step

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-5222?page=com.atlassian.jira.plugin.... ] Work on ISPN-5222 started by Galder Zamarreño. ---------------------------------------------- > Perform Remote Filtering/Conversion in a single step > ---------------------------------------------------- > > Key: ISPN-5222 > URL: https://issues.jboss.org/browse/ISPN-5222 > Project: Infinispan > Issue Type: Feature Request > Components: Listeners > Affects Versions: 7.1.0.Final > Reporter: Stylianos Koussouris > Assignee: Galder Zamarreño > Fix For: 7.2.0.Final > > > I want to have filter and convert take place in one step ie. do filtering and conversion applied to REMOTE LISTENERS in one step > a) I define CacheEventConverterFactory which implements CacheEventConverterFactory, Serializable > b) I register on the server org.infinispan.notifications.cachelistener.filter.CacheEventConverterFactory the cache event converter > which returns (CacheEventConverter<K, V, C>) new SharesDynamicFilterConverter(params); > c) I then define CacheEventFilterFactory which implements CacheEventFilterFactory, Serializable { > and returns(CacheEventFilter<K, V>) new SharesDynamicFilterConverter(params); > d) The CustomeDynamicFilterConverter extends AbstractCacheEventFilterConverter<String, Share, ShareProgress> implements Serializable { > and has the implementation of > public Share filterAndConvert(String key, Share oldValue, Metadata oldMetadata, Share newValue, Metadata newMetadata, EventType eventType) { > e) finally I define a listener binding it to the filter and converter > @ClientListener(filterFactoryName = "custom-dynamic-filter", > converterFactoryName = "custom-dynamic-converter", > includeCurrentState = true) > and register it along with params for the filter on the client side > cache.addClientListener(listener, new Object[]{"NYX", 50f}, null); > The result of this is that certainly both accept and convert methods are run and both call the same filterAndConvert method on SharesDynamicFilterConverter > However, this is not desirable as I don't want 2 steps which will effectively do the same thing but a single step. TBH I am not happy with the solution but what I did (in absence of better understanding of how to combine the steps -NOTE there is no single Factory for both Converter and Filter and even if it did we would probably have to implement accept & convert inside so the end result would have been the same) > So what I did was to change the last step > ie. > e) finally I define a listener binding ONLY the converter > @ClientListener(converterFactoryName = "murex-dynamic-converter", includeCurrentState = true) > and register it along with params ONLY for the converter on the client side > cache.addClientListener(listener, null, new Object[]{"NYX", 50f}); > This works as it actually does the filter during the convert step BUT is there another way and am I missing something? If not this would be a feature request -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 11 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 April 2015