October 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-825) Consider staggering remote get requests when using DIST

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-825?page=com.atlassian.jira.plugin.s... ] Mircea Markus updated ISPN-825: ------------------------------- Fix Version/s: (was: 6.0.0.Final) > Consider staggering remote get requests when using DIST > ------------------------------------------------------- > > Key: ISPN-825 > URL: https://issues.jboss.org/browse/ISPN-825 > Project: Infinispan > Issue Type: Feature Request > Components: RPC > Affects Versions: 4.1.0.Final > Reporter: Manik Surtani > Assignee: Mircea Markus > Priority: Critical > Labels: optimization, performance > > In DIST mode, when a request is made on a key that is not mapped locally, a remote get is sent to all data owners of that key and the first response is used. This can add unnecessary load on the network as all nodes still eventually respond, and if values are large this can cause a lot of unnecessary network traffic. > The purpose of broadcasting to all data owners is so that (1) if one is down, another could still respond (2) if one is overloaded, others may respond faster. > A solution around this could be based on either (or both) of: > * Provide a configurable stagger timeout, e.g. 100ms. E.g., RPC to (random) Owner1. Wait for timeout t. If no response, RPC to Owner2. etc. > * Always broadcast to a (configurable) subset of owners, e.g., always 2 even if numOwners is 5. > Needs careful thought and design. -- 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-2141) Better configuration options for Infinispan Query

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2141?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2141: -------------------------------- Fix Version/s: (was: 6.0.0.Final) > Better configuration options for Infinispan Query > ------------------------------------------------- > > Key: ISPN-2141 > URL: https://issues.jboss.org/browse/ISPN-2141 > Project: Infinispan > Issue Type: Feature Request > Components: Querying > Reporter: Sanne Grinovero > Assignee: Tristan Tarrant > > Rethink the configuration options for Query. > See also https://community.jboss.org/wiki/InfinispanQuery-DesignAndPlanning -- 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-1855) Accessing a non-distributed cache from a RemoteCacheManager can break topology updates

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-1855?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-1855: -------------------------------- Fix Version/s: (was: 6.0.0.Final) > Accessing a non-distributed cache from a RemoteCacheManager can break topology updates > -------------------------------------------------------------------------------------- > > Key: ISPN-1855 > URL: https://issues.jboss.org/browse/ISPN-1855 > Project: Infinispan > Issue Type: Bug > Components: Remote protocols > Affects Versions: 5.1.1.FINAL > Reporter: Dan Berindei > Assignee: Galder Zamarreño > > RemoteCacheManager uses a single consistent hash to map requests to different servers, but caches on the server may have different CHs (or even no CH if the cache is not in distributed mode). > If the first request goes to a on-distributed cache, the client will never request an updated CH and so it will use a round robin strategy for routing request to all the caches. Obviously this is not optimal for distributed caches. > Each distributed cache can also have different members since 5.1, so it would be best if we kept a separate CH per cache on the client. -- 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-1822) Cache entry not evicted from memory on IBM JDK when another entry was loaded from a cache loader and maxEntries had been reached

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-1822?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-1822: -------------------------------- Fix Version/s: (was: 6.0.0.Final) > Cache entry not evicted from memory on IBM JDK when another entry was loaded from a cache loader and maxEntries had been reached > -------------------------------------------------------------------------------------------------------------------------------- > > Key: ISPN-1822 > URL: https://issues.jboss.org/browse/ISPN-1822 > Project: Infinispan > Issue Type: Bug > Components: Eviction > Affects Versions: 5.1.0.FINAL > Environment: java version "1.6.0" > Java(TM) SE Runtime Environment (build pxi3260sr9fp1-20110208_03(SR9 FP1)) > IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 Linux x86-32 jvmxi3260sr9-20110203_74623 (JIT enabled, AOT enabled) ; > java version "1.7.0" > Java(TM) SE Runtime Environment (build pxi3270-20110827_01) > IBM J9 VM (build 2.6, JRE 1.7.0 Linux x86-32 20110810_88604 (JIT enabled, AOT enabled) > Reporter: Martin Gencur > Assignee: Tristan Tarrant > > This behavior is specific to IBM JDK (I tried JDK6 and 7), it works fine with Java HotSpot. > Steps to reproduce the problem: > 1) set maxEntries for eviction to 2 and algorithm e.g. to LRU > 2) store 3 entries key1, key2, key3 to the cache (after that you can see that the cache contains only 2 entries - key2 and key3, the first one was evicted from memory) > 3) call cache.get("key1") > 4) PROBLEM - cache contains all key1, key2, key3 even though it should contain only 2 entries - only happens with IBM JDK (6 or 7 ..no matter) > I'll shortly issue a pull request with a test to ispn-core -- 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-3589) StackOverflow in InternalMetadataImpl.Externalizer

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3589?page=com.atlassian.jira.plugin.... ] Pedro Ruivo commented on ISPN-3589: ----------------------------------- ah, almost forgot, the test where I detected this was: https://github.com/pruivo/infinispan/blob/ISPN-2958/lucene/lucene-v3/src/... just set the TERMS_TO_ADD>=20000 (with 20000 it fails in my laptop...) > StackOverflow in InternalMetadataImpl.Externalizer > -------------------------------------------------- > > Key: ISPN-3589 > URL: https://issues.jboss.org/browse/ISPN-3589 > Project: Infinispan > Issue Type: Bug > Affects Versions: 6.0.0.CR1 > Reporter: Pedro Ruivo > Assignee: Mircea Markus > > the implementation delegates to another metadata some methods. The result is a chain of InternalMetadataImpl as you can see in: > {code} > metadata=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=Inte > rnalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl > {actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=Internal > MetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{act > ual=InternalMetadataImpl [....] > {code} -- 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-1947) Automate staging repository step in release script

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-1947?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-1947: -------------------------------- Fix Version/s: (was: 6.0.0.Final) > Automate staging repository step in release script > -------------------------------------------------- > > Key: ISPN-1947 > URL: https://issues.jboss.org/browse/ISPN-1947 > Project: Infinispan > Issue Type: Task > Components: Build process > Reporter: Sanne Grinovero > Assignee: Manik Surtani > Priority: Optional > > The following plugin can be used to control the staging repository from command line (including authenticating with your account as set in your settings file) > {code:xml} > <plugin> > <groupId>org.sonatype.plugins</groupId> > <artifactId>nexus-maven-plugin</artifactId> > <configuration> > <nexusUrl>https://repository.jboss.org/nexus</nexusUrl> > <automatic>true</automatic> > </configuration> > </plugin> > {code} > Goals are described at: https://repository.sonatype.org/content/sites/maven-sites/nexus-maven-plu... -- 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-1896) ClusteredGetCommands should never fail with a SuspectException

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-1896?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-1896: -------------------------------- Fix Version/s: (was: 6.0.0.Final) > ClusteredGetCommands should never fail with a SuspectException > -------------------------------------------------------------- > > Key: ISPN-1896 > URL: https://issues.jboss.org/browse/ISPN-1896 > Project: Infinispan > Issue Type: Bug > Components: RPC > Affects Versions: 5.1.6.FINAL > Reporter: Dan Berindei > Assignee: Dan Berindei > > I have seen this exception in the core test suite logs: > {noformat} > 2012-03-02 15:07:19,718 ERROR (testng-VersionedDistStateTransferTest) [org.infinispan.test.fwk.UnitTestTestNGListener] Method testStateTransfer(org.infinispan.container.versioning.VersionedDistStateTransferTest) threw an exceptionorg.infinispan.CacheException: SuspectedException > at org.infinispan.util.Util.rewrapAsCacheException(Util.java:524) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:168) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:478) > at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:148) > at org.infinispan.distribution.DistributionManagerImpl.retrieveFromRemoteSource(DistributionManagerImpl.java:169) > at org.infinispan.interceptors.DistributionInterceptor.realRemoteGet(DistributionInterceptor.java:212) > at org.infinispan.interceptors.DistributionInterceptor.remoteGetAndStoreInL1(DistributionInterceptor.java:194) > at org.infinispan.interceptors.DistributionInterceptor.remoteGetBeforeWrite(DistributionInterceptor.java:440) > at org.infinispan.interceptors.DistributionInterceptor.handleWriteCommand(DistributionInterceptor.java:455) > at org.infinispan.interceptors.DistributionInterceptor.visitPutKeyValueCommand(DistributionInterceptor.java:274) > ... > Caused by: SuspectedException > at org.jgroups.blocks.MessageDispatcher.sendMessage(MessageDispatcher.java:349) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.processSingleCall(CommandAwareRpcDispatcher.java:263) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:163) > ... 60 more > {noformat} > The remote get command should return null instead of failing, even if it had a single target node. -- 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-1856) Allow independent configuration of buffer allocation size vs segment chunks maximum size

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-1856?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-1856: -------------------------------- Fix Version/s: (was: 6.0.0.Final) > Allow independent configuration of buffer allocation size vs segment chunks maximum size > ---------------------------------------------------------------------------------------- > > Key: ISPN-1856 > URL: https://issues.jboss.org/browse/ISPN-1856 > Project: Infinispan > Issue Type: Enhancement > Components: Lucene Directory > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > > Especially make sure that we can allocate buffers efficiently when having chunk_size=MAX_INTEGER or other very high values. > Maybe reuse them as well? -- 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-2059) Custom CacheLoaders are treated as CacheStores unless annotated with @CacheLoaderMetadata

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2059?page=com.atlassian.jira.plugin.... ] Mircea Markus resolved ISPN-2059. --------------------------------- Resolution: Out of Date no longer actual with the CacheWriter/CacheLoader hierarchy. > Custom CacheLoaders are treated as CacheStores unless annotated with @CacheLoaderMetadata > ----------------------------------------------------------------------------------------- > > Key: ISPN-2059 > URL: https://issues.jboss.org/browse/ISPN-2059 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 5.1.6.FINAL > Reporter: Sanne Grinovero > Assignee: Tristan Tarrant > Fix For: 6.0.0.Final > > > If the @CacheLoaderMetadata is missing, Infinispan will treat the CacheLoader as a CacheStore: if it's not implementing CacheStore as well the component will fail. > @CacheLoaderMetadata should be optional. -- 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-2016) Release script should push branch to origin after updating to version+1

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2016?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2016: -------------------------------- Fix Version/s: (was: 6.0.0.Final) > Release script should push branch to origin after updating to version+1 > ----------------------------------------------------------------------- > > Key: ISPN-2016 > URL: https://issues.jboss.org/browse/ISPN-2016 > Project: Infinispan > Issue Type: Bug > Components: Build process > Affects Versions: 5.1.4.FINAL > Reporter: NadirX > Assignee: Manik Surtani > Priority: Minor > -- 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 October 2013