[JBoss JIRA] (ISPN-6713) RemoteQueryDslConditionsTest.testIsNullNumericWithProjection1 fails
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-6713?page=com.atlassian.jira.plugin.... ]
Adrian Nistor commented on ISPN-6713:
-------------------------------------
The test failure is not longer reproducible with currently used lucene version.
> RemoteQueryDslConditionsTest.testIsNullNumericWithProjection1 fails
> -------------------------------------------------------------------
>
> Key: ISPN-6713
> URL: https://issues.jboss.org/browse/ISPN-6713
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Querying
> Affects Versions: 8.0.0.Final
> Reporter: Adrian Nistor
> Assignee: Adrian Nistor
> Fix For: 9.0.0.Final
>
>
> {code}
> java.lang.NumberFormatException: Invalid shift value in prefixCoded bytes (is encoded value really an INT?)
> at org.apache.lucene.util.NumericUtils.getPrefixCodedIntShift(NumericUtils.java:216)
> at org.apache.lucene.util.NumericUtils$2.accept(NumericUtils.java:504)
> at org.apache.lucene.index.FilteredTermsEnum.next(FilteredTermsEnum.java:232)
> at org.apache.lucene.uninverting.FieldCacheImpl$Uninvert.uninvert(FieldCacheImpl.java:285)
> at org.apache.lucene.uninverting.FieldCacheImpl$LongCache.createValue(FieldCacheImpl.java:552)
> at org.apache.lucene.uninverting.FieldCacheImpl$Cache.get(FieldCacheImpl.java:189)
> at org.apache.lucene.uninverting.FieldCacheImpl.getNumerics(FieldCacheImpl.java:469)
> at org.apache.lucene.uninverting.UninvertingReader.getNumericDocValues(UninvertingReader.java:233)
> at org.apache.lucene.index.DocValues.getNumeric(DocValues.java:225)
> at org.apache.lucene.search.FieldComparator$NumericComparator.getNumericDocValues(FieldComparator.java:167)
> at org.apache.lucene.search.FieldComparator$NumericComparator.doSetNextReader(FieldComparator.java:153)
> at org.apache.lucene.search.SimpleFieldComparator.getLeafComparator(SimpleFieldComparator.java:36)
> at org.apache.lucene.search.FieldValueHitQueue.getComparators(FieldValueHitQueue.java:183)
> at org.apache.lucene.search.TopFieldCollector$SimpleFieldCollector.getLeafCollector(TopFieldCollector.java:164)
> at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:812)
> at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:535)
> at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:523)
> at org.hibernate.search.query.engine.impl.LazyQueryState.search(LazyQueryState.java:103)
> at org.hibernate.search.query.engine.impl.QueryHits.updateTopDocs(QueryHits.java:241)
> at org.hibernate.search.query.engine.impl.QueryHits.<init>(QueryHits.java:136)
> at org.hibernate.search.query.engine.impl.QueryHits.<init>(QueryHits.java:105)
> at org.hibernate.search.query.engine.impl.LuceneHSQuery.getQueryHits(LuceneHSQuery.java:313)
> at org.hibernate.search.query.engine.impl.LuceneHSQuery.queryEntityInfos(LuceneHSQuery.java:143)
> at org.infinispan.query.impl.CacheQueryImpl.list(CacheQueryImpl.java:161)
> at org.infinispan.query.dsl.embedded.impl.EmbeddedLuceneQuery.listInternal(EmbeddedLuceneQuery.java:75)
> at org.infinispan.query.dsl.embedded.impl.EmbeddedLuceneQuery.list(EmbeddedLuceneQuery.java:69)
> at org.infinispan.query.remote.impl.QueryFacadeImpl.makeResponse(QueryFacadeImpl.java:87)
> at org.infinispan.query.remote.impl.QueryFacadeImpl.query(QueryFacadeImpl.java:64)
> at org.infinispan.server.hotrod.HotRodServer.query(HotRodServer.scala:78)
> at org.infinispan.server.hotrod.ContextHandler.realRead(ContextHandler.java:146)
> at org.infinispan.server.hotrod.ContextHandler.lambda$channelRead0$1(ContextHandler.java:56)
> 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:145)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (ISPN-7642) Administration console - remote sites are not displayed correctly on cache container page
by Roman Macor (JIRA)
[ https://issues.jboss.org/browse/ISPN-7642?page=com.atlassian.jira.plugin.... ]
Roman Macor commented on ISPN-7642:
-----------------------------------
[~vblagojevic] yes, but that's correct, it is displayed wrong on the cache container page. In this screenshot, memcached cache has only BRN site configured so that's the only site that should be displayed. However, on the cache container page, there are two sites BRN, NYC.
> Administration console - remote sites are not displayed correctly on cache container page
> -----------------------------------------------------------------------------------------
>
> Key: ISPN-7642
> URL: https://issues.jboss.org/browse/ISPN-7642
> Project: Infinispan
> Issue Type: Bug
> Components: JMX, reporting and management
> Affects Versions: 9.0.0.CR2
> Reporter: Roman Macor
> Attachments: Screenshot-cacheContainer.png, Screenshot-detail-cache.png
>
>
> Have 2 caches each configured with a different remote site.
> When you click on cache container, both remote sites are displayed on both cache cards. Clicking on a cache to see cache detail page shows correct remote site. Please see the attached screenshots.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (ISPN-7644) Administration console - loader tab allows to set invalid options
by Vladimir Blagojevic (JIRA)
[ https://issues.jboss.org/browse/ISPN-7644?page=com.atlassian.jira.plugin.... ]
Vladimir Blagojevic reassigned ISPN-7644:
-----------------------------------------
Assignee: Ryan Emerson
> Administration console - loader tab allows to set invalid options
> -----------------------------------------------------------------
>
> Key: ISPN-7644
> URL: https://issues.jboss.org/browse/ISPN-7644
> Project: Infinispan
> Issue Type: Bug
> Components: JMX, reporting and management
> Affects Versions: 9.0.0.CR2
> Reporter: Roman Macor
> Assignee: Ryan Emerson
>
> Click on cache container -> cache -> configuration -> loader tab
> Some options in loader type drop down such as "Async Cache loader" (but there might be more of them) result in following error, after cluster restart:
> ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 19) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "datagrid-infinispan"),
> ("cache-container" => "clustered"),
> ("configurations" => "CONFIGURATIONS"),
> ("distributed-cache-configuration" => "distributedCache")
> ]) - failure description: "DGISPN0102: org.infinispan.persistence.async.AsyncCacheLoader is not a valid cache store"
> Then there are valid options such as "Single File Store" which work if there is a corresponding cache store set up, in this case, File store. But if there isn't a cache store configured, the cache is no longer available after restart and configuration cannot be fixed from the console.
> I suggest we add a restriction when configuring cache loaders in the console which wouldn't allow the users to configure cache loader without having to configure appropriate cache store first.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (ISPN-7644) Administration console - loader tab allows to set invalid options
by Roman Macor (JIRA)
[ https://issues.jboss.org/browse/ISPN-7644?page=com.atlassian.jira.plugin.... ]
Roman Macor updated ISPN-7644:
------------------------------
Description:
Click on cache container -> cache -> configuration -> loader tab
Some options in loader type drop down such as "Async Cache loader" (but there might be more of them) result in following error, after cluster restart:
ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 19) WFLYCTL0013: Operation ("add") failed - address: ([
("subsystem" => "datagrid-infinispan"),
("cache-container" => "clustered"),
("configurations" => "CONFIGURATIONS"),
("distributed-cache-configuration" => "distributedCache")
]) - failure description: "DGISPN0102: org.infinispan.persistence.async.AsyncCacheLoader is not a valid cache store"
Then there are valid options such as "Single File Store" which work if there is a corresponding cache store set up, in this case, File store. But if there isn't a cache store configured, the cache is no longer available after restart and configuration cannot be fixed from the console.
I suggest we add a restriction when configuring cache loaders in the console which wouldn't allow the users to configure cache loader without having to configure appropriate cache store first.
was:
Click on cache container -> cache -> configuration -> loader tab
Some options in loader type drop down such as "Async Cache loader" (but there might be more of them) result in following error, after cluster restart:
ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 19) WFLYCTL0013: Operation ("add") failed - address: ([
("subsystem" => "datagrid-infinispan"),
("cache-container" => "clustered"),
("configurations" => "CONFIGURATIONS"),
("distributed-cache-configuration" => "distributedCache")
]) - failure description: "DGISPN0102: org.infinispan.persistence.async.AsyncCacheLoader is not a valid cache store"
Then there are valid options such as "Single File Store" which work if there is a corresponding cache store set up, in this case, File store. But if there isn't a cache store configured, the cache is no longer available after restart and configuration cannot be fixed from the console.
I suggest we add a restriction when configuring cache loaders in the console which wouldn't allow users to configure cache loader without having to configure appropriate cache store first.
> Administration console - loader tab allows to set invalid options
> -----------------------------------------------------------------
>
> Key: ISPN-7644
> URL: https://issues.jboss.org/browse/ISPN-7644
> Project: Infinispan
> Issue Type: Bug
> Components: JMX, reporting and management
> Affects Versions: 9.0.0.CR2
> Reporter: Roman Macor
>
> Click on cache container -> cache -> configuration -> loader tab
> Some options in loader type drop down such as "Async Cache loader" (but there might be more of them) result in following error, after cluster restart:
> ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 19) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "datagrid-infinispan"),
> ("cache-container" => "clustered"),
> ("configurations" => "CONFIGURATIONS"),
> ("distributed-cache-configuration" => "distributedCache")
> ]) - failure description: "DGISPN0102: org.infinispan.persistence.async.AsyncCacheLoader is not a valid cache store"
> Then there are valid options such as "Single File Store" which work if there is a corresponding cache store set up, in this case, File store. But if there isn't a cache store configured, the cache is no longer available after restart and configuration cannot be fixed from the console.
> I suggest we add a restriction when configuring cache loaders in the console which wouldn't allow the users to configure cache loader without having to configure appropriate cache store first.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (ISPN-7580) Use of marsheller is not consistent in all places
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-7580?page=com.atlassian.jira.plugin.... ]
Adrian Nistor commented on ISPN-7580:
-------------------------------------
Hi Ramesh,
I see what are you trying to achieve in those two git commits but cannot figure out the reason. SerializationContext is not supposed to be implemented by the user. I think I need to see the bigger picture of what is Teiid doing with ProtoStreamMarshaller.
Adrian
> Use of marsheller is not consistent in all places
> -------------------------------------------------
>
> Key: ISPN-7580
> URL: https://issues.jboss.org/browse/ISPN-7580
> Project: Infinispan
> Issue Type: Bug
> Components: Marshalling, Remote Querying
> Reporter: Ramesh Reddy
> Assignee: Adrian Nistor
>
> Usage of extended ProtoStreamMarshaller is not consistent across all the code paths. For the purposes of Teiid translator, I have extended ProtoStreamMarshaller which knows to read/write byte streams in portable fashion for given message type, which are representions of a relational table in Teiid. This works fine, if I just use cache's get/put calls.
> However, the same fails when used with RemoteQuery or Continuous query. The reason is, these classes circumvent extended Marsheller and go directly to serialization context registered to do the wrapping/unwrapping. Not only that there are few places code will type cast the SerializationContext to SerializationContextImpl object. Thus I can not even provide my own Serializer nor I can extend this as SerializationContextImpl is declared as final. These need to be corrected such that extended marsheller is used rather than hard coding them.
> I am guessing this is first time anyone has even done this without using dedicated java classes as marshellers.
> This is extremely critical for me to be fixed to move forward, I can provide the pull request for it?
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (ISPN-7644) Administration console - loader tab allows to set invalid options
by Roman Macor (JIRA)
Roman Macor created ISPN-7644:
---------------------------------
Summary: Administration console - loader tab allows to set invalid options
Key: ISPN-7644
URL: https://issues.jboss.org/browse/ISPN-7644
Project: Infinispan
Issue Type: Bug
Components: JMX, reporting and management
Affects Versions: 9.0.0.CR2
Reporter: Roman Macor
Click on cache container -> cache -> configuration -> loader tab
Some options in loader type drop down such as "Async Cache loader" (but there might be more of them) result in following error, after cluster restart:
ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 19) WFLYCTL0013: Operation ("add") failed - address: ([
("subsystem" => "datagrid-infinispan"),
("cache-container" => "clustered"),
("configurations" => "CONFIGURATIONS"),
("distributed-cache-configuration" => "distributedCache")
]) - failure description: "DGISPN0102: org.infinispan.persistence.async.AsyncCacheLoader is not a valid cache store"
Then there are valid options such as "Single File Store" which work if there is a corresponding cache store set up, in this case, File store. But if there isn't a cache store configured, the cache is no longer available after restart and configuration cannot be fixed from the console.
I suggest we add a restriction when configuring cache loaders in the console which wouldn't allow users to configure cache loader without having to configure appropriate cache store first.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (ISPN-7580) Use of marsheller is not consistent in all places
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-7580?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-7580:
--------------------------------
Status: Open (was: New)
> Use of marsheller is not consistent in all places
> -------------------------------------------------
>
> Key: ISPN-7580
> URL: https://issues.jboss.org/browse/ISPN-7580
> Project: Infinispan
> Issue Type: Bug
> Components: Marshalling, Remote Querying
> Reporter: Ramesh Reddy
> Assignee: Adrian Nistor
>
> Usage of extended ProtoStreamMarshaller is not consistent across all the code paths. For the purposes of Teiid translator, I have extended ProtoStreamMarshaller which knows to read/write byte streams in portable fashion for given message type, which are representions of a relational table in Teiid. This works fine, if I just use cache's get/put calls.
> However, the same fails when used with RemoteQuery or Continuous query. The reason is, these classes circumvent extended Marsheller and go directly to serialization context registered to do the wrapping/unwrapping. Not only that there are few places code will type cast the SerializationContext to SerializationContextImpl object. Thus I can not even provide my own Serializer nor I can extend this as SerializationContextImpl is declared as final. These need to be corrected such that extended marsheller is used rather than hard coding them.
> I am guessing this is first time anyone has even done this without using dedicated java classes as marshellers.
> This is extremely critical for me to be fixed to move forward, I can provide the pull request for it?
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years