[JBoss JIRA] (ISPN-4693) Locks acquired before a partition will never be released
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-4693?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-4693:
-------------------------------
Fix Version/s: 7.0.0.Final
> Locks acquired before a partition will never be released
> --------------------------------------------------------
>
> Key: ISPN-4693
> URL: https://issues.jboss.org/browse/ISPN-4693
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 6.0.2.Final
> Reporter: Erik Salter
> Assignee: Dan Berindei
> Fix For: 7.0.0.Final
>
>
> Consider the following case:
> 1. A prepares a transaction for key K on nodes B and C.
> 2. The primary owner B acquires and registers this lock.
> 3. The cluster partitions and A,C remain in partition one, and B in a separate partition.
> 4. The transaction rolls back. However, since B left the cluster, the rollback will not be sent to B.
> 5. B rejoins the cluster. It still has a lock acquired for key K.
> This can lead to a lock being acquired indefinitely.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 7 months
[JBoss JIRA] (ISPN-4693) Locks acquired before a partition will never be released
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-4693?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-4693:
------------------------------------
I think we would need to introduce a transaction timeout setting as well. We have a {{txTimeout}} in TransactionXaAdapter that comes from the transaction manager, but we need something that works with synchronizations and with the batch TM as well.
We could also reuse the existing {{completedTxTimeout}}.
> Locks acquired before a partition will never be released
> --------------------------------------------------------
>
> Key: ISPN-4693
> URL: https://issues.jboss.org/browse/ISPN-4693
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 6.0.2.Final
> Reporter: Erik Salter
> Assignee: Dan Berindei
> Fix For: 7.0.0.Final
>
>
> Consider the following case:
> 1. A prepares a transaction for key K on nodes B and C.
> 2. The primary owner B acquires and registers this lock.
> 3. The cluster partitions and A,C remain in partition one, and B in a separate partition.
> 4. The transaction rolls back. However, since B left the cluster, the rollback will not be sent to B.
> 5. B rejoins the cluster. It still has a lock acquired for key K.
> This can lead to a lock being acquired indefinitely.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 7 months
[JBoss JIRA] (ISPN-4237) Security manager test QueryAuthorizationTest.testQuery fails
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4237?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4237:
-----------------------------------------------
Vojtech Juranek <vjuranek(a)redhat.com> changed the Status of [bug 1091373|https://bugzilla.redhat.com/show_bug.cgi?id=1091373] from ON_QA to ASSIGNED
> Security manager test QueryAuthorizationTest.testQuery fails
> ------------------------------------------------------------
>
> Key: ISPN-4237
> URL: https://issues.jboss.org/browse/ISPN-4237
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Core
> Affects Versions: 7.0.0.Alpha3
> Reporter: Vojtech Juranek
> Assignee: Dan Berindei
> Labels: testsuite_stability
> Fix For: 7.0.0.Alpha5
>
> Attachments: QueryAuthorizationTest.log.zip
>
>
> {{org.infinispan.security.QueryAuthorizationTest.testQuery}} fails (no matter which JDK is used) with
> {noformat}
> java.lang.IllegalArgumentException: Indexing was not enabled on this cache. interface org.hibernate.search.spi.SearchFactoryIntegrator not found in registry
> at org.infinispan.query.impl.ComponentRegistryUtils.getComponent(ComponentRegistryUtils.java:27)
> at org.infinispan.query.impl.ComponentRegistryUtils.getComponent(ComponentRegistryUtils.java:20)
> at org.infinispan.query.impl.SearchManagerImpl.<init>(SearchManagerImpl.java:42)
> at org.infinispan.query.Search.getSearchManager(Search.java:21)
> at org.infinispan.security.QueryAuthorizationTest.queryTest(QueryAuthorizationTest.java:97)
> at org.infinispan.security.QueryAuthorizationTest.access$300(QueryAuthorizationTest.java:32)
> at org.infinispan.security.QueryAuthorizationTest$4.run(QueryAuthorizationTest.java:113)
> at org.infinispan.security.QueryAuthorizationTest$4.run(QueryAuthorizationTest.java:109)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:415)
> at org.infinispan.security.QueryAuthorizationTest.testQuery(QueryAuthorizationTest.java:109)
> {noformat}
> Example of test failure in Jenkins on RHEL6 and Oracle JDK 7 is e.g. [here|https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/edg-60-ispn-tes...].
> Maybe it's some setup issue, as on Jenkins it fails on all platforms, while I;m not able to reproduce it on my machine.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 7 months
[JBoss JIRA] (ISPN-4406) Stabilise security manager integration testsuite
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4406?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4406:
-----------------------------------------------
Vojtech Juranek <vjuranek(a)redhat.com> changed the Status of [bug 1091373|https://bugzilla.redhat.com/show_bug.cgi?id=1091373] from ON_QA to ASSIGNED
> Stabilise security manager integration testsuite
> ------------------------------------------------
>
> Key: ISPN-4406
> URL: https://issues.jboss.org/browse/ISPN-4406
> Project: Infinispan
> Issue Type: Bug
> Components: Security
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 7.0.0.Alpha5
>
>
> integrationtests/security-manager-it tests randomly fail, which might be related to the fact that a lot of these tests rely on static initialisation, and I think that's causing messing up between tests initialising/uninitialising these static variables. The fact that the errors are random seems to back this up.
> However, enabling sequential testing results in:
> {code}[ERROR] java.lang.SecurityException: ISPN000287: Unauthorized access: subject 'null' lacks 'LIFECYCLE' permission
> [ERROR] at org.infinispan.security.impl.AuthorizationHelper.checkPermission(AuthorizationHelper.java:56)
> [ERROR] at org.infinispan.security.impl.AuthorizationHelper.checkPermission(AuthorizationHelper.java:70)
> [ERROR] at org.infinispan.security.impl.AuthorizationHelper.checkPermission(AuthorizationHelper.java:75)
> [ERROR] at org.infinispan.manager.DefaultCacheManager.getStatus(DefaultCacheManager.java:677)
> [ERROR] at org.infinispan.test.fwk.TestCacheManagerFactory$PerThreadCacheManagers.checkManagersClosed(TestCacheManagerFactory.java:435)
> [ERROR] at org.infinispan.test.fwk.TestCacheManagerFactory.testFinished(TestCacheManagerFactory.java:422)
> [ERROR] at org.infinispan.test.fwk.UnitTestTestNGListener.onFinish(UnitTestTestNGListener.java:104){code}
> This error is also present in paralell testing but in this case it's just logged rather than halting the process.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 7 months
[JBoss JIRA] (ISPN-4694) Apply ASYNC backend indexing options to the RemoteIndexingBackend
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-4694?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero updated ISPN-4694:
----------------------------------
Description:
The {{RemoteIndexingBackend}} in Infinispan Query generates synchronous RPCs.
There is an option in Hibernate Search to enable the "async" worker, which decouples the indexing queue processing from the invoker by using a separate executor.
If this option is enabled, we should transparently apply it to the {{RemoteIndexingBackend}} too by making RPCs non blocking as well.
{code}rpcManager.getDefaultRpcOptions(sync){code}
was:
The {{RemoteIndexingBackend}} in Infinispan Query generates synchronous RPCs.
There is an option in Hibernate Search to enable the "async" worker, which decouples the indexing queue processing from the invoker by using a separate executor.
If this option is enabled, we should transparently apply it to the {{RemoteIndexingBackend}} too by making RPCs non blocking as well.
> Apply ASYNC backend indexing options to the RemoteIndexingBackend
> -----------------------------------------------------------------
>
> Key: ISPN-4694
> URL: https://issues.jboss.org/browse/ISPN-4694
> Project: Infinispan
> Issue Type: Feature Request
> Components: Embedded Querying
> Reporter: Sanne Grinovero
> Assignee: Gustavo Fernandes
> Fix For: 7.0.0.Beta2, 7.0.0.Final
>
>
> The {{RemoteIndexingBackend}} in Infinispan Query generates synchronous RPCs.
> There is an option in Hibernate Search to enable the "async" worker, which decouples the indexing queue processing from the invoker by using a separate executor.
> If this option is enabled, we should transparently apply it to the {{RemoteIndexingBackend}} too by making RPCs non blocking as well.
> {code}rpcManager.getDefaultRpcOptions(sync){code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 7 months
[JBoss JIRA] (ISPN-4694) Apply ASYNC backend indexing options to the RemoteIndexingBackend
by Sanne Grinovero (JIRA)
Sanne Grinovero created ISPN-4694:
-------------------------------------
Summary: Apply ASYNC backend indexing options to the RemoteIndexingBackend
Key: ISPN-4694
URL: https://issues.jboss.org/browse/ISPN-4694
Project: Infinispan
Issue Type: Feature Request
Components: Embedded Querying
Reporter: Sanne Grinovero
Assignee: Gustavo Fernandes
Fix For: 7.0.0.Beta2, 7.0.0.Final
The RemoteIndexingBackend in Infinispan Query generates synchronous RPCs.
There is an option in Hibernate Search to enable the "async" worker, which decouples the indexing queue processing from the invoker by using a separate executor.
If this option is enabled, we should transparently apply it to the {{RemoteIndexingBackend}} too by making RPCs non blocking as well.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 7 months
[JBoss JIRA] (ISPN-4694) Apply ASYNC backend indexing options to the RemoteIndexingBackend
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-4694?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero updated ISPN-4694:
----------------------------------
Description:
The {{RemoteIndexingBackend}} in Infinispan Query generates synchronous RPCs.
There is an option in Hibernate Search to enable the "async" worker, which decouples the indexing queue processing from the invoker by using a separate executor.
If this option is enabled, we should transparently apply it to the {{RemoteIndexingBackend}} too by making RPCs non blocking as well.
was:
The RemoteIndexingBackend in Infinispan Query generates synchronous RPCs.
There is an option in Hibernate Search to enable the "async" worker, which decouples the indexing queue processing from the invoker by using a separate executor.
If this option is enabled, we should transparently apply it to the {{RemoteIndexingBackend}} too by making RPCs non blocking as well.
> Apply ASYNC backend indexing options to the RemoteIndexingBackend
> -----------------------------------------------------------------
>
> Key: ISPN-4694
> URL: https://issues.jboss.org/browse/ISPN-4694
> Project: Infinispan
> Issue Type: Feature Request
> Components: Embedded Querying
> Reporter: Sanne Grinovero
> Assignee: Gustavo Fernandes
> Fix For: 7.0.0.Beta2, 7.0.0.Final
>
>
> The {{RemoteIndexingBackend}} in Infinispan Query generates synchronous RPCs.
> There is an option in Hibernate Search to enable the "async" worker, which decouples the indexing queue processing from the invoker by using a separate executor.
> If this option is enabled, we should transparently apply it to the {{RemoteIndexingBackend}} too by making RPCs non blocking as well.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 7 months
[JBoss JIRA] (ISPN-4693) Locks acquired before a partition will never be released
by Erik Salter (JIRA)
[ https://issues.jboss.org/browse/ISPN-4693?page=com.atlassian.jira.plugin.... ]
Erik Salter commented on ISPN-4693:
-----------------------------------
A simple, brute-force solution is to periodically walk the TransactionTable and compare the active transaction to its creation time. Any transaction that is greater than txTimeout and not completed would be rolled back. (CacheTransaction, etc, would need a field for creation time, which is trivial to add).
> Locks acquired before a partition will never be released
> --------------------------------------------------------
>
> Key: ISPN-4693
> URL: https://issues.jboss.org/browse/ISPN-4693
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 6.0.2.Final
> Reporter: Erik Salter
> Assignee: Dan Berindei
>
> Consider the following case:
> 1. A prepares a transaction for key K on nodes B and C.
> 2. The primary owner B acquires and registers this lock.
> 3. The cluster partitions and A,C remain in partition one, and B in a separate partition.
> 4. The transaction rolls back. However, since B left the cluster, the rollback will not be sent to B.
> 5. B rejoins the cluster. It still has a lock acquired for key K.
> This can lead to a lock being acquired indefinitely.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 7 months