August 2015 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-5414) Support (named) parameters in DSL based queries

by Prashant Thakur (JIRA)

[ https://issues.jboss.org/browse/ISPN-5414?page=com.atlassian.jira.plugin.... ] Prashant Thakur edited comment on ISPN-5414 at 8/10/15 2:30 AM: ---------------------------------------------------------------- Thanks Adrian, We are presently implementing by keeping parsing result of antlr parser and storing it in Cache. Avoiding internals for AST Processor for now would give us easier way forward. Did some analysis around end to end speed after avoiding parsing we are able to achieve approx 4200 req/sec for 1 Million cache size which looks good for the moment. Our intention for now is not to make solution very generic which would be the final solution from your end but just to provide lookups from multiple keys stored in value part was (Author: prashant.thakur): Thanks Adrain, We are presently implementing by keeping parsing result of antlr parser and storing it in Cache. Avoiding internals for AST Processor for now would give us easier way forward. Did some analysis around end to end speed after avoiding parsing we are able to achieve approx 4200 req/sec for 1 Million cache size which looks good for the moment. Our intention for now is not to make solution very generic which would be the final solution from your end but just to provide lookups from multiple keys stored in value part > Support (named) parameters in DSL based queries > ----------------------------------------------- > > Key: ISPN-5414 > URL: https://issues.jboss.org/browse/ISPN-5414 > Project: Infinispan > Issue Type: Feature Request > Components: Remote Querying > Affects Versions: 8.0.0.Final > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 8.0.0.Final > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5414) Support (named) parameters in DSL based queries

by Prashant Thakur (JIRA)

[ https://issues.jboss.org/browse/ISPN-5414?page=com.atlassian.jira.plugin.... ] Prashant Thakur edited comment on ISPN-5414 at 8/10/15 1:39 AM: ---------------------------------------------------------------- Thanks Adrain, We are presently implementing by keeping parsing result of antlr parser and storing it in Cache. Avoiding internals for AST Processor for now would give us easier way forward. Did some analysis around end to end speed after avoiding parsing we are able to achieve approx 4200 req/sec for 1 Million cache size which looks good for the moment. Our intention for now is not to make solution very generic which would be the final solution from your end but just to provide lookups from multiple keys stored in value part was (Author: prashant.thakur): Thanks Adrain, We are presently implementing by keeping parsing result of antlr parser and storing it in Cache. Avoiding internals for AST Processor for now would give us easier way forward. Did some analysis around end to end speed after avoiding parsing we are able to achieve approx 4200 req/sec for 1 Million cache size which looks good for the moment. > Support (named) parameters in DSL based queries > ----------------------------------------------- > > Key: ISPN-5414 > URL: https://issues.jboss.org/browse/ISPN-5414 > Project: Infinispan > Issue Type: Feature Request > Components: Remote Querying > Affects Versions: 8.0.0.Final > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 8.0.0.Final > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5414) Support (named) parameters in DSL based queries

by Prashant Thakur (JIRA)

[ https://issues.jboss.org/browse/ISPN-5414?page=com.atlassian.jira.plugin.... ] Prashant Thakur commented on ISPN-5414: --------------------------------------- Thanks Adrain, We are presently implementing by keeping parsing result of antlr parser and storing it in Cache. Avoiding internals for AST Processor for now would give us easier way forward. Did some analysis around end to end speed after avoiding parsing we are able to achieve approx 4200 req/sec for 1 Million cache size which looks good for the moment. > Support (named) parameters in DSL based queries > ----------------------------------------------- > > Key: ISPN-5414 > URL: https://issues.jboss.org/browse/ISPN-5414 > Project: Infinispan > Issue Type: Feature Request > Components: Remote Querying > Affects Versions: 8.0.0.Final > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 8.0.0.Final > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5635) Upgrade server to WildFly 9.0.1.Final

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-5635?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-5635: ----------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 8.0.0.Beta3 (was: 8.0.0.CR1) Resolution: Done > Upgrade server to WildFly 9.0.1.Final > ------------------------------------- > > Key: ISPN-5635 > URL: https://issues.jboss.org/browse/ISPN-5635 > Project: Infinispan > Issue Type: Component Upgrade > Components: Server > Affects Versions: 8.0.0.Beta2 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 8.0.0.Beta3 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2849) Don't keep threads blocked when waiting for locks to be released

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-2849?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-2849: ------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 8.0.0.Beta3 (was: 8.0.0.CR1) Resolution: Done > Don't keep threads blocked when waiting for locks to be released > ---------------------------------------------------------------- > > Key: ISPN-2849 > URL: https://issues.jboss.org/browse/ISPN-2849 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Affects Versions: 6.0.0.CR1 > Reporter: Mircea Markus > Assignee: Pedro Ruivo > Fix For: 8.0.0.Beta3 > > > ATM if a tx2 waits on a lock to be released by tx1, the (incoming) tx2 thread is BLOCKED and taken out from the pool. A better way to implement this is by using a structure that would hold and order the depending transactions on the receiver correlated with the async execution API from JGroups 3.3.0, result being that tx2 would not BLOCK but return to the pool this (not maxing out the thread pool that executes commands). > More about it in the "Async invocation section" of https://docspace.corp.redhat.com/docs/DOC-134411 -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5596) "Cannot clear data directory" in SoftIndexFileStore when clear() is called after stopping and restarting cache

by Andreas Pabst (JIRA)

[ https://issues.jboss.org/browse/ISPN-5596?page=com.atlassian.jira.plugin.... ] Andreas Pabst commented on ISPN-5596: ------------------------------------- Good news. Now there are a bunch of file system exceptions about the file being in use by another process, but eventually the delete goes through. JDK is 1.8.0_20 32 Bit > "Cannot clear data directory" in SoftIndexFileStore when clear() is called after stopping and restarting cache > -------------------------------------------------------------------------------------------------------------- > > Key: ISPN-5596 > URL: https://issues.jboss.org/browse/ISPN-5596 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 7.2.3.Final > Environment: Windows 7 > Reporter: Andreas Pabst > Assignee: Radim Vansa > Attachments: SoftIndexFileStoreTest.java, test.log, test2.log, test3.log > > > When stopping and restarting a cache with SoftIndexFileStore persistence, it behaves strangely. > Calling cache.clear() leads to the following exception: > ERROR: ISPN000136: Execution error > org.infinispan.persistence.spi.PersistenceException: Cannot clear data directory! > at org.infinispan.persistence.sifs.SoftIndexFileStore.clear(SoftIndexFileStore.java:234) > at org.infinispan.persistence.manager.PersistenceManagerImpl.clearAllStores(PersistenceManagerImpl.java:372) > at org.infinispan.interceptors.CacheWriterInterceptor.visitClearCommand(CacheWriterInterceptor.java:158) > ... > Caused by: java.io.IOException: Cannot delete file soft-index-test\data\2 > at org.infinispan.persistence.sifs.FileProvider.clear(FileProvider.java:205) > at org.infinispan.persistence.sifs.SoftIndexFileStore.clear(SoftIndexFileStore.java:232) > If the manager is also stopped and recreated every time, this only happens after the third iteration. > Calling cache.remove() in the same place leads to an unrecoverable corruption of the cache store files: java.lang.IllegalArgumentException: Negative position -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5596) "Cannot clear data directory" in SoftIndexFileStore when clear() is called after stopping and restarting cache

by Andreas Pabst (JIRA)

[ https://issues.jboss.org/browse/ISPN-5596?page=com.atlassian.jira.plugin.... ] Andreas Pabst updated ISPN-5596: -------------------------------- Attachment: test3.log Added test case output with "more attempts to delete" commit > "Cannot clear data directory" in SoftIndexFileStore when clear() is called after stopping and restarting cache > -------------------------------------------------------------------------------------------------------------- > > Key: ISPN-5596 > URL: https://issues.jboss.org/browse/ISPN-5596 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 7.2.3.Final > Environment: Windows 7 > Reporter: Andreas Pabst > Assignee: Radim Vansa > Attachments: SoftIndexFileStoreTest.java, test.log, test2.log, test3.log > > > When stopping and restarting a cache with SoftIndexFileStore persistence, it behaves strangely. > Calling cache.clear() leads to the following exception: > ERROR: ISPN000136: Execution error > org.infinispan.persistence.spi.PersistenceException: Cannot clear data directory! > at org.infinispan.persistence.sifs.SoftIndexFileStore.clear(SoftIndexFileStore.java:234) > at org.infinispan.persistence.manager.PersistenceManagerImpl.clearAllStores(PersistenceManagerImpl.java:372) > at org.infinispan.interceptors.CacheWriterInterceptor.visitClearCommand(CacheWriterInterceptor.java:158) > ... > Caused by: java.io.IOException: Cannot delete file soft-index-test\data\2 > at org.infinispan.persistence.sifs.FileProvider.clear(FileProvider.java:205) > at org.infinispan.persistence.sifs.SoftIndexFileStore.clear(SoftIndexFileStore.java:232) > If the manager is also stopped and recreated every time, this only happens after the third iteration. > Calling cache.remove() in the same place leads to an unrecoverable corruption of the cache store files: java.lang.IllegalArgumentException: Negative position -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5650) NPE when trying to execute script from Hot Rod client

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5650?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5650: ---------------------------------- Fix Version/s: 7.2.4.Final > NPE when trying to execute script from Hot Rod client > ----------------------------------------------------- > > Key: ISPN-5650 > URL: https://issues.jboss.org/browse/ISPN-5650 > Project: Infinispan > Issue Type: Bug > Components: Server > Affects Versions: 7.2.3.Final, 8.0.0.Beta2 > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Fix For: 8.0.0.Beta3, 7.2.4.Final, 8.0.0.Final > > > {code} > String SCRIPT_CACHE = "___script_cache"; > RemoteCacheManager remoteCacheManager = ... > RemoteCache<String, String> scriptCache = remoteCacheManager.getCache(SCRIPT_CACHE); > scriptCache.put("wordCountMapper.js", ...); > {code} > throws: > {code} > 14:34:21,473 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (HotRodServerWorker-8-1) ISPN000136: Execution error: java.lang.NullPointerException > at org.infinispan.interceptors.compat.BaseTypeConverterInterceptor.visitPutKeyValueCommand(BaseTypeConverterInterceptor.java:85) > at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:72) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99) > at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:102) > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5558) DistributedTaskPart.equals() implementation is wrong

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5558?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5558: ----------------------------------------------- Matej Čimbora <mcimbora(a)redhat.com> changed the Status of [bug 1250033|https://bugzilla.redhat.com/show_bug.cgi?id=1250033] from ON_QA to VERIFIED > DistributedTaskPart.equals() implementation is wrong > ---------------------------------------------------- > > Key: ISPN-5558 > URL: https://issues.jboss.org/browse/ISPN-5558 > Project: Infinispan > Issue Type: Bug > Components: Core, Distributed Execution and Map/Reduce > Affects Versions: 7.2.2.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 8.0.0.Beta1, 7.2.4.Final, 8.0.0.Final > > > {{DistributedExecutorService.submitEverywhere()}} returns a list of futures, one future for each targeted node. Because of how {{DistributedTaskPart.equals()}} is implemented, all the futures in the list appear to be equal, even though their target node is different and their result will also be different. > The simplest fix would be to remove the equals() and hashCode() overloads from {{DistributedTaskPart}}. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5414) Support (named) parameters in DSL based queries

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-5414?page=com.atlassian.jira.plugin.... ] Adrian Nistor commented on ISPN-5414: ------------------------------------- The pull request is linked in the 'Git Pull Request' field of the jira. The PR adds the named params feature but does not add a noticeable performance improvement because it currently cannot avoid re-parsing but due to a limitation in the HQL parser's way of supporting params. The HQL parser translates the HQL query into a lucene query and during this phase it also injects the current values of the parameters into the resulting lucene query. Lucene queries are immutable. So running a query with different param values requires re-parsing and re-translation. I'm trying to enhance the HQL parser to remove this limitation until the 8.0 final release but cannot promise it will happen. Worst case scenario, we'll have support for named params now but without a performance benefit in 8.0, hoping to solve that in 8.1. or 8.2. > Support (named) parameters in DSL based queries > ----------------------------------------------- > > Key: ISPN-5414 > URL: https://issues.jboss.org/browse/ISPN-5414 > Project: Infinispan > Issue Type: Feature Request > Components: Remote Querying > Affects Versions: 8.0.0.Final > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 8.0.0.Final > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 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 August 2015