[JBoss JIRA] (ISPN-5601) Merge ExtendedModuleCommandFactory into ModuleCommandFactory
by Radim Vansa (JIRA)
Radim Vansa created ISPN-5601:
---------------------------------
Summary: Merge ExtendedModuleCommandFactory into ModuleCommandFactory
Key: ISPN-5601
URL: https://issues.jboss.org/browse/ISPN-5601
Project: Infinispan
Issue Type: Bug
Components: Core
Affects Versions: 8.0.0.Alpha2
Reporter: Radim Vansa
These are the docs for ExtendedModuleCommandFactory:
{quote}
Temporary workaround to avoid modifying ModuleCommandFactory interface. This interface should be merged with ModuleCommandFactory in 6.0.
{quote}
Seems that was forgotten in 6.0, 8.0 can fix that.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (ISPN-5600) Optimize transactions on multiple caches
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-5600?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-5600:
------------------------------------
I assume Narayana is processing synchronizations sequentially?
It would definitely be an improvement for users of multiple caches in the same transaction, but it may also need extensive changes in how we process transactions in Infinispan.
> Optimize transactions on multiple caches
> ----------------------------------------
>
> Key: ISPN-5600
> URL: https://issues.jboss.org/browse/ISPN-5600
> Project: Infinispan
> Issue Type: Enhancement
> Components: Transactions
> Affects Versions: 8.0.0.Alpha2
> Reporter: Radim Vansa
>
> NON_XA transactions that span multiple caches are registered as multiple synchronizations, and these synchronizations are often processed sequentially ^1^; therefore, we send synchronous PrepareCommand for each cache and then CommitCommand for each cache as well, delaying the commit by these round-trips.
> Since the targets for different caches may differ, we still need to send the RPCs separately, but in parallel. Therefore, there should be one uber-synchronization for all caches that use NON_XA mode (and maybe something similar with XA). I believe that using single synchronization could save some allocations, too.
> ^1^ Not sure if full-fledged JTA implementations do that; JTA spec does not say anything about the order of synchronizations and whether these should be processed in parallel.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (ISPN-5600) Optimize transactions on multiple caches
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-5600?page=com.atlassian.jira.plugin.... ]
Radim Vansa commented on ISPN-5600:
-----------------------------------
[~dan.berindei] WDYT?
> Optimize transactions on multiple caches
> ----------------------------------------
>
> Key: ISPN-5600
> URL: https://issues.jboss.org/browse/ISPN-5600
> Project: Infinispan
> Issue Type: Enhancement
> Components: Transactions
> Affects Versions: 8.0.0.Alpha2
> Reporter: Radim Vansa
>
> NON_XA transactions that span multiple caches are registered as multiple synchronizations, and these synchronizations are often processed sequentially ^1^; therefore, we send synchronous PrepareCommand for each cache and then CommitCommand for each cache as well, delaying the commit by these round-trips.
> Since the targets for different caches may differ, we still need to send the RPCs separately, but in parallel. Therefore, there should be one uber-synchronization for all caches that use NON_XA mode (and maybe something similar with XA). I believe that using single synchronization could save some allocations, too.
> ^1^ Not sure if full-fledged JTA implementations do that; JTA spec does not say anything about the order of synchronizations and whether these should be processed in parallel.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (ISPN-5600) Optimize transactions on multiple caches
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-5600?page=com.atlassian.jira.plugin.... ]
Radim Vansa updated ISPN-5600:
------------------------------
Component/s: Transactions
> Optimize transactions on multiple caches
> ----------------------------------------
>
> Key: ISPN-5600
> URL: https://issues.jboss.org/browse/ISPN-5600
> Project: Infinispan
> Issue Type: Enhancement
> Components: Transactions
> Affects Versions: 8.0.0.Alpha2
> Reporter: Radim Vansa
>
> NON_XA transactions that span multiple caches are registered as multiple synchronizations, and these synchronizations are often processed sequentially ^1^; therefore, we send synchronous PrepareCommand for each cache and then CommitCommand for each cache as well, delaying the commit by these round-trips.
> Since the targets for different caches may differ, we still need to send the RPCs separately, but in parallel. Therefore, there should be one uber-synchronization for all caches that use NON_XA mode (and maybe something similar with XA). I believe that using single synchronization could save some allocations, too.
> ^1^ Not sure if full-fledged JTA implementations do that; JTA spec does not say anything about the order of synchronizations and whether these should be processed in parallel.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (ISPN-5600) Optimize transactions on multiple caches
by Radim Vansa (JIRA)
Radim Vansa created ISPN-5600:
---------------------------------
Summary: Optimize transactions on multiple caches
Key: ISPN-5600
URL: https://issues.jboss.org/browse/ISPN-5600
Project: Infinispan
Issue Type: Enhancement
Reporter: Radim Vansa
NON_XA transactions that span multiple caches are registered as multiple synchronizations, and these synchronizations are often processed sequentially ^1^; therefore, we send synchronous PrepareCommand for each cache and then CommitCommand for each cache as well, delaying the commit by these round-trips.
Since the targets for different caches may differ, we still need to send the RPCs separately, but in parallel. Therefore, there should be one uber-synchronization for all caches that use NON_XA mode (and maybe something similar with XA). I believe that using single synchronization could save some allocations, too.
^1^ Not sure if full-fledged JTA implementations do that; JTA spec does not say anything about the order of synchronizations and whether these should be processed in parallel.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (ISPN-5600) Optimize transactions on multiple caches
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-5600?page=com.atlassian.jira.plugin.... ]
Radim Vansa updated ISPN-5600:
------------------------------
Affects Version/s: 8.0.0.Alpha2
> Optimize transactions on multiple caches
> ----------------------------------------
>
> Key: ISPN-5600
> URL: https://issues.jboss.org/browse/ISPN-5600
> Project: Infinispan
> Issue Type: Enhancement
> Affects Versions: 8.0.0.Alpha2
> Reporter: Radim Vansa
>
> NON_XA transactions that span multiple caches are registered as multiple synchronizations, and these synchronizations are often processed sequentially ^1^; therefore, we send synchronous PrepareCommand for each cache and then CommitCommand for each cache as well, delaying the commit by these round-trips.
> Since the targets for different caches may differ, we still need to send the RPCs separately, but in parallel. Therefore, there should be one uber-synchronization for all caches that use NON_XA mode (and maybe something similar with XA). I believe that using single synchronization could save some allocations, too.
> ^1^ Not sure if full-fledged JTA implementations do that; JTA spec does not say anything about the order of synchronizations and whether these should be processed in parallel.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (ISPN-5599) Deadlock exception when purging string based JDBC Store
by Richard Lucas (JIRA)
Richard Lucas created ISPN-5599:
-----------------------------------
Summary: 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
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)
10 years, 2 months
[JBoss JIRA] (ISPN-5597) Verify if clustered Arquillian based tests are really clustered
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-5597?page=com.atlassian.jira.plugin.... ]
Dan Berindei reassigned ISPN-5597:
----------------------------------
Assignee: Martin Gencur
> Verify if clustered Arquillian based tests are really clustered
> ---------------------------------------------------------------
>
> Key: ISPN-5597
> URL: https://issues.jboss.org/browse/ISPN-5597
> Project: Infinispan
> Issue Type: Task
> Components: Test Suite - Query, Test Suite - Server
> Reporter: Sanne Grinovero
> Assignee: Martin Gencur
> Priority: Critical
>
> I just identified ARQ-1964 while debugging a clustered issue, and I think this affects the reliability of many tests in Infinispan.
> The essence is that while you might think you're testing things on containers \{A,B\}, and so doing able to verify the cross-node synchronisations, you're actually always testing couples \{A,A\} or \{B,B\}. It's possible that some things actually don't work as expected even if the tests are passing.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (ISPN-5597) Verify if clustered Arquillian based tests are really clustered
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-5597?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-5597:
-------------------------------
Status: Open (was: New)
> Verify if clustered Arquillian based tests are really clustered
> ---------------------------------------------------------------
>
> Key: ISPN-5597
> URL: https://issues.jboss.org/browse/ISPN-5597
> Project: Infinispan
> Issue Type: Task
> Components: Test Suite - Query, Test Suite - Server
> Reporter: Sanne Grinovero
> Assignee: Martin Gencur
> Priority: Critical
>
> I just identified ARQ-1964 while debugging a clustered issue, and I think this affects the reliability of many tests in Infinispan.
> The essence is that while you might think you're testing things on containers \{A,B\}, and so doing able to verify the cross-node synchronisations, you're actually always testing couples \{A,A\} or \{B,B\}. It's possible that some things actually don't work as expected even if the tests are passing.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (ISPN-5597) Verify if clustered Arquillian based tests are really clustered
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-5597?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-5597:
------------------------------------
There don't seem to be many tests using `@OperateOnDeployment`, but it would be a good idea to change the defaultProtocol to {{Servlet 3.0}} in all {{arquillian.xml}} files.
> Verify if clustered Arquillian based tests are really clustered
> ---------------------------------------------------------------
>
> Key: ISPN-5597
> URL: https://issues.jboss.org/browse/ISPN-5597
> Project: Infinispan
> Issue Type: Task
> Components: Test Suite - Query, Test Suite - Server
> Reporter: Sanne Grinovero
> Priority: Critical
>
> I just identified ARQ-1964 while debugging a clustered issue, and I think this affects the reliability of many tests in Infinispan.
> The essence is that while you might think you're testing things on containers \{A,B\}, and so doing able to verify the cross-node synchronisations, you're actually always testing couples \{A,A\} or \{B,B\}. It's possible that some things actually don't work as expected even if the tests are passing.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months