June 2015 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-5452) Query Execution using Hibernate Search slow for large volume data

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-5452?page=com.atlassian.jira.plugin.... ] Adrian Nistor commented on ISPN-5452: ------------------------------------- I've tried measuring and comparing remote vs embedded, see RemoteQueryDslPerfTest in this PR: https://github.com/infinispan/infinispan/pull/3520 I found remote mode to be 2x slower than embedded, which perfectly fits my expectations. A query that matches exactly one entry takes about 600 microseconds in remote mode and 300 us in embedded mode. But this scenario runs completely in memory, on one machine and the volume of data is very small. It was not meant to measure absolute performance but it does prove the relative difference between remote and embedded is not absurdly big. So unless we identify why we have such a big difference in your scenario there is not much we can do. > 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)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2198) Cluster with non-shared JDBC cache store has too much entries after node failure

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-2198?page=com.atlassian.jira.plugin.... ] Dan Berindei edited comment on ISPN-2198 at 6/3/15 9:23 AM: ------------------------------------------------------------ [~rvansa] on a second look, each node's configuration has a different table prefix, so the configuration is fine. However, state transfer has indeed changed completely since version 5.1, so I'm resolving this as out of date. was (Author: dan.berindei): [~rvansa] on a second look, each node's configuration has a different table prefix, so the configuration is fine. However, state transfer has changed completely since version 5.1, so I'm resolving this as out of date. > Cluster with non-shared JDBC cache store has too much entries after node failure > -------------------------------------------------------------------------------- > > Key: ISPN-2198 > URL: https://issues.jboss.org/browse/ISPN-2198 > Project: Infinispan > Issue Type: Feature Request > Components: Loaders and Stores > Affects Versions: 5.1.5.FINAL > Reporter: Radim Vansa > Attachments: cache_entries.csv, logs.zip, sfout.txt > > > In resilience test with 4-node cluster where one node is killed a weird situation appears. Before the node kill have this number of entries: > 210602;215820;209400;203038 = 838860 entries > After the kill the number of entries changes for a while: > 210602;null;209400;203038 > 250602;null;269400;243038 > 290602;null;269400;273038 > 300602;null;289400;293038 > 300602;null;289400;293038 > 321218;null;296035;293038 > But then it stabilizes on > 326899;null;305039;314165 = 946103 entries > When the node02 is restarted it complains about duplicit entries: > ERROR [org.infinispan.loaders.jdbc.stringbased.JdbcStringBasedCacheStore] (OOB-124,null) ISPN008024: Error while storing string key to database; key: '8Az4Ia2V5NzYzNDI=', buffer size of value: 1050 bytes: com.mysql.jdbc.exceptions.jdbc4.MySQLIntegrityConstraintViolationException: Duplicate entry '?8Az4Ia2V5NzYzNDI=' for key 'PRIMARY' > Is this a bug or wrong configuration? > Here is an excerpt from configuration (sorry for no formatting): > <distributed-cache batching="false" indexing="NONE" l1-lifespan="0" mode="SYNC" name="memcachedCache" owners="2" remote-timeout="60000" start="EAGER" virtual-nodes="512"> > <locking acquire-timeout="3000" concurrency-level="1000" isolation="REPEATABLE_READ" striping="false"/> > <transaction mode="NONE"/> > <state-transfer enabled="true" timeout="600000"/> > <eviction max-entries="-1" strategy="NONE"/> > <string-keyed-jdbc-store datasource="java:jboss/datasources/JdbcDS" passivation="false" preload="false" purge="true" shared="false"> > <property name="databaseType">MYSQL</property> > <string-keyed-table prefix="node01"> > <id-column name="id" type="VARCHAR(100)"/> > <data-column name="value" type="BLOB(1200)"/> > </string-keyed-table> > </string-keyed-jdbc-store> > </distributed-cache> -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2198) Cluster with non-shared JDBC cache store has too much entries after node failure

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-2198?page=com.atlassian.jira.plugin.... ] Dan Berindei resolved ISPN-2198. -------------------------------- Resolution: Out of Date [~rvansa] on a second look, each node's configuration has a different table prefix, so the configuration is fine. However, state transfer has changed completely since version 5.1, so I'm resolving this as out of date. > Cluster with non-shared JDBC cache store has too much entries after node failure > -------------------------------------------------------------------------------- > > Key: ISPN-2198 > URL: https://issues.jboss.org/browse/ISPN-2198 > Project: Infinispan > Issue Type: Feature Request > Components: Loaders and Stores > Affects Versions: 5.1.5.FINAL > Reporter: Radim Vansa > Attachments: cache_entries.csv, logs.zip, sfout.txt > > > In resilience test with 4-node cluster where one node is killed a weird situation appears. Before the node kill have this number of entries: > 210602;215820;209400;203038 = 838860 entries > After the kill the number of entries changes for a while: > 210602;null;209400;203038 > 250602;null;269400;243038 > 290602;null;269400;273038 > 300602;null;289400;293038 > 300602;null;289400;293038 > 321218;null;296035;293038 > But then it stabilizes on > 326899;null;305039;314165 = 946103 entries > When the node02 is restarted it complains about duplicit entries: > ERROR [org.infinispan.loaders.jdbc.stringbased.JdbcStringBasedCacheStore] (OOB-124,null) ISPN008024: Error while storing string key to database; key: '8Az4Ia2V5NzYzNDI=', buffer size of value: 1050 bytes: com.mysql.jdbc.exceptions.jdbc4.MySQLIntegrityConstraintViolationException: Duplicate entry '?8Az4Ia2V5NzYzNDI=' for key 'PRIMARY' > Is this a bug or wrong configuration? > Here is an excerpt from configuration (sorry for no formatting): > <distributed-cache batching="false" indexing="NONE" l1-lifespan="0" mode="SYNC" name="memcachedCache" owners="2" remote-timeout="60000" start="EAGER" virtual-nodes="512"> > <locking acquire-timeout="3000" concurrency-level="1000" isolation="REPEATABLE_READ" striping="false"/> > <transaction mode="NONE"/> > <state-transfer enabled="true" timeout="600000"/> > <eviction max-entries="-1" strategy="NONE"/> > <string-keyed-jdbc-store datasource="java:jboss/datasources/JdbcDS" passivation="false" preload="false" purge="true" shared="false"> > <property name="databaseType">MYSQL</property> > <string-keyed-table prefix="node01"> > <id-column name="id" type="VARCHAR(100)"/> > <data-column name="value" type="BLOB(1200)"/> > </string-keyed-table> > </string-keyed-jdbc-store> > </distributed-cache> -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2053) Memcached server occasionally does not consume CR/LF after data block

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-2053?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-2053: ----------------------------------------------- Roman Macor <rmacor(a)redhat.com> changed the Status of [bug 801296|https://bugzilla.redhat.com/show_bug.cgi?id=801296] from ASSIGNED to VERIFIED > Memcached server occasionally does not consume CR/LF after data block > --------------------------------------------------------------------- > > Key: ISPN-2053 > URL: https://issues.jboss.org/browse/ISPN-2053 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols > Affects Versions: 5.1.5.CR1 > Reporter: NadirX > Assignee: Tristan Tarrant > Fix For: 5.1.5.FINAL > > > The memcached server sometimes "forgets" to read the ending CR/LF after value payloads. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5492) DelayedAvailabilityUpdateTest.testDelayedAvailabilityUpdate2 random failures

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-5492?page=com.atlassian.jira.plugin.... ] Dan Berindei reopened ISPN-5492: -------------------------------- Waiting for the availability mode to change on {{p0n1}} isn't enough either... the availability check in {{PartitionHandlingInterceptor}} can also pass if the partition is in degraded mode, but the list of available members hasn't been updated yet (because the availability mode is updated before the cache topology). > DelayedAvailabilityUpdateTest.testDelayedAvailabilityUpdate2 random failures > ---------------------------------------------------------------------------- > > Key: ISPN-5492 > URL: https://issues.jboss.org/browse/ISPN-5492 > Project: Infinispan > Issue Type: Bug > Components: Core, Test Suite - Core > Affects Versions: 7.2.1.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Blocker > Labels: testsuite_stability > Fix For: 8.0.0.Alpha1 > > > {{Partition.partition()}} only waits for the split JGroups view to be installed, and the test should explicitly wait for {{p0.node(1)}} to enter degraded mode before doing the read availability check on {{k1Existing}}. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5464) ReflectionHelper fails to detect element type for arrays of generic types

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5464?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5464: ----------------------------------------------- Vojtech Juranek <vjuranek(a)redhat.com> changed the Status of [bug 1223010|https://bugzilla.redhat.com/show_bug.cgi?id=1223010] from ON_QA to VERIFIED > ReflectionHelper fails to detect element type for arrays of generic types > ------------------------------------------------------------------------- > > Key: ISPN-5464 > URL: https://issues.jboss.org/browse/ISPN-5464 > Project: Infinispan > Issue Type: Bug > Components: Embedded Querying > Affects Versions: 7.2.1.Final > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 7.2.2.Final, 8.0.0.Alpha1, 8.0.0.Final > > > A property declared like: > {code} > SomeGenericType<T>[] myArrayProperty; > {code} > Will cause a ClassCastException in ReflectionHelper. > This affects indexless queries only. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5420) Thread pools are depleted by ClusterTopologyManagerImpl.waitForView() and causing deadlock

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5420?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5420: ----------------------------------------------- Alan Field <afield(a)redhat.com> changed the Status of [bug 1208429|https://bugzilla.redhat.com/show_bug.cgi?id=1208429] from ON_QA to VERIFIED > Thread pools are depleted by ClusterTopologyManagerImpl.waitForView() and causing deadlock > ------------------------------------------------------------------------------------------ > > Key: ISPN-5420 > URL: https://issues.jboss.org/browse/ISPN-5420 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 6.0.2.Final, 7.1.1.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > Fix For: 8.0.0.Alpha1 > > > The join process was designed in the idea that a node would start its caches in sequential order, so {{ClusterTopologyManager.waitForView()}} would block at most once for each joining node. However, WildFly actually starts {{2 * Runtime.availableProcessors()}} caches in parallel, and this can be a problem when the machine has a lot of cores and multiple nodes. > {{ClustertopologyManager.handleClusterView()}} only updates the {{viewId}} after it updated the cache topologies of each cache AND after it confirmed the availability of all the nodes with a {{POLICY_GET_STATUS}} RPC. This RPC can block, and it's very easy for the remote-executor thread pool on the coordinator to become overloades with threads like this: > {noformat} > "remote-thread-172" daemon prio=10 tid=0x00007f0cc48c0000 nid=0x28ca4 in Object.wait() [0x00007f0c5f25b000] > java.lang.Thread.State: TIMED_WAITING (on object monitor) > at java.lang.Object.wait(Native Method) > at org.infinispan.topology.ClusterTopologyManagerImpl.waitForView(ClusterTopologyManagerImpl.java:357) > - locked <0x00000000ff3bd900> (a java.lang.Object) > at org.infinispan.topology.ClusterTopologyManagerImpl.handleJoin(ClusterTopologyManagerImpl.java:123) > at org.infinispan.topology.CacheTopologyControlCommand.doPerform(CacheTopologyControlCommand.java:162) > at org.infinispan.topology.CacheTopologyControlCommand.perform(CacheTopologyControlCommand.java:144) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher$4.run(CommandAwareRpcDispatcher.java:276) > {noformat} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5440) Upgrade to Hibernate Search 5.3.0.CR1

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/ISPN-5440?page=com.atlassian.jira.plugin.... ] Sanne Grinovero updated ISPN-5440: ---------------------------------- Summary: Upgrade to Hibernate Search 5.3.0.CR1 (was: Upgrade to Hibernate Search 5.3.0.Beta1) > Upgrade to Hibernate Search 5.3.0.CR1 > ------------------------------------- > > Key: ISPN-5440 > URL: https://issues.jboss.org/browse/ISPN-5440 > Project: Infinispan > Issue Type: Component Upgrade > Components: Embedded Querying > Reporter: Sanne Grinovero > Assignee: Gustavo Fernandes > Fix For: 8.0.0.Alpha2 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5519) Cannot choose to run index-less query on an indexed cache in compat mode

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-5519?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-5519: -------------------------------- Git Pull Request: https://github.com/infinispan/infinispan/pull/3520, https://github.com/infinispan/infinispan/pull/3521 (was: https://github.com/infinispan/infinispan/pull/3520) > Cannot choose to run index-less query on an indexed cache in compat mode > ------------------------------------------------------------------------ > > Key: ISPN-5519 > URL: https://issues.jboss.org/browse/ISPN-5519 > Project: Infinispan > Issue Type: Enhancement > Components: Embedded Querying, Remote Querying > Affects Versions: 7.2.2.Final, 8.0.0.Alpha1 > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 8.0.0.Alpha2, 7.2.3.Final > > > This is similar to ISPN-5165 but refers to compat mode. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5519) Cannot choose to run index-less query on an indexed cache in compat mode

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-5519?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-5519: -------------------------------- Fix Version/s: 8.0.0.Alpha2 (was: 8.0.0.Beta1) > Cannot choose to run index-less query on an indexed cache in compat mode > ------------------------------------------------------------------------ > > Key: ISPN-5519 > URL: https://issues.jboss.org/browse/ISPN-5519 > Project: Infinispan > Issue Type: Enhancement > Components: Embedded Querying, Remote Querying > Affects Versions: 7.2.2.Final, 8.0.0.Alpha1 > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 8.0.0.Alpha2, 7.2.3.Final > > > This is similar to ISPN-5165 but refers to compat mode. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 4 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues June 2015