July 2015 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-5623) Retried prepare commands do not wait for backup locks

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-5623?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-5623: ------------------------------- Attachment: OptimisticPrimaryOwnerCrashDuringPrepareTest.java Attached test reproduces the issue. > Retried prepare commands do not wait for backup locks > ----------------------------------------------------- > > Key: ISPN-5623 > URL: https://issues.jboss.org/browse/ISPN-5623 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.2.3.Final, 8.0.0.Beta1 > Reporter: Dan Berindei > Fix For: 8.0.0.Beta2 > > Attachments: OptimisticPrimaryOwnerCrashDuringPrepareTest.java > > > When the primary owner crashes during prepare, the prepare command is retried on the new primary owner. But because the transaction topology id stays the same, the new primary owner does not check for backup locks owned by other transactions from the previous topology. > That makes it possible for the retried prepare command to lock a key that was already locked by another transaction on the primary owner. > This wasn't a problem before the ISPN-4546 fix, because a primary owner crash would have forced the transaction to roll back. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5623) Retried prepare commands do not wait for backup locks

by Dan Berindei (JIRA)

Dan Berindei created ISPN-5623: ---------------------------------- Summary: Retried prepare commands do not wait for backup locks Key: ISPN-5623 URL: https://issues.jboss.org/browse/ISPN-5623 Project: Infinispan Issue Type: Bug Components: Core Affects Versions: 8.0.0.Beta1, 7.2.3.Final Reporter: Dan Berindei Fix For: 8.0.0.Beta2 When the primary owner crashes during prepare, the prepare command is retried on the new primary owner. But because the transaction topology id stays the same, the new primary owner does not check for backup locks owned by other transactions from the previous topology. That makes it possible for the retried prepare command to lock a key that was already locked by another transaction on the primary owner. This wasn't a problem before the ISPN-4546 fix, because a primary owner crash would have forced the transaction to roll back. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5622) Make use of parallel iteration in the MassIndexer

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-5622?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes reassigned ISPN-5622: --------------------------------------- Assignee: Gustavo Fernandes > Make use of parallel iteration in the MassIndexer > ------------------------------------------------- > > Key: ISPN-5622 > URL: https://issues.jboss.org/browse/ISPN-5622 > Project: Infinispan > Issue Type: Enhancement > Components: Embedded Querying > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > > As the EntryRetriever is being deprecated, there's a possibility of speeding up the indexing process by using parallel streams -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5622) Make use of parallel iteration in the MassIndexer

by Gustavo Fernandes (JIRA)

Gustavo Fernandes created ISPN-5622: --------------------------------------- Summary: Make use of parallel iteration in the MassIndexer Key: ISPN-5622 URL: https://issues.jboss.org/browse/ISPN-5622 Project: Infinispan Issue Type: Enhancement Components: Embedded Querying Reporter: Gustavo Fernandes As the EntryRetriever is being deprecated, there's a possibility of speeding up the indexing process by using parallel streams -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 5 months

1
0
0 / 0

[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 updated ISPN-5452: ---------------------------------- Affects Version/s: 8.0.0.Final > 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, 8.0.0.Final > Environment: Linux > Reporter: Prashant Thakur > Attachments: profiling_results.7z > > > 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, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5598) Hit count computed incorrectly for getAll()

by Andrea Cosentino (JIRA)

[ https://issues.jboss.org/browse/ISPN-5598?page=com.atlassian.jira.plugin.... ] Andrea Cosentino commented on ISPN-5598: ---------------------------------------- PR updated: https://github.com/infinispan/infinispan/pull/3595 > Hit count computed incorrectly for getAll() > ------------------------------------------- > > Key: ISPN-5598 > URL: https://issues.jboss.org/browse/ISPN-5598 > Project: Infinispan > Issue Type: Bug > Reporter: Radim Vansa > Priority: Minor > > Hits are counted twice during getAll(). > https://github.com/infinispan/infinispan/blob/master/core/src/main/java/o... -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5619) Deprecate EntryRetriever with distributed streams

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-5619?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-5619: -------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://issues.jboss.org/browse/ISPN-5619 > Deprecate EntryRetriever with distributed streams > ------------------------------------------------- > > Key: ISPN-5619 > URL: https://issues.jboss.org/browse/ISPN-5619 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 8.0.0.Beta1 > Reporter: William Burns > Assignee: William Burns > Fix For: 8.0.0.CR1, 8.0.0.Final > > > Distributed streams were added for ISPN-5293. However segment completion listeners are not yet added and thus EntryRetriever is still required for that case. This is to add support for listener completion so we can remove EntryRetriever references. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5568) KeyAffinityService race condition on view change

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-5568?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-5568: ------------------------------- Git Pull Request: https://github.com/infinispan/infinispan/pull/3590, https://github.com/infinispan/infinispan/pull/3589, https://github.com/infinispan/infinispan/pull/3588, https://github.com/infinispan/infinispan/pull/3597, https://github.com/infinispan/infinispan/pull/3598 (was: https://github.com/infinispan/infinispan/pull/3590, https://github.com/infinispan/infinispan/pull/3589, https://github.com/infinispan/infinispan/pull/3588) > KeyAffinityService race condition on view change > ------------------------------------------------ > > Key: ISPN-5568 > URL: https://issues.jboss.org/browse/ISPN-5568 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 5.2.11.Final > Reporter: Dennis Reed > Assignee: Bartosz Baranowski > > KeyAffinityService#getKeyForAddress runs in a tight loop looking for keys: > {noformat} > queue = address2key.get(address) > while (result == null) > result = queue.poll() > {noformat} > KeyAffinityService#handleViewChange clears and resets the queue list on membership change: > {noformat} > address2key.clear() > for each address > map.put(address, new queue) > {noformat} > If a view change comes in after getKeyForAddress gets the queue, and the queue is empty, it will get stuck in a tight loop looking at the wrong queue forever while new keys are added to the new queue. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5618) Upgrade to WildFly 9.0.0.Final

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-5618?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-5618: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Upgrade to WildFly 9.0.0.Final > ------------------------------ > > Key: ISPN-5618 > URL: https://issues.jboss.org/browse/ISPN-5618 > Project: Infinispan > Issue Type: Task > Components: Server > Affects Versions: 8.0.0.Beta1 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 8.0.0.Beta2, 8.0.0.Final > > > Now that WildFly 9.0.0.Final is out, we should upgrade our server to it. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5599) Deadlock exception when purging string based JDBC Store

by Richard Lucas (JIRA)

[ https://issues.jboss.org/browse/ISPN-5599?page=com.atlassian.jira.plugin.... ] Richard Lucas commented on ISPN-5599: ------------------------------------- It appears this issue is a side effect of me wrapping the JDBC calls in a local transaction via a patched version of Infinispan. The issue occurs when the expiration process runs and attempts to remove expired items in the cache store. This results in row locking which results in deadlock exceptions if my application tries to access the row while it is locked. I have also seen the issue cause the purge to error if the application has the row locked. I have resolved the issue for now by disabling expiration in my cache store as I do not require it. This issue can most likely be closed as it is a result of my modified code base but it may be worth noting that this could be an issue when transaction support is introduced for JDBC Cache Stores ISPN-201 > Deadlock exception when purging string based JDBC Store > ------------------------------------------------------- > > Key: ISPN-5599 > URL: https://issues.jboss.org/browse/ISPN-5599 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 7.2.0.Final > Environment: Wildfly 8.2 > Reporter: Richard Lucas > Labels: cache-store, jdbc > > I'm seeing the following expectation periodically when purging my Infinispan cache using the JDBC string based cache store: > {noformat} > 12:45:20,752 WARN [org.infinispan.persistence.manager.PersistenceManagerImpl] (expiration-thread--p2-t1) ISPN000026: Caught exception purging data container!: org.infinispan.persistence.spi.PersistenceException: java.util.concurrent.ExecutionException: org.infinispan.persistence.spi.PersistenceException: Failed clearing string based JDBC store > at org.infinispan.persistence.jdbc.stringbased.JdbcStringBasedStore.purge(JdbcStringBasedStore.java:302) [infinispan-cachestore-jdbc.jar:7.2.0.Final] > at org.infinispan.persistence.manager.PersistenceManagerImpl.purgeExpired(PersistenceManagerImpl.java:342) [infinispan-core.jar:7.2.0.Final] > at org.infinispan.expiration.impl.ExpirationManagerImpl.processExpiration(ExpirationManagerImpl.java:101) [infinispan-core.jar:7.2.0.Final] > at org.infinispan.expiration.impl.ExpirationManagerImpl$ScheduledTask.run(ExpirationManagerImpl.java:122) [infinispan-core.jar:7.2.0.Final] > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [rt.jar:1.8.0_40] > at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) [rt.jar:1.8.0_40] > at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) [rt.jar:1.8.0_40] > at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) [rt.jar:1.8.0_40] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_40] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_40] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_40] > Caused by: java.util.concurrent.ExecutionException: org.infinispan.persistence.spi.PersistenceException: Failed clearing string based JDBC store > at java.util.concurrent.FutureTask.report(FutureTask.java:122) [rt.jar:1.8.0_40] > at java.util.concurrent.FutureTask.get(FutureTask.java:192) [rt.jar:1.8.0_40] > at org.infinispan.persistence.jdbc.stringbased.JdbcStringBasedStore.purge(JdbcStringBasedStore.java:297) [infinispan-cachestore-jdbc.jar:7.2.0.Final] > ... 10 more > Caused by: org.infinispan.persistence.spi.PersistenceException: Failed clearing string based JDBC store > at org.infinispan.persistence.jdbc.stringbased.JdbcStringBasedStore$1.call(JdbcStringBasedStore.java:288) [infinispan-cachestore-jdbc.jar:7.2.0.Final] > at org.infinispan.persistence.jdbc.stringbased.JdbcStringBasedStore$1.call(JdbcStringBasedStore.java:272) [infinispan-cachestore-jdbc.jar:7.2.0.Final] > at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_40] > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [rt.jar:1.8.0_40] > at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_40] > ... 3 more > Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLTransactionRollbackException: Deadlock found when trying to get lock; try restarting transaction > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [rt.jar:1.8.0_40] > at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) [rt.jar:1.8.0_40] > at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [rt.jar:1.8.0_40] > at java.lang.reflect.Constructor.newInstance(Constructor.java:422) [rt.jar:1.8.0_40] > at com.mysql.jdbc.Util.handleNewInstance(Util.java:408) > at com.mysql.jdbc.Util.getInstance(Util.java:383) > at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1074) > at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4208) > at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4140) > at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2597) > at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2758) > at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2826) > at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:2082) > at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2334) > at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2262) > at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2246) > at com.mysql.jdbc.jdbc2.optional.PreparedStatementWrapper.executeUpdate(PreparedStatementWrapper.java:873) > at org.jboss.jca.adapters.jdbc.CachedPreparedStatement.executeUpdate(CachedPreparedStatement.java:119) > at org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:493) > at org.infinispan.persistence.jdbc.stringbased.JdbcStringBasedStore$1.call(JdbcStringBasedStore.java:282) [infinispan-cachestore-jdbc.jar:7.2.0.Final] > ... 7 more > {noformat} > My cache configuration is: > {code:xml} > <cache-container default-cache="repo" statistics="false"> > <transport cluster="modeshape-cluster" stack="tcp"/> > <jmx duplicate-domains="true"/> > <replicated-cache name="repo" mode="SYNC"> > <locking striping="false" isolation="READ_COMMITTED"/> > <transaction mode="NON_DURABLE_XA" locking="PESSIMISTIC"/> > <persistence passivation="false"> > <string-keyed-jdbc-store xmlns="urn:infinispan:config:store:jdbc:7.0" fetch-state="false" read-only="false" purge="true" shared="true"> > <data-source jndi-url="java:jboss/datasources/ds"/> > <string-keyed-table prefix="modeshape" create-on-start="true" drop-on-exit="false"> > <id-column name="id" type="VARCHAR(200)"/> > <data-column name="datum" type="LONGBLOB"/> > <timestamp-column name="version" type="BIGINT"/> > </string-keyed-table> > </string-keyed-jdbc-store> > </persistence> > </replicated-cache> > </cache-container> > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues July 2015