[JBoss JIRA] (ISPN-7536) JDBCMigrator is unable to read 8.x tables due to marshaller changes
by Ryan Emerson (JIRA)
Ryan Emerson created ISPN-7536:
----------------------------------
Summary: JDBCMigrator is unable to read 8.x tables due to marshaller changes
Key: ISPN-7536
URL: https://issues.jboss.org/browse/ISPN-7536
Project: Infinispan
Issue Type: Bug
Components: Loaders and Stores
Affects Versions: 9.0.0.CR2
Reporter: Ryan Emerson
Assignee: Ryan Emerson
Fix For: 9.0.0.Final
Due to the marshaller changes introduced in Infinispan 9, store records from Infinispan 8.x are no longer compatible. Consequently the JDBCMigrator currently only allows migration between 9.x JDBC stores, which isn't very useful.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (ISPN-5654) Make DeadlockDetectingLockManager aware of single-node locking
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-5654?page=com.atlassian.jira.plugin.... ]
Dan Berindei edited comment on ISPN-5654 at 2/28/17 8:46 AM:
-------------------------------------------------------------
-Looking at the code, the deadlock detection doesn't seem to work at all in most cases. Lock intentions are only added in {{DeadlockDetectingLockManager.lock(key)}}, which doesn't get called on the transaction originator unless it's also the primary owner of the key. Thus lock intentions are never sent from the tx originator to the primary owners, and deadlock detection for multiple keys only works when all the keys are owned by the originator.- And of course, same-key deadlocks cannot happen at all with the single-node locking.
-I propose to remove {{DeadlockDetectingLockManager}} altogether and to deprecate the related configuration.-
-Update: I had missed {{DeadlockDetectingInterceptor}}, which does add remote lock intentions on the originator for all the locked keys. So deadlock detection should work, both with pessimistic locking and with optimistic locking, although the number of deadlocks should be much smaller with single-node locking.-
was (Author: dan.berindei):
-Looking at the code, the deadlock detection doesn't seem to work at all in most cases. Lock intentions are only added in {{DeadlockDetectingLockManager.lock(key)}}, which doesn't get called on the transaction originator unless it's also the primary owner of the key. Thus lock intentions are never sent from the tx originator to the primary owners, and deadlock detection for multiple keys only works when all the keys are owned by the originator.- And of course, same-key deadlocks cannot happen at all with the single-node locking.
-I propose to remove {{DeadlockDetectingLockManager}} altogether and to deprecate the related configuration.-
Update: I had missed {{DeadlockDetectingInterceptor}}, which does add remote lock intentions on the originator for all the locked keys. So deadlock detection should work, both with pessimistic locking and with optimistic locking, although the number of deadlocks should be much smaller with single-node locking.
> Make DeadlockDetectingLockManager aware of single-node locking
> --------------------------------------------------------------
>
> Key: ISPN-5654
> URL: https://issues.jboss.org/browse/ISPN-5654
> Project: Infinispan
> Issue Type: Task
> Components: Core
> Affects Versions: 8.0.0.Beta2
> Reporter: Dan Berindei
>
> {{DeadlockDetectingLockManager}} seems to assume that the node that started a transaction acquires a local lock before replicating, which is wrong since we switched to locking only on the primary owner.
> In particular, {{isSameKeyDeadlock}} can probably be removed altogether.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (ISPN-5654) Make DeadlockDetectingLockManager aware of single-node locking
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-5654?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-5654:
------------------------------------
Update 2: {{DeadlockDetectingInterceptor}} does set the remote lock intention, but the externalizer doesn't include it in the payload, instead it is reconstructed from the remote command, e.g. for a {{LockControlCommand}} it only includes the key(s) being locked. The collection of keys already acquired ({{locksAtOrigin}}) does get replicated, but it doesn't include keys for which the origin is not the primary owner, so DDLM will only detect a small fraction of the deadlocks with pessimistic locking. This is easy enough to fix, but the benefit from deadlock detection is quite small here, as users can and should modify their transactions to acquire locks in the same order and avoid deadlocks.
With optimistic locking, {{CommandsFactoryImpl}} overwrites the {{locksAtOrigin}} collection on the remote node with {{PrepareCommand.getAffectedKeys()}}, which can cause false positives (in effect shortening the lock acquisition timeout to {{spinDuration}}). E.g. if tx1 and tx2 both want to write k1 (primary owner A) and k2 (primary owner B), when tx1 can't acquire lock k1 on A after {{spinDuration}} millis, DDLM will assume there's a deadlock, even if tx1 and tx2 weren't actually blocking each other and they could have executed successfully. In theory we could add a round of communication between the remote nodes executing the {{PrepareCommand}} to gather the actual locked keys and detect deadlocks without false positives, but that would certainly add complexity.
In conclusion, I'm going back removing {{DeadlockDetectingLockManager}}.
> Make DeadlockDetectingLockManager aware of single-node locking
> --------------------------------------------------------------
>
> Key: ISPN-5654
> URL: https://issues.jboss.org/browse/ISPN-5654
> Project: Infinispan
> Issue Type: Task
> Components: Core
> Affects Versions: 8.0.0.Beta2
> Reporter: Dan Berindei
>
> {{DeadlockDetectingLockManager}} seems to assume that the node that started a transaction acquires a local lock before replicating, which is wrong since we switched to locking only on the primary owner.
> In particular, {{isSameKeyDeadlock}} can probably be removed altogether.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (ISPN-7070) CacheNotifierImplInitialTransferDistTest.testIterationBeganAndSegmentNotComplete random failures
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-7070?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-7070:
------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> CacheNotifierImplInitialTransferDistTest.testIterationBeganAndSegmentNotComplete random failures
> ------------------------------------------------------------------------------------------------
>
> Key: ISPN-7070
> URL: https://issues.jboss.org/browse/ISPN-7070
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Test Suite - Core
> Affects Versions: 9.0.0.Alpha4
> Reporter: Dan Berindei
> Assignee: William Burns
> Priority: Critical
> Labels: testsuite_stability
> Fix For: 9.0.0.Final
>
> Attachments: CacheNotifierImplInitialTransferDistTest_ISPN-5467_CompletableFuture-like_API_20161003.log
>
>
> Looks like sometimes the originator listener ignores the CACHE_ENTRY_REMOVED notification:
> {noformat}
> 09:58:57,877 INFO (testng-Test:[]) [TestSuiteProgress] Test starting: org.infinispan.notifications.cachelistener.CacheNotifierImplInitialTransferDistTest.testRemoveAfterIterationBeganAndSegmentNotCompleteValueNonOwnerClustered
> 09:58:58,913 DEBUG (testng-Test:[]) [Test] Found key key-to-change-0 with primary owner != Test-NodeA-7051, segment 60
> 09:58:58,930 TRACE (remote-thread-Test-NodeA-p23726-t6:[]) [ReadCommittedEntry] Updating entry (key=key-to-change-0 removed=false valid=true changed=true created=true value=initial-value metadata=EmbeddedExpirableMetadata{lifespan=-1, maxIdle=-1, version=null}, providedMetadata=EmbeddedExpirableMetadata{lifespan=-1, maxIdle=-1, version=null})
> 09:58:58,972 TRACE (remote-thread-Test-NodeC-p23887-t6:[]) [ReadCommittedEntry] Updating entry (key=key-to-change-0 removed=false valid=true changed=true created=true value=initial-value metadata=EmbeddedExpirableMetadata{lifespan=-1, maxIdle=-1, version=null}, providedMetadata=EmbeddedExpirableMetadata{lifespan=-1, maxIdle=-1, version=null})
> 09:58:59,014 TRACE (ForkThread-1,Test:[]) [Test] Adding segment listener 2a41ec3f-c79f-4b7d-bd0e-8754170d8fc1 : org.infinispan.notifications.cachelistener.DistributedQueueingSegmentListener@68007f8
> 09:58:59,014 TRACE (ForkThread-1,Test:[]) [CacheNotifierImpl] Replicating cluster listener to other nodes [Test-NodeA-7051, Test-NodeB-10318, Test-NodeC-52778] for cluster listener with id 2a41ec3f-c79f-4b7d-bd0e-8754170d8fc1
> 09:58:58,998 TRACE (testng-Test:[]) [CheckPoint] Waiting for event pre_complete_segment_invoked * 1
> 09:58:59,063 TRACE (remote-thread-Test-NodeC-p23887-t6:[]) [ClusterListenerReplicateCallable] Registered local cluster listener for remote cluster listener from origin Test-NodeA-7051 with id 2a41ec3f-c79f-4b7d-bd0e-8754170d8fc1
> 09:58:59,098 TRACE (remote-thread-Test-NodeB-p23775-t6:[]) [ClusterListenerReplicateCallable] Registered local cluster listener for remote cluster listener from origin Test-NodeA-7051 with id 2a41ec3f-c79f-4b7d-bd0e-8754170d8fc1
> 09:58:59,145 TRACE (ForkThread-1,Test:[]) [CacheNotifierImpl] Listener 2a41ec3f-c79f-4b7d-bd0e-8754170d8fc1 requests initial state for cache
> 09:58:59,373 TRACE (ForkThread-1,Test:[]) [Test] Completed segments [48, 2, 229, 118, 71, 72, 233, 60]
> 09:58:59,373 TRACE (ForkThread-1,Test:[]) [Test] Listener received event EventImpl{type=CACHE_ENTRY_CREATED, pre=false, cache=Cache 'DistInitialTransferListener'@Test-NodeA-7051, key=key-to-change-0, value=initial-value, oldValue=null, transaction=null, originLocal=true, transactionSuccessful=false, entries=null, created=false}
> 09:58:59,373 TRACE (ForkThread-1,Test:[]) [Test] Notified for key key-to-change-0
> 09:58:59,373 TRACE (ForkThread-1,Test:[]) [CheckPoint] Triggering event pre_complete_segment_invoked * 1 (available = 1, total = 1)
> 09:58:59,373 TRACE (ForkThread-1,Test:[]) [CheckPoint] Waiting for event pre_complete_segment_released * 1
> 09:58:59,373 TRACE (testng-Test:[]) [CheckPoint] Received event pre_complete_segment_invoked * 1 (available = 0, total = 1)
> 09:58:59,577 TRACE (remote-thread-Test-NodeA-p23726-t6:[]) [ReadCommittedEntry] Updating entry (key=key-to-change-0 removed=true valid=false changed=true created=false value=initial-value metadata=EmbeddedMetadata{version=null}, providedMetadata=null)
> 09:58:59,661 TRACE (remote-thread-Test-NodeC-p23887-t5:[]) [ReadCommittedEntry] Updating entry (key=key-to-change-0 removed=true valid=false changed=true created=false value=initial-value metadata=EmbeddedMetadata{version=null}, providedMetadata=null)
> 09:58:59,661 TRACE (remote-thread-Test-NodeC-p23887-t5:[]) [RequestCorrelator] Test-NodeC-52778: invoking unicast RPC [req-id=91126] on Test-NodeA-7051
> 09:58:59,684 TRACE (OOB-2,Test-NodeA-7051:[]) [RequestCorrelator] calling (org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher) with request 91126
> 09:58:59,779 TRACE (remote-thread-Test-NodeA-p23726-t6:[]) [NonTotalOrderPerCacheInboundInvocationHandler] Calling perform() on DistributedExecuteCommand [cache=Cache 'DistInitialTransferListener'@Test-NodeA-7051, keys=[], callable=org.infinispan.notifications.cachelistener.cluster.ClusterEventCallable@640b0234]
> 09:58:59,780 TRACE (remote-thread-Test-NodeA-p23726-t6:[]) [ClusterEventCallable] Received cluster event(s) [ClusterEvent {type=CACHE_ENTRY_REMOVED, cache=Cache 'DistInitialTransferListener'@Test-NodeA-7051, key=key-to-change-0, value=null, oldValue=initial-value, transaction=null, retryCommand=false, origin=Test-NodeC-52778}], notifying cluster listener with id 2a41ec3f-c79f-4b7d-bd0e-8754170d8fc1
> 09:58:59,837 TRACE (testng-Test:[]) [CheckPoint] Triggering event pre_complete_segment_released * 999999999 (available = 999999999, total = 999999999)
> 09:58:59,837 TRACE (ForkThread-1,Test:[]) [CheckPoint] Received event pre_complete_segment_released * 1 (available = 999999998, total = 999999999)
> 09:58:59,898 TRACE (ForkThread-1,Test:[]) [CacheNotifierImpl] Listener 2a41ec3f-c79f-4b7d-bd0e-8754170d8fc1 initial state for cache completed
> 09:58:59,916 TRACE (remote-thread-Test-NodeB-p23775-t6:[]) [ClusterListenerRemoveCallable] Removing local cluster listener due to parent cluster listener was removed : 2a41ec3f-c79f-4b7d-bd0e-8754170d8fc1
> 09:58:59,921 TRACE (remote-thread-Test-NodeC-p23887-t5:[]) [ClusterListenerRemoveCallable] Removing local cluster listener due to parent cluster listener was removed : 2a41ec3f-c79f-4b7d-bd0e-8754170d8fc1
> 09:58:59,943 ERROR (testng-Test:[]) [TestSuiteProgress] Test failed: org.infinispan.notifications.cachelistener.CacheNotifierImplInitialTransferDistTest.testRemoveAfterIterationBeganAndSegmentNotCompleteValueNonOwnerClustered
> java.lang.AssertionError: expected [12] but found [11]
> {noformat}
> {{CacheNotifierImplInitialTransferDistTest}} also had a different problem: it replaced the {{CacheNotifier}} component with a clone before adding the listener, but replaced it again with the original before removing the listener. Because the listener's uuid was only registered in the clone, {{removeListener}} couldn't find the uuid and disn't try to remove the listener on the other nodes. This meant the listener was leaked, resulting in logs like this:
> {noformat}
> 20:12:04,098 TRACE (remote-thread-Test-NodeB-p24127-t6:[]) [ReadCommittedEntry] Updating entry (key=key-to-change-0 removed=true valid=false changed=true created=false value=initial-value metadata=EmbeddedMetadata{version=null}, providedMetadata=null)
> 20:12:04,099 TRACE (remote-thread-Test-NodeB-p24127-t6:[]) [RemoteClusterListener] Passing Event to manager EventImpl{type=CACHE_ENTRY_REMOVED, pre=false, cache=Cache 'DistInitialTransferListener'@Test-NodeB-56142, key=key-to-change-0, value=null, oldValue=initial-value, transaction=null, originLocal=false, transactionSuccessful=false, entries=null, created=false} to send to Test-NodeA-38047
> 20:12:04,100 TRACE (remote-thread-Test-NodeB-p24127-t6:[]) [RemoteClusterListener] Passing Event to manager EventImpl{type=CACHE_ENTRY_REMOVED, pre=false, cache=Cache 'DistInitialTransferListener'@Test-NodeB-56142, key=key-to-change-0, value=null, oldValue=initial-value, transaction=null, originLocal=false, transactionSuccessful=false, entries=null, created=false} to send to Test-NodeA-38047
> 20:12:04,100 TRACE (remote-thread-Test-NodeB-p24127-t6:[]) [RemoteClusterListener] Passing Event to manager EventImpl{type=CACHE_ENTRY_REMOVED, pre=false, cache=Cache 'DistInitialTransferListener'@Test-NodeB-56142, key=key-to-change-0, value=null, oldValue=initial-value, transaction=null, originLocal=false, transactionSuccessful=false, entries=null, created=false} to send to Test-NodeA-38047
> 20:12:04,100 TRACE (remote-thread-Test-NodeB-p24127-t6:[]) [RemoteClusterListener] Passing Event to manager EventImpl{type=CACHE_ENTRY_REMOVED, pre=false, cache=Cache 'DistInitialTransferListener'@Test-NodeB-56142, key=key-to-change-0, value=null, oldValue=initial-value, transaction=null, originLocal=false, transactionSuccessful=false, entries=null, created=false} to send to Test-NodeA-38047
> 20:12:04,100 TRACE (remote-thread-Test-NodeB-p24127-t6:[]) [RemoteClusterListener] Passing Event to manager EventImpl{type=CACHE_ENTRY_REMOVED, pre=false, cache=Cache 'DistInitialTransferListener'@Test-NodeB-56142, key=key-to-change-0, value=null, oldValue=initial-value, transaction=null, originLocal=false, transactionSuccessful=false, entries=null, created=false} to send to Test-NodeA-38047
> 20:12:04,106 TRACE (remote-thread-Test-NodeA-p24103-t6:[]) [MultiClusterEventCallable] Received multiple cluster event(s) {86f77630-b1bb-4a21-97bb-b03efeae39d6=[ClusterEvent {type=CACHE_ENTRY_REMOVED, cache=Cache 'DistInitialTransferListener'@Test-NodeA-38047, key=key-to-change-0, value=null, oldValue=initial-value, transaction=null, retryCommand=false, origin=Test-NodeB-56142}], 91d05a50-4a35-4e37-8c5c-bffbabc6154b=[ClusterEvent {type=CACHE_ENTRY_REMOVED, cache=Cache 'DistInitialTransferListener'@Test-NodeA-38047, key=key-to-change-0, value=null, oldValue=initial-value, transaction=null, retryCommand=false, origin=Test-NodeB-56142}], ba09480f-c698-431b-8fe6-213f1bdefc7b=[ClusterEvent {type=CACHE_ENTRY_REMOVED, cache=Cache 'DistInitialTransferListener'@Test-NodeA-38047, key=key-to-change-0, value=null, oldValue=initial-value, transaction=null, retryCommand=false, origin=Test-NodeB-56142}], 992da014-0516-4f2a-8093-50ba3b1f358a=[ClusterEvent {type=CACHE_ENTRY_REMOVED, cache=Cache 'DistInitialTransferListener'@Test-NodeA-38047, key=key-to-change-0, value=null, oldValue=initial-value, transaction=null, retryCommand=false, origin=Test-NodeB-56142}], b4eeb9b3-85c4-4ff9-865e-076b7cf93faa=[ClusterEvent {type=CACHE_ENTRY_REMOVED, cache=Cache 'DistInitialTransferListener'@Test-NodeA-38047, key=key-to-change-0, value=null, oldValue=initial-value, transaction=null, retryCommand=false, origin=Test-NodeB-56142}]}
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (ISPN-5654) Make DeadlockDetectingLockManager aware of single-node locking
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-5654?page=com.atlassian.jira.plugin.... ]
Dan Berindei edited comment on ISPN-5654 at 2/28/17 7:06 AM:
-------------------------------------------------------------
-Looking at the code, the deadlock detection doesn't seem to work at all in most cases. Lock intentions are only added in {{DeadlockDetectingLockManager.lock(key)}}, which doesn't get called on the transaction originator unless it's also the primary owner of the key. Thus lock intentions are never sent from the tx originator to the primary owners, and deadlock detection for multiple keys only works when all the keys are owned by the originator.- And of course, same-key deadlocks cannot happen at all with the single-node locking.
-I propose to remove {{DeadlockDetectingLockManager}} altogether and to deprecate the related configuration.-
Update: I had missed {{DeadlockDetectingInterceptor}}, which does add remote lock intentions on the originator for all the locked keys. So deadlock detection should work, both with pessimistic locking and with optimistic locking, although the number of deadlocks should be much smaller with single-node locking.
was (Author: dan.berindei):
-Looking at the code, the deadlock detection doesn't seem to work at all in most cases. Lock intentions are only added in {{DeadlockDetectingLockManager.lock(key)}}, which doesn't get called on the transaction originator unless it's also the primary owner of the key. Thus lock intentions are never sent from the tx originator to the primary owners, and deadlock detection for multiple keys only works when all the keys are owned by the originator. And of course, same-key deadlocks cannot happen at all with the single-node locking.-
I propose to remove {{DeadlockDetectingLockManager}} altogether and to deprecate the related configuration.
> Make DeadlockDetectingLockManager aware of single-node locking
> --------------------------------------------------------------
>
> Key: ISPN-5654
> URL: https://issues.jboss.org/browse/ISPN-5654
> Project: Infinispan
> Issue Type: Task
> Components: Core
> Affects Versions: 8.0.0.Beta2
> Reporter: Dan Berindei
>
> {{DeadlockDetectingLockManager}} seems to assume that the node that started a transaction acquires a local lock before replicating, which is wrong since we switched to locking only on the primary owner.
> In particular, {{isSameKeyDeadlock}} can probably be removed altogether.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (ISPN-7535) Cache creation requires specific permissions when using security manager
by Lin Gao (JIRA)
[ https://issues.jboss.org/browse/ISPN-7535?page=com.atlassian.jira.plugin.... ]
Lin Gao updated ISPN-7535:
--------------------------
Status: Open (was: New)
> Cache creation requires specific permissions when using security manager
> ------------------------------------------------------------------------
>
> Key: ISPN-7535
> URL: https://issues.jboss.org/browse/ISPN-7535
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Reporter: Lin Gao
> Assignee: Ingo Weiss
>
> *org.jboss.as.test.integration.ee.injection.resource.infinispan.InfinispanResourceRefTestCase#test*
> {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=org.jboss.as.test.integration.ee.injection.resource.infinispan.* -Dsecurity.manager}}
> {panel:title=NOTE}
> specify the InfinispanResourceRefTestCase itself will succeed:
> {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=org.jboss.as.test.integration.ee.injection.resource.infinispan.InfinispanResourceRefTestCase -Dsecurity.manager}}
> {panel}
> {code}
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/infinispan-resource-ref.war/WEB-INF/classes <no signer certificates>)" of "null")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> at java.lang.ClassLoader.checkClassLoaderPermission(ClassLoader.java:1528)
> at java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1442)
> at org.infinispan.commons.util.Util.getClassLoaders(Util.java:127)
> at org.infinispan.commons.util.Util.loadClassStrict(Util.java:150)
> at org.infinispan.commons.util.Util.loadClass(Util.java:101)
> at org.infinispan.factories.AbstractComponentRegistry.instantiateFactory(AbstractComponentRegistry.java:359)
> at org.infinispan.factories.AbstractComponentRegistry.createComponentFactoryInternal(AbstractComponentRegistry.java:339)
> at org.infinispan.factories.ComponentRegistry.createComponentFactoryInternal(ComponentRegistry.java:202)
> at org.infinispan.factories.AbstractComponentRegistry.getFactory(AbstractComponentRegistry.java:322)
> at org.infinispan.factories.ComponentRegistry.getFactory(ComponentRegistry.java:183)
> at org.infinispan.factories.AbstractComponentRegistry.getOrCreateComponent(AbstractComponentRegistry.java:288)
> at org.infinispan.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:156)
> at org.infinispan.factories.AbstractComponentRegistry.invokeInjectionMethod(AbstractComponentRegistry.java:241)
> at org.infinispan.factories.AbstractComponentRegistry.access$000(AbstractComponentRegistry.java:70)
> at org.infinispan.factories.AbstractComponentRegistry$Component.injectDependencies(AbstractComponentRegistry.java:815)
> at org.infinispan.factories.AbstractComponentRegistry.registerComponentInternal(AbstractComponentRegistry.java:215)
> at org.infinispan.factories.ComponentRegistry.registerComponentInternal(ComponentRegistry.java:193)
> at org.infinispan.factories.AbstractComponentRegistry.registerComponent(AbstractComponentRegistry.java:170)
> at org.infinispan.factories.AbstractComponentRegistry.getOrCreateComponent(AbstractComponentRegistry.java:295)
> at org.infinispan.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:156)
> at org.infinispan.factories.AbstractComponentRegistry.invokeInjectionMethod(AbstractComponentRegistry.java:241)
> at org.infinispan.factories.AbstractComponentRegistry.access$000(AbstractComponentRegistry.java:70)
> at org.infinispan.factories.AbstractComponentRegistry$Component.injectDependencies(AbstractComponentRegistry.java:815)
> at org.infinispan.factories.AbstractComponentRegistry.registerComponentInternal(AbstractComponentRegistry.java:215)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (ISPN-7535) Cache creation requires specific permissions when using security manager
by Lin Gao (JIRA)
[ https://issues.jboss.org/browse/ISPN-7535?page=com.atlassian.jira.plugin.... ]
Lin Gao updated ISPN-7535:
--------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/4917
> Cache creation requires specific permissions when using security manager
> ------------------------------------------------------------------------
>
> Key: ISPN-7535
> URL: https://issues.jboss.org/browse/ISPN-7535
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Reporter: Lin Gao
> Assignee: Ingo Weiss
>
> *org.jboss.as.test.integration.ee.injection.resource.infinispan.InfinispanResourceRefTestCase#test*
> {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=org.jboss.as.test.integration.ee.injection.resource.infinispan.* -Dsecurity.manager}}
> {panel:title=NOTE}
> specify the InfinispanResourceRefTestCase itself will succeed:
> {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=org.jboss.as.test.integration.ee.injection.resource.infinispan.InfinispanResourceRefTestCase -Dsecurity.manager}}
> {panel}
> {code}
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/infinispan-resource-ref.war/WEB-INF/classes <no signer certificates>)" of "null")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> at java.lang.ClassLoader.checkClassLoaderPermission(ClassLoader.java:1528)
> at java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1442)
> at org.infinispan.commons.util.Util.getClassLoaders(Util.java:127)
> at org.infinispan.commons.util.Util.loadClassStrict(Util.java:150)
> at org.infinispan.commons.util.Util.loadClass(Util.java:101)
> at org.infinispan.factories.AbstractComponentRegistry.instantiateFactory(AbstractComponentRegistry.java:359)
> at org.infinispan.factories.AbstractComponentRegistry.createComponentFactoryInternal(AbstractComponentRegistry.java:339)
> at org.infinispan.factories.ComponentRegistry.createComponentFactoryInternal(ComponentRegistry.java:202)
> at org.infinispan.factories.AbstractComponentRegistry.getFactory(AbstractComponentRegistry.java:322)
> at org.infinispan.factories.ComponentRegistry.getFactory(ComponentRegistry.java:183)
> at org.infinispan.factories.AbstractComponentRegistry.getOrCreateComponent(AbstractComponentRegistry.java:288)
> at org.infinispan.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:156)
> at org.infinispan.factories.AbstractComponentRegistry.invokeInjectionMethod(AbstractComponentRegistry.java:241)
> at org.infinispan.factories.AbstractComponentRegistry.access$000(AbstractComponentRegistry.java:70)
> at org.infinispan.factories.AbstractComponentRegistry$Component.injectDependencies(AbstractComponentRegistry.java:815)
> at org.infinispan.factories.AbstractComponentRegistry.registerComponentInternal(AbstractComponentRegistry.java:215)
> at org.infinispan.factories.ComponentRegistry.registerComponentInternal(ComponentRegistry.java:193)
> at org.infinispan.factories.AbstractComponentRegistry.registerComponent(AbstractComponentRegistry.java:170)
> at org.infinispan.factories.AbstractComponentRegistry.getOrCreateComponent(AbstractComponentRegistry.java:295)
> at org.infinispan.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:156)
> at org.infinispan.factories.AbstractComponentRegistry.invokeInjectionMethod(AbstractComponentRegistry.java:241)
> at org.infinispan.factories.AbstractComponentRegistry.access$000(AbstractComponentRegistry.java:70)
> at org.infinispan.factories.AbstractComponentRegistry$Component.injectDependencies(AbstractComponentRegistry.java:815)
> at org.infinispan.factories.AbstractComponentRegistry.registerComponentInternal(AbstractComponentRegistry.java:215)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (ISPN-5654) Make DeadlockDetectingLockManager aware of single-node locking
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-5654?page=com.atlassian.jira.plugin.... ]
Dan Berindei edited comment on ISPN-5654 at 2/28/17 6:55 AM:
-------------------------------------------------------------
-Looking at the code, the deadlock detection doesn't seem to work at all in most cases. Lock intentions are only added in {{DeadlockDetectingLockManager.lock(key)}}, which doesn't get called on the transaction originator unless it's also the primary owner of the key. Thus lock intentions are never sent from the tx originator to the primary owners, and deadlock detection for multiple keys only works when all the keys are owned by the originator. And of course, same-key deadlocks cannot happen at all with the single-node locking.-
I propose to remove {{DeadlockDetectingLockManager}} altogether and to deprecate the related configuration.
was (Author: dan.berindei):
Looking at the code, the deadlock detection doesn't seem to work at all in most cases. Lock intentions are only added in {{DeadlockDetectingLockManager.lock(key)}}, which doesn't get called on the transaction originator unless it's also the primary owner of the key. Thus lock intentions are never sent from the tx originator to the primary owners, and deadlock detection for multiple keys only works when all the keys are owned by the originator. And of course, same-key deadlocks cannot happen at all with the single-node locking.
I propose to remove {{DeadlockDetectingLockManager}} altogether and to deprecate the related configuration.
> Make DeadlockDetectingLockManager aware of single-node locking
> --------------------------------------------------------------
>
> Key: ISPN-5654
> URL: https://issues.jboss.org/browse/ISPN-5654
> Project: Infinispan
> Issue Type: Task
> Components: Core
> Affects Versions: 8.0.0.Beta2
> Reporter: Dan Berindei
>
> {{DeadlockDetectingLockManager}} seems to assume that the node that started a transaction acquires a local lock before replicating, which is wrong since we switched to locking only on the primary owner.
> In particular, {{isSameKeyDeadlock}} can probably be removed altogether.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month