[JBoss JIRA] (ISPN-7714) Deploy Lucene analyzers in server for remote query
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-7714?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes updated ISPN-7714:
------------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 9.2.0.Beta1
Resolution: Done
> Deploy Lucene analyzers in server for remote query
> --------------------------------------------------
>
> Key: ISPN-7714
> URL: https://issues.jboss.org/browse/ISPN-7714
> Project: Infinispan
> Issue Type: Enhancement
> Components: Remote Querying
> Reporter: Adrian Nistor
> Assignee: Adrian Nistor
> Fix For: 9.2.0.Beta1, 9.2.0.Final
>
>
> Current integration tests demonstrate remote query with user deployed analyzers but the hot rod server is started in a special way that is used only for testing. Deployment of analyzers seems to work but with a real server it does not.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 5 months
[JBoss JIRA] (ISPN-8344) DSL queries filtering only on type are always executed without index
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-8344?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-8344:
--------------------------------
Fix Version/s: 9.1.3.Final
(was: 9.1.2.Final)
> DSL queries filtering only on type are always executed without index
> --------------------------------------------------------------------
>
> Key: ISPN-8344
> URL: https://issues.jboss.org/browse/ISPN-8344
> Project: Infinispan
> Issue Type: Bug
> Components: Embedded Querying, Remote Querying
> Affects Versions: 9.0.0.Final
> Reporter: Adrian Nistor
> Assignee: Adrian Nistor
> Fix For: 9.0.4.Final, 8.2.9.Final, 9.2.0.Beta1, 9.1.3.Final
>
>
> This happens if the WHERE clause is empty or a tautology (true). In this case the query is wrongly executed unindexed even though the index should be at least used for filtering on type.
> The query
> {code}
> FROM org.infinispan.test.Person
> {code}
> or
> {code}
> qf.from(Person.class).build();
> {code}
> is such a case
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 5 months
[JBoss JIRA] (ISPN-8220) ClusteredCacheMgmtInterceptorMBeanTest fails intermittently
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-8220?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-8220:
--------------------------------
Fix Version/s: 9.1.3.Final
(was: 9.1.2.Final)
> ClusteredCacheMgmtInterceptorMBeanTest fails intermittently
> -----------------------------------------------------------
>
> Key: ISPN-8220
> URL: https://issues.jboss.org/browse/ISPN-8220
> Project: Infinispan
> Issue Type: Bug
> Components: JMX, reporting and management, Test Suite - Core
> Affects Versions: 9.1.0.Final
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Labels: testsuite_stability
> Fix For: 9.1.3.Final
>
>
> {code:java}
> org.infinispan.util.concurrent.TimeoutException: Timed out waiting for topology 6
> at org.infinispan.interceptors.impl.AsyncInterceptorChainImpl.invoke(AsyncInterceptorChainImpl.java:259)
> at org.infinispan.cache.impl.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1679)
> at org.infinispan.cache.impl.CacheImpl.put(CacheImpl.java:1327)
> at org.infinispan.cache.impl.CacheImpl.put(CacheImpl.java:1793)
> at org.infinispan.cache.impl.CacheImpl.put(CacheImpl.java:282)
> at org.infinispan.cache.impl.AbstractDelegatingCache.put(AbstractDelegatingCache.java:358)
> at org.infinispan.cache.impl.EncoderCache.put(EncoderCache.java:655)
> at org.infinispan.jmx.ClusteredCacheMgmtInterceptorMBeanTest.testCorrectStatsInCluster(ClusteredCacheMgmtInterceptorMBeanTest.java:48)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: org.infinispan.util.concurrent.TimeoutException: Timed out waiting for topology 6
> at org.infinispan.interceptors.impl.BaseStateTransferInterceptor$CancellableRetry.run(BaseStateTransferInterceptor.java:347)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> ... 3 more
> ... Removed 16 stack frames
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 5 months
[JBoss JIRA] (ISPN-8217) RestStoreTest.tearDown intermittent failure
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-8217?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-8217:
--------------------------------
Fix Version/s: 9.1.3.Final
(was: 9.1.2.Final)
> RestStoreTest.tearDown intermittent failure
> -------------------------------------------
>
> Key: ISPN-8217
> URL: https://issues.jboss.org/browse/ISPN-8217
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 9.1.0.Final
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Fix For: 9.1.3.Final
>
>
> The test fails intermittently with the following:
> {code:java}
> io.netty.channel.ChannelException: eventfd_write() failed: Bad file descriptor
> at io.netty.channel.epoll.Native.eventFdWrite(Native Method)
> at io.netty.channel.epoll.EpollEventLoop.wakeup(EpollEventLoop.java:126)
> at io.netty.util.concurrent.SingleThreadEventExecutor.shutdownGracefully(SingleThreadEventExecutor.java:589)
> at io.netty.util.concurrent.MultithreadEventExecutorGroup.shutdownGracefully(MultithreadEventExecutorGroup.java:163)
> at org.infinispan.server.core.transport.NettyTransport.stop(NettyTransport.java:161)
> at org.infinispan.server.core.AbstractProtocolServer.stop(AbstractProtocolServer.java:144)
> at org.infinispan.persistence.rest.RestStoreTest.tearDown(RestStoreTest.java:73)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> ... Removed 18 stack frames
>
> {code}
> I believe this is caused by Netty not closing connections properly. See [here|http://netty.io/news/2017/07/06/4-0-49-Final-4-1-13-Final.html]. Upgrading Netty to the latest version should hopefully resolve this issue.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 5 months
[JBoss JIRA] (ISPN-8379) Support configuration wildcards
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-8379?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-8379:
--------------------------------
Fix Version/s: 9.2.0.Alpha2
> Support configuration wildcards
> -------------------------------
>
> Key: ISPN-8379
> URL: https://issues.jboss.org/browse/ISPN-8379
> Project: Infinispan
> Issue Type: Enhancement
> Components: Configuration
> Reporter: Tristan Tarrant
> Assignee: Tristan Tarrant
> Fix For: 9.2.0.Alpha2, 9.2.0.Final
>
>
> Allow defining configuration names containing wildcards so that they are implicitly used for caches whose names match. This would be particularly useful for using templates with JCache which doesn't allow specifying additional configuration properties outside what is available in MutableConfiguration.
> Therefore, declaring a cache configuration such as:
> {code:xml}
> <invalidation-cache-configuration name="invalidation-*" />
> {code}
> and invoking:
> {code:java}
> cacheManager.getCache("invalidation-1");
> {code}
> would use the above configuration
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 5 months
[JBoss JIRA] (ISPN-8445) Off-heap container doesn't work in compatibility mode
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-8445?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes commented on ISPN-8445:
-----------------------------------------
Thanks [~vjuranek].
Before starting to throw and error though, I need to check if it's possible to interop between Rest and Hot Rod under OFF_HEAP without compat mode, using different marshaller in the HR client. I know that it works for the UTF8String marshaller, need to check for others.
> Off-heap container doesn't work in compatibility mode
> -----------------------------------------------------
>
> Key: ISPN-8445
> URL: https://issues.jboss.org/browse/ISPN-8445
> Project: Infinispan
> Issue Type: Bug
> Components: Off Heap
> Affects Versions: 9.2.0.Alpha1
> Reporter: Vojtech Juranek
>
> When cache uses off-heap container and has compatibility mode turned on, it's not able to convert keys/value into proper type and fails with (when accessed via hotrod or rest)
> {noformat}
> ESC[0mESC[31m14:27:46,383 ERROR [org.infinispan.interceptors.impl.InvocationContextInterceptor] (HotRod-ServerHandler-6-1) ISPN000136: Error executing command PutKeyValueCommand, writing keys [key1]: java.lang.ClassCastException: java.la
> ng.String cannot be cast to org.infinispan.commons.marshall.WrappedBytes
> at org.infinispan.container.offheap.OffHeapDataContainer.put(OffHeapDataContainer.java:39)
> at org.infinispan.container.entries.ReadCommittedEntry.commit(ReadCommittedEntry.java:134)
> at org.infinispan.statetransfer.CommitManager.commitEntry(CommitManager.java:141)
> at org.infinispan.statetransfer.CommitManager.commit(CommitManager.java:101)
> at org.infinispan.interceptors.locking.ClusteringDependentLogic$LocalLogic.commitSingleEntry(ClusteringDependentLogic.java:329)
> at org.infinispan.interceptors.locking.ClusteringDependentLogic$AbstractClusteringDependentLogic.commitEntry(ClusteringDependentLogic.java:183)
> at org.infinispan.interceptors.impl.EntryWrappingInterceptor.commitContextEntry(EntryWrappingInterceptor.java:585)
> at org.infinispan.interceptors.impl.EntryWrappingInterceptor.commitEntryIfNeeded(EntryWrappingInterceptor.java:808)
> at org.infinispan.interceptors.impl.EntryWrappingInterceptor.commitContextEntries(EntryWrappingInterceptor.java:562)
> at org.infinispan.interceptors.impl.EntryWrappingInterceptor.applyChanges(EntryWrappingInterceptor.java:618)
> at org.infinispan.interceptors.impl.EntryWrappingInterceptor.lambda$setSkipRemoteGetsAndInvokeNextForDataCommand$7(EntryWrappingInterceptor.java:674)
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextThenAccept(BaseAsyncInterceptor.java:109)
> at org.infinispan.interceptors.impl.EntryWrappingInterceptor.setSkipRemoteGetsAndInvokeNextForDataCommand(EntryWrappingInterceptor.java:671)
> at org.infinispan.interceptors.impl.EntryWrappingInterceptor.visitPutKeyValueCommand(EntryWrappingInterceptor.java:316)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:67)
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextAndFinally(BaseAsyncInterceptor.java:154)
> at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitNonTxDataWriteCommand(AbstractLockingInterceptor.java:135)
> at org.infinispan.interceptors.locking.NonTransactionalLockingInterceptor.visitDataWriteCommand(NonTransactionalLockingInterceptor.java:38)
> at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitPutKeyValueCommand(AbstractLockingInterceptor.java:85)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:67)
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextAndFinally(BaseAsyncInterceptor.java:154)
> at org.infinispan.interceptors.impl.CacheMgmtInterceptor.updateStoreStatistics(CacheMgmtInterceptor.java:200)
> at org.infinispan.interceptors.impl.CacheMgmtInterceptor.visitPutKeyValueCommand(CacheMgmtInterceptor.java:162)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:67)
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:58)
> at org.infinispan.interceptors.DDAsyncInterceptor.handleDefault(DDAsyncInterceptor.java:54)
> at org.infinispan.interceptors.DDAsyncInterceptor.visitPutKeyValueCommand(DDAsyncInterceptor.java:60)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:67)
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextAndExceptionally(BaseAsyncInterceptor.java:127)
> at org.infinispan.interceptors.impl.InvocationContextInterceptor.visitCommand(InvocationContextInterceptor.java:96)
> at org.infinispan.interceptors.impl.AsyncInterceptorChainImpl.invoke(AsyncInterceptorChainImpl.java:248)
> at org.infinispan.cache.impl.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1674)
> at org.infinispan.cache.impl.CacheImpl.put(CacheImpl.java:1322)
> at org.infinispan.cache.impl.CacheImpl.put(CacheImpl.java:1788)
> at org.infinispan.cache.impl.AbstractDelegatingAdvancedCache.put(AbstractDelegatingAdvancedCache.java:318)
> at org.infinispan.cache.impl.EncoderCache.put(EncoderCache.java:439)
> at org.infinispan.cache.impl.AbstractDelegatingAdvancedCache.put(AbstractDelegatingAdvancedCache.java:318)
> at org.infinispan.server.hotrod.CacheDecodeContext.put(CacheDecodeContext.java:404)
> at org.infinispan.server.hotrod.ContextHandler.realRead(ContextHandler.java:65)
> at org.infinispan.server.hotrod.ContextHandler.lambda$channelRead0$0(ContextHandler.java:52)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:144)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 5 months