June 2016 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-6794) Administration console - editing javascript task name doesn't work correctly

by Roman Macor (JIRA)

Roman Macor created ISPN-6794: --------------------------------- Summary: Administration console - editing javascript task name doesn't work correctly Key: ISPN-6794 URL: https://issues.jboss.org/browse/ISPN-6794 Project: Infinispan Issue Type: Bug Components: JMX, reporting and management Reporter: Roman Macor Editing javascript task name, doesn't change the name of the script. If we try to edit name the script can no longer be executed. Console error message when trying to run edited script: Error Some unexpected problem happened when launching the task: DGISPN0118: Failed to invoke operation: java.lang.NullPointerException Steps to reproduce: upload javascript - click on cache container -> Configuration -> Tasks -> Create new script - fill in the mandatory parameter (e.g. Task name: newTask, Language: javascript, Execution mode: local, script body: cache.put('key','value')) - click create script task button edit script - click on cache container -> Configuration -> Tasks -> Edit - change the name of the script - click update script Result: name remains the same and script can no longer be executed Note that other properties such as mode or script body can be edited in this way. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[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)

9 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)

9 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)

9 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)

9 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)

9 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)

9 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)

9 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)

9 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)

9 years, 6 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues June 2016