[JBoss JIRA] (ISPN-5452) Query Execution using Hibernate Search slow for large volume data
by Prashant Thakur (JIRA)
[ https://issues.jboss.org/browse/ISPN-5452?page=com.atlassian.jira.plugin.... ]
Prashant Thakur commented on ISPN-5452:
---------------------------------------
Any updates or hints how we can resolve this issue
> Query Execution using Hibernate Search slow for large volume data
> -----------------------------------------------------------------
>
> Key: ISPN-5452
> URL: https://issues.jboss.org/browse/ISPN-5452
> Project: Infinispan
> Issue Type: Bug
> Components: Configuration, Remote Querying
> Affects Versions: 7.2.1.Final
> Environment: Linux
> Reporter: Prashant Thakur
>
> While benchmarking Infinispan we found that Querying is very slow when compared with Hibernate Search in Isolation
> Single node of Infinispan
> Memory allocated 230GB. No GC seen throughout query operation.
> Total required after full GC was 122GB.
> Setup 240 million records each of avg size 330 bytes .
> System has 16 cores and 40 worker threads were allocated at server side.
> With Single Client thread throughput was 900 req/sec in remote and 3k per sec in embedded more same request with Hibernate Search in Isolation gives throughput of 14000 req/sec.
> For 50 threads of clients the throughput was limited to 15k req/sec while hibernate search gives 80k req/sec for 10 threads.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 1 month
[JBoss JIRA] (ISPN-4720) Values data reverts in Compatibilty mode in Infinispan 6.0.2
by Prashant Thakur (JIRA)
[ https://issues.jboss.org/browse/ISPN-4720?page=com.atlassian.jira.plugin.... ]
Prashant Thakur commented on ISPN-4720:
---------------------------------------
We are still getting this issue in latest version of infinispan even in 7.2.2.
The issue is simple
1) Configure cache in compatibility mode
2) Specify number of owners as 2
3) Start 3 nodes.t
4) try some get and put operation through hot-rod client error occurs as there is some type conversion issues.
> Values data reverts in Compatibilty mode in Infinispan 6.0.2
> ------------------------------------------------------------
>
> Key: ISPN-4720
> URL: https://issues.jboss.org/browse/ISPN-4720
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 6.0.2.Final
> Environment: Linux 3.15.8-200.fc20.x86_64
> Reporter: Prashant Thakur
> Assignee: Dan Berindei
> Priority: Critical
> Labels: Infinispan
> Fix For: 7.0.0.Alpha3
>
> Attachments: distributed_cache_configuration.xml, tc1.zip, tc2.out, tc3.out, tc4.out
>
>
> 1) The owners of the keys are Node1 and Node4
> 0911 10:56:56,552 TRACE [org.infinispan.interceptors.distribution.TxDistributionInterceptor] [remote-thread-0] (TxDistributionInterceptor.java:362) - Not doing a remote get for key 1029 since entry is mapped to current node (blrsrv42-19390), or is in L1. Owners are [blrsrv29-4565, blrsrv42-19390]
> 2. The request for update came to Node2 a non-owner.
> 0911 10:56:56,388 TRACE [org.infinispan.statetransfer.StateTransferInterceptor] [HotRodServerWorker-2] (StateTransferInterceptor.java:203) - handleNonTxWriteCommand for command ReplaceCommand{key=1029, oldValue=TestData{id=1029, field1=XXXXXX}, newValue=TestData{id=1029, field1=cyyy}, metadata=EmbeddedMetadata{version=NumericVersion{version=844433520066561}}, flags=[OPERATION_HOTROD], successful=true, valueMatcher=MATCH_EXPECTED}
> 3. The updates are happening in Node1 and overwritten again with old data present in OOB Thread. Because of which the Node1, reverts back to the old data.
> 4. While doing a get from Node 1 we again receive the old value
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 1 month
[JBoss JIRA] (ISPN-4720) Values data reverts in Compatibilty mode in Infinispan 6.0.2
by Prashant Thakur (JIRA)
[ https://issues.jboss.org/browse/ISPN-4720?page=com.atlassian.jira.plugin.... ]
Prashant Thakur reopened ISPN-4720:
-----------------------------------
Issue still visible after migrating to 7.2.0.Final as well.
> Values data reverts in Compatibilty mode in Infinispan 6.0.2
> ------------------------------------------------------------
>
> Key: ISPN-4720
> URL: https://issues.jboss.org/browse/ISPN-4720
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 6.0.2.Final
> Environment: Linux 3.15.8-200.fc20.x86_64
> Reporter: Prashant Thakur
> Assignee: Dan Berindei
> Priority: Critical
> Labels: Infinispan
> Fix For: 7.0.0.Alpha3
>
> Attachments: distributed_cache_configuration.xml, tc1.zip, tc2.out, tc3.out, tc4.out
>
>
> 1) The owners of the keys are Node1 and Node4
> 0911 10:56:56,552 TRACE [org.infinispan.interceptors.distribution.TxDistributionInterceptor] [remote-thread-0] (TxDistributionInterceptor.java:362) - Not doing a remote get for key 1029 since entry is mapped to current node (blrsrv42-19390), or is in L1. Owners are [blrsrv29-4565, blrsrv42-19390]
> 2. The request for update came to Node2 a non-owner.
> 0911 10:56:56,388 TRACE [org.infinispan.statetransfer.StateTransferInterceptor] [HotRodServerWorker-2] (StateTransferInterceptor.java:203) - handleNonTxWriteCommand for command ReplaceCommand{key=1029, oldValue=TestData{id=1029, field1=XXXXXX}, newValue=TestData{id=1029, field1=cyyy}, metadata=EmbeddedMetadata{version=NumericVersion{version=844433520066561}}, flags=[OPERATION_HOTROD], successful=true, valueMatcher=MATCH_EXPECTED}
> 3. The updates are happening in Node1 and overwritten again with old data present in OOB Thread. Because of which the Node1, reverts back to the old data.
> 4. While doing a get from Node 1 we again receive the old value
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 1 month