June 2016 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-6793) Document indexless query feature

by Gustavo Fernandes (JIRA)

Gustavo Fernandes created ISPN-6793: --------------------------------------- Summary: Document indexless query feature Key: ISPN-6793 URL: https://issues.jboss.org/browse/ISPN-6793 Project: Infinispan Issue Type: Task Components: Documentation-Query Reporter: Gustavo Fernandes Explain the pros/cons and compare with indexed queries configuration wise -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3664) Improve write command processing

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3664?page=com.atlassian.jira.plugin.... ] Pedro Ruivo commented on ISPN-3664: ----------------------------------- no. > Improve write command processing > -------------------------------- > > Key: ISPN-3664 > URL: https://issues.jboss.org/browse/ISPN-3664 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 6.0.0.CR1 > Reporter: Pedro Ruivo > Assignee: Dan Berindei > > Major refactorization of the write command with the following goals: > -> Base WriteCommand: all the write command has the same workflow through the interceptor chain > -> Create a concrete WriteCommand for each operation (put, remove, replace, replaceIfEquals, removeIfEquals, putIfAbsent) > -> Extend the interceptor chain to process each one of the command and add a new "visitWriteCommand", that is invoked by the default visitX methods. > -> (minor) change the GetKeyValueCommand to ReadCommand to make name "compatible" with WriteCommand. > Note that most of the interceptor only needs to implement the visitWriteCommand because all the write command has the same execution flow. The basic flow of the write commands are: (non-tx) lock, fetch value (cachestore/remote), check condition and apply change. for tx mode, lock (if pessimistic), fetch value (cache loader, remote, etc), apply change and add it to the transaction (if successful) > Also, another advantage is the simplification of the EntryFactory because if we think a little about it, independent of the write command we need to wrap the entry anyway. > Suggested implementation > {code:java} > class abstract WriteCommand > Object key, Object newValue > boolen match(Object currentValue) //true by default > boolean needsRemoteGetBeforeWrite() //true by default > object perform() //common implementation like: if (match(entry.getValue()) then entry.setValue(newValue); entry.setChanged(true); entry.setRemoved(newValue == null)} > {code} > * Concrete implementations* > {code:java} > {PutCommand|RemoveCommand} extends WriteCommand > ovewrite needsRemoteGetBeforeWrite() {return !flags.contains(IGNORE_RETURN_VALUE)} > ReplaceIfPresentCommand extends WriteCommand > ovewrite match(Object currentValue) {return currentValue != null} > PutIfAbsentCommand extends WriteCommand > ovewrite match(Object currentValue) {return currentValue == null} > {code} > * Special base class for operation with expected value to compare* > {code:java} > class abstract AdvancedWriteCommand extends WriteCommand > Object expectedValue > match(Object currentValue) {return currentValue.equals(expectedValue)} > {RemoveIfEquals|ReplaceIfEquals} extends AdvancedWriteCommand //no different implementation needed. > {code} > ps: I'm going to open the discussion in the dev mailing list... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6484) MarshallableTypeHints.getBufferSizePredictor(Class) is very hot

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/ISPN-6484?page=com.atlassian.jira.plugin.... ] Sanne Grinovero commented on ISPN-6484: --------------------------------------- Note: in the description I suggested the option of using a special purpose data structure. The reason is that I created a Map-like implementation for Hibernate ORM which is optimised for very fast lookups. It's definitely not a general-purpose Map implementation but it might fit this use case well too. Generally: - it needs to use {{Class}} as a key - it's extremely non-efficient at writes (only a good coice if it's very hot at reads but writes are part of the "setup") - it's meant for small collections, i.e. design was intended for less than 32 elements.. could work fine with some ~512 I guess but that's not tested.. See {{org.hibernate.service.internal.ConcurrentServiceBinding}}. I'd also experiment the effects of using a "no-op" predictor to see if it's all worth it. > MarshallableTypeHints.getBufferSizePredictor(Class) is very hot > --------------------------------------------------------------- > > Key: ISPN-6484 > URL: https://issues.jboss.org/browse/ISPN-6484 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Reporter: Sanne Grinovero > Assignee: Galder Zamarreño > Labels: performance > > This method is very hot, especially on its usage of ConcurrentMap#get > Seems worth to try: > * minimise using this service > * tune the map > * use a special purpose data structure -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6484) MarshallableTypeHints.getBufferSizePredictor(Class) is very hot

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/ISPN-6484?page=com.atlassian.jira.plugin.... ] Sanne Grinovero edited comment on ISPN-6484 at 6/20/16 5:20 AM: ---------------------------------------------------------------- Note: in the description I suggested the option of using a special purpose data structure. The reason is that I created a Map-like implementation for Hibernate ORM which is optimised for very fast lookups. It's definitely not a general-purpose Map implementation but it might fit this use case well too. Generally: - it needs to use {{Class}} as a key - it's extremely non-efficient at writes (only a good choice if it's very hot at reads but writes are part of the "setup") - it's meant for small collections, i.e. design was intended for less than 32 elements.. could work fine with some ~512 I guess but that's not tested.. See {{org.hibernate.service.internal.ConcurrentServiceBinding}}. I'd also experiment the effects of using a "no-op" predictor to see if it's all worth it. was (Author: sannegrinovero): Note: in the description I suggested the option of using a special purpose data structure. The reason is that I created a Map-like implementation for Hibernate ORM which is optimised for very fast lookups. It's definitely not a general-purpose Map implementation but it might fit this use case well too. Generally: - it needs to use {{Class}} as a key - it's extremely non-efficient at writes (only a good coice if it's very hot at reads but writes are part of the "setup") - it's meant for small collections, i.e. design was intended for less than 32 elements.. could work fine with some ~512 I guess but that's not tested.. See {{org.hibernate.service.internal.ConcurrentServiceBinding}}. I'd also experiment the effects of using a "no-op" predictor to see if it's all worth it. > MarshallableTypeHints.getBufferSizePredictor(Class) is very hot > --------------------------------------------------------------- > > Key: ISPN-6484 > URL: https://issues.jboss.org/browse/ISPN-6484 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Reporter: Sanne Grinovero > Assignee: Galder Zamarreño > Labels: performance > > This method is very hot, especially on its usage of ConcurrentMap#get > Seems worth to try: > * minimise using this service > * tune the map > * use a special purpose data structure -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3664) Improve write command processing

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-3664?page=com.atlassian.jira.plugin.... ] Radim Vansa commented on ISPN-3664: ----------------------------------- [~pruivo] I assume this is done? > Improve write command processing > -------------------------------- > > Key: ISPN-3664 > URL: https://issues.jboss.org/browse/ISPN-3664 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 6.0.0.CR1 > Reporter: Pedro Ruivo > Assignee: Dan Berindei > > Major refactorization of the write command with the following goals: > -> Base WriteCommand: all the write command has the same workflow through the interceptor chain > -> Create a concrete WriteCommand for each operation (put, remove, replace, replaceIfEquals, removeIfEquals, putIfAbsent) > -> Extend the interceptor chain to process each one of the command and add a new "visitWriteCommand", that is invoked by the default visitX methods. > -> (minor) change the GetKeyValueCommand to ReadCommand to make name "compatible" with WriteCommand. > Note that most of the interceptor only needs to implement the visitWriteCommand because all the write command has the same execution flow. The basic flow of the write commands are: (non-tx) lock, fetch value (cachestore/remote), check condition and apply change. for tx mode, lock (if pessimistic), fetch value (cache loader, remote, etc), apply change and add it to the transaction (if successful) > Also, another advantage is the simplification of the EntryFactory because if we think a little about it, independent of the write command we need to wrap the entry anyway. > Suggested implementation > {code:java} > class abstract WriteCommand > Object key, Object newValue > boolen match(Object currentValue) //true by default > boolean needsRemoteGetBeforeWrite() //true by default > object perform() //common implementation like: if (match(entry.getValue()) then entry.setValue(newValue); entry.setChanged(true); entry.setRemoved(newValue == null)} > {code} > * Concrete implementations* > {code:java} > {PutCommand|RemoveCommand} extends WriteCommand > ovewrite needsRemoteGetBeforeWrite() {return !flags.contains(IGNORE_RETURN_VALUE)} > ReplaceIfPresentCommand extends WriteCommand > ovewrite match(Object currentValue) {return currentValue != null} > PutIfAbsentCommand extends WriteCommand > ovewrite match(Object currentValue) {return currentValue == null} > {code} > * Special base class for operation with expected value to compare* > {code:java} > class abstract AdvancedWriteCommand extends WriteCommand > Object expectedValue > match(Object currentValue) {return currentValue.equals(expectedValue)} > {RemoveIfEquals|ReplaceIfEquals} extends AdvancedWriteCommand //no different implementation needed. > {code} > ps: I'm going to open the discussion in the dev mailing list... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3690) Lower allocation cost of instances of org.infinispan.commands.read.GetKeyValueCommand

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-3690?page=com.atlassian.jira.plugin.... ] Radim Vansa updated ISPN-3690: ------------------------------ Labels: performance (was: ) > Lower allocation cost of instances of org.infinispan.commands.read.GetKeyValueCommand > ------------------------------------------------------------------------------------- > > Key: ISPN-3690 > URL: https://issues.jboss.org/browse/ISPN-3690 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Reporter: Sanne Grinovero > Priority: Minor > Labels: performance > > Classes of type {code}org.infinispan.commands.read.GetKeyValueCommand{code} have an high cost in terms of memory allocation. > Would be great if we could reduce the runtime cost: in an app server test of just 25 minutes - which is stressing way more systems than just Infinispan - just the occasional get operations 43GB of memory accumulated over time. > This is a high cost on the TLABs, skewing various other values, among others making the default GC options unsuitable. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3901) Drop AtomicMap (and FineGrainedAtomicMap)

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-3901?page=com.atlassian.jira.plugin.... ] Radim Vansa commented on ISPN-3901: ----------------------------------- Deprecate in 9.0? > Drop AtomicMap (and FineGrainedAtomicMap) > ----------------------------------------- > > Key: ISPN-3901 > URL: https://issues.jboss.org/browse/ISPN-3901 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Reporter: Galder Zamarreño > Labels: atomic_map, grouping > > * Paul not using it any more for AS/Wildfly > * Atomic Maps lose data and don’t work well with replication queue > * Instead, Paul using Grouping API now > * [~sannegrinovero] and OGM, do you still need atomic maps? Could grouping API be used instead? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3905) Murmurhash3 implementation is slow on String keys

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-3905?page=com.atlassian.jira.plugin.... ] Radim Vansa updated ISPN-3905: ------------------------------ Labels: performance (was: ) > Murmurhash3 implementation is slow on String keys > ------------------------------------------------- > > Key: ISPN-3905 > URL: https://issues.jboss.org/browse/ISPN-3905 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 6.0.0.Final, 6.0.1.Final > Reporter: Sanne Grinovero > Assignee: Dan Berindei > Priority: Minor > Labels: performance > > String instances are a common choice for being used as key entries, still the getBytes() operation being performed allocates costly buffers, and the computation to get those bytes looks like expensive too. > I suspect there might be good reasons for not using the String's own hashcode directly as an input to Murmurhash? Still that's what other implementations seem to do. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4281) Refactor DistributedEntryRetriever segment retry logic to a service implementation to be reused

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-4281?page=com.atlassian.jira.plugin.... ] Radim Vansa commented on ISPN-4281: ----------------------------------- [~william.burns] out of date? > Refactor DistributedEntryRetriever segment retry logic to a service implementation to be reused > ----------------------------------------------------------------------------------------------- > > Key: ISPN-4281 > URL: https://issues.jboss.org/browse/ISPN-4281 > Project: Infinispan > Issue Type: Enhancement > Reporter: William Burns > > The DistributedEntryRetriever has a lot of logic for retrying segments to allow for a rehash to not produce duplicate entries. We should refactor this out so it is more of a utility so that any given DistributedCallable for example can be used instead. Also we should have a pluggable request policy to allow for parallel requests. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6483) CacheRpcCommandExternalizer frequently performs lookups from GlobalComponentRegistry

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-6483?page=com.atlassian.jira.plugin.... ] Radim Vansa updated ISPN-6483: ------------------------------ Labels: performance (was: ) > CacheRpcCommandExternalizer frequently performs lookups from GlobalComponentRegistry > ------------------------------------------------------------------------------------ > > Key: ISPN-6483 > URL: https://issues.jboss.org/browse/ISPN-6483 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Reporter: Sanne Grinovero > Labels: performance > > This is a significant CPU consumer; talking with Dan and Galder it looks like the reasons for the design might have changed and this could be simplified. > {noformat} > org.infinispan.factories.GlobalComponentRegistry.getNamedComponentRegistry(String) > org.infinispan.marshall.exts.CacheRpcCommandExternalizer.getCacheMarshaller(String) > org.infinispan.marshall.exts.CacheRpcCommandExternalizer.writeObject(ObjectOutput, CacheRpcCommand) > org.infinispan.marshall.exts.CacheRpcCommandExternalizer.readObject(ObjectInput) > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues June 2016