[JBoss JIRA] (ISPN-5111) [CLI] HELP of container command should be changed
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-5111?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-5111:
-----------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 7.1.0.CR1
Resolution: Done
> [CLI] HELP of container command should be changed
> -------------------------------------------------
>
> Key: ISPN-5111
> URL: https://issues.jboss.org/browse/ISPN-5111
> Project: Infinispan
> Issue Type: Bug
> Components: CLI
> Affects Versions: 7.1.0.Alpha1
> Reporter: Vitalii Chepeliuk
> Assignee: Vitalii Chepeliuk
> Priority: Minor
> Fix For: 7.1.0.CR1
>
>
> CONTAINER COMMAND---------------------------------------------------------------
> SYNOPSIS
> container [containername]
>
> DESCRIPTION
> Shows the available containers or selects a container to be used as default for CLI operations
>
> ARGUMENTS
> <<cachename>> !!! should be "containername"
> (optional) the name of the container to set as default for the following operations
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (ISPN-5111) [CLI] HELP of container command should be changed
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-5111?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-5111:
-----------------------------------
Status: Open (was: New)
> [CLI] HELP of container command should be changed
> -------------------------------------------------
>
> Key: ISPN-5111
> URL: https://issues.jboss.org/browse/ISPN-5111
> Project: Infinispan
> Issue Type: Bug
> Components: CLI
> Affects Versions: 7.1.0.Alpha1
> Reporter: Vitalii Chepeliuk
> Assignee: Vitalii Chepeliuk
> Priority: Minor
>
> CONTAINER COMMAND---------------------------------------------------------------
> SYNOPSIS
> container [containername]
>
> DESCRIPTION
> Shows the available containers or selects a container to be used as default for CLI operations
>
> ARGUMENTS
> <<cachename>> !!! should be "containername"
> (optional) the name of the container to set as default for the following operations
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (ISPN-5149) Nested field is reported as non-indexed when using protobuf annotations
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-5149?page=com.atlassian.jira.plugin.... ]
Adrian Nistor reassigned ISPN-5149:
-----------------------------------
Assignee: Adrian Nistor
> Nested field is reported as non-indexed when using protobuf annotations
> -----------------------------------------------------------------------
>
> Key: ISPN-5149
> URL: https://issues.jboss.org/browse/ISPN-5149
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Querying
> Affects Versions: 7.1.0.Beta1
> Reporter: Adrian Nistor
> Assignee: Adrian Nistor
>
> Steps to reproduce:
> 1. use the remote-query quickstart app (https://github.com/jboss-developer/jboss-jdg-quickstarts/tree/master/remo...) with an indexed cache config to add a Person and then a Memo object that has the Person as author.
> 2. try to query memos by author -> you get this exception
> {code}
> Jan 14, 2015 4:13:52 PM org.infinispan.client.hotrod.impl.protocol.Codec20 checkForErrorsInResponseStatus
> WARN: ISPN004005: Error received from the server: java.lang.IllegalArgumentException: Field author.name from type quickstart.Memo is not indexed
> org.infinispan.client.hotrod.exceptions.HotRodClientException:Request for message id[14] returned server error (status=0x85): java.lang.IllegalArgumentException: Field author.name from type quickstart.Memo is not indexed
> at org.infinispan.client.hotrod.impl.protocol.Codec20.checkForErrorsInResponseStatus(Codec20.java:321)
> at org.infinispan.client.hotrod.impl.protocol.Codec20.readPartialHeader(Codec20.java:111)
> at org.infinispan.client.hotrod.impl.protocol.Codec20.readHeader(Codec20.java:97)
> at org.infinispan.client.hotrod.impl.operations.HotRodOperation.readHeaderAndValidate(HotRodOperation.java:56)
> at org.infinispan.client.hotrod.impl.operations.QueryOperation.executeOperation(QueryOperation.java:57)
> at org.infinispan.client.hotrod.impl.operations.QueryOperation.executeOperation(QueryOperation.java:24)
> at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:50)
> at org.infinispan.client.hotrod.impl.query.RemoteQuery.executeQuery(RemoteQuery.java:72)
> at org.infinispan.client.hotrod.impl.query.RemoteQuery.list(RemoteQuery.java:62)
> at org.jboss.as.quickstarts.datagrid.hotrod.query.AddressBookManager.queryMemoByAuthor(AddressBookManager.java:285)
> at org.jboss.as.quickstarts.datagrid.hotrod.query.AddressBookManager.main(AddressBookManager.java:328)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:134)
> >
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (ISPN-5150) Eager near cache tests randomly failing
by Galder Zamarreño (JIRA)
Galder Zamarreño created ISPN-5150:
--------------------------------------
Summary: Eager near cache tests randomly failing
Key: ISPN-5150
URL: https://issues.jboss.org/browse/ISPN-5150
Project: Infinispan
Issue Type: Bug
Components: Remote Protocols
Affects Versions: 7.1.0.Beta1
Reporter: Galder Zamarreño
Assignee: Galder Zamarreño
Fix For: 7.1.0.CR1
expectNearGetValue() failing randomly in eager near cache tests randomly, e..g
http://ci.infinispan.org/viewLog.html?buildId=22924&buildTypeId=bt9&tab=b...
{code}
java.lang.AssertionError: expected:<v1> but was:<null>
at org.testng.AssertJUnit.fail(AssertJUnit.java:59)
at org.testng.AssertJUnit.failNotEquals(AssertJUnit.java:364)
at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:80)
at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:88)
at org.infinispan.client.hotrod.near.AssertsNearCache.assertGetKeyValue(AssertsNearCache.java:168)
at org.infinispan.client.hotrod.near.AssertsNearCache.expectNearGetValue(AssertsNearCache.java:85)
at org.infinispan.client.hotrod.near.EagerNearCacheTest.testGetNearCache(EagerNearCacheTest.java:37)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
{code}
In this case, the tests afterwards fail with:
{code}
java.lang.AssertionError: [org.infinispan.client.hotrod.near.MockNearCacheService$MockPutIfAbsentEvent{key=1, value=VersionedValueImpl{version=1, value=v1}}] expected:<0> but was:<1>
at org.testng.AssertJUnit.fail(AssertJUnit.java:59)
at org.testng.AssertJUnit.failNotEquals(AssertJUnit.java:364)
at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:80)
at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:245)
at org.infinispan.client.hotrod.near.AssertsNearCache.expectNoNearEvents(AssertsNearCache.java:71)
at org.infinispan.client.hotrod.near.EagerNearCacheTest.testGetUpdatesNearCache(EagerNearCacheTest.java:59)
{code}
We also see a similar failure in ClusterEagerNearCacheTest
http://ci.infinispan.org/viewLog.html?buildId=22966&tab=buildResultsDiv&b...
{code}
java.lang.AssertionError: expected:<v1> but was:<null>
at org.testng.AssertJUnit.fail(AssertJUnit.java:59)
at org.testng.AssertJUnit.failNotEquals(AssertJUnit.java:364)
at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:80)
at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:88)
at org.infinispan.client.hotrod.near.AssertsNearCache.assertGetKeyValue(AssertsNearCache.java:168)
at org.infinispan.client.hotrod.near.AssertsNearCache.expectNearGetValue(AssertsNearCache.java:85)
at org.infinispan.client.hotrod.near.ClusterEagerNearCacheTest.expectNearCacheUpdates(ClusterEagerNearCacheTest.java:65)
at org.infinispan.client.hotrod.near.ClusterEagerNearCacheTest.testNearCacheUpdatesSeenByAllClients(ClusterEagerNearCacheTest.java:58)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (ISPN-5103) Inefficient index updates cause high cost merges and increase overall latency
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-5103?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-5103:
-----------------------------------------------
Radim Vansa <rvansa(a)redhat.com> changed the Status of [bug 1180693|https://bugzilla.redhat.com/show_bug.cgi?id=1180693] from ON_QA to VERIFIED
> Inefficient index updates cause high cost merges and increase overall latency
> -----------------------------------------------------------------------------
>
> Key: ISPN-5103
> URL: https://issues.jboss.org/browse/ISPN-5103
> Project: Infinispan
> Issue Type: Enhancement
> Components: Embedded Querying
> Affects Versions: 7.0.2.Final, 7.1.0.Alpha1
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
> Fix For: 7.1.0.Beta1
>
>
> Currently every change to the index is done Lucene-wise combining two operations:
> * Delete by query, using a boolean query on the id plus the entity class
> * Add
>
> Under high load, specially during merges those numerous deletes provoke very long delays causing high latency.
> We should instead use a simple Lucene Update to add/change documents, since internally it translates to a Delete by term plus an Add operation, and delete by terms are extremely efficient in Lucene.
> Some local tests showed average latency of updating the index using this strategy to drop 4 times, both for the SYNC and ASYNC backends
> With relation to sharing the index between entities, which was the original motivation of the Delete by query plus add strategy, we have two scenarios:
> * Same cache with multiple entity types: that's a non-issue, since obviously there's no id collision in this case
> * Different caches with the same index: this scenario happens when different caches shares the same index, for ex:
> {code}
> @Indexed(indexName=common)
> public class Country { ... }
> @Indexed(indexName=common)
> public class Currency { ... }
> cm.getCache("currencies").put(1, new Currency(...))
> cm.getCache("countries").put(1, new Country(...))
> {code}
> This would require a delete by query in order to persist both a Country and a Currency with id=1.
> It would also require setting "default.exclusive_index_use", "false", with the associated cost of having to reopen the IndexWriter on every operation.
> Given the performance gain of doing a simple Update is considerable, we should make the corner case supported by extra configuration or alternatively, generate a unique @ProvidedId, including the entity class or the cache name that work for all cases described above.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months