[JBoss JIRA] (ISPN-6868) Expose extra configuration for the SSLContext protocol in the Hot Rod client
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-6868?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes updated ISPN-6868:
------------------------------------
Status: Open (was: New)
> Expose extra configuration for the SSLContext protocol in the Hot Rod client
> ----------------------------------------------------------------------------
>
> Key: ISPN-6868
> URL: https://issues.jboss.org/browse/ISPN-6868
> Project: Infinispan
> Issue Type: Bug
> Components: Security
> Affects Versions: 9.0.0.Alpha3, 8.2.3.Final
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
>
> Currently in the HotRod client the {{SSLContext}} is created with the hardcoded "TLS" protocol, and this can only be overriden by providing a whole custom instance of {{SSLContext}} programmatically. We should provide an extra property to change the protocol for the default SSLContext case, allowing it to be supported via properties files
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (ISPN-6745) Locks are lost in pessimistic cache
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-6745?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-6745:
------------------------------
Git Pull Request: https://github.com/infinispan/infinispan/pull/4428, https://github.com/infinispan/infinispan/pull/4460 (was: https://github.com/infinispan/infinispan/pull/4428)
> Locks are lost in pessimistic cache
> -----------------------------------
>
> Key: ISPN-6745
> URL: https://issues.jboss.org/browse/ISPN-6745
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 7.2.3.Final
> Environment: JBoss DataGrid 6.5.0 (6.3.1.Final-redhat-1)
> 3 nodes in REPL_SYNC mode
> pessimistic locking
> read committed isolation
> Reporter: Eugene Scripnik
> Assignee: Pedro Ruivo
> Fix For: 9.0.0.Alpha4, 8.2.4.Final
>
> Attachments: InfinispanNodeFailureTest.java
>
>
> When you perform multiple TX write operations in one transaction (put, replace, lock, etc) and one of the nodes goes down, there is a slight chance that some locks will be lost and acquired by another transaction before current transaction ends.
> So client ends up with two transactions holding the same lock on pessimistic cache at the same time. Both transactions commit at the end successfully.
> I spent some time debugging infinispan code and found that PessimisticLockingInterceptor#releaseLocksOnFailureBeforePrepare releases all locks when OutdatedTopologyException occurs on remote node. But then StateTransferInterceptor#handleTxWriteCommand retries last command. This behavior produces inconsistent state - all locks before last command are released and any other transaction can acquire them.
> I am attaching Test which reproduces this problem
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (ISPN-6869) Deadlock during stopping CacheManager
by Vojtech Juranek (JIRA)
[ https://issues.jboss.org/browse/ISPN-6869?page=com.atlassian.jira.plugin.... ]
Vojtech Juranek updated ISPN-6869:
----------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/4459
> Deadlock during stopping CacheManager
> -------------------------------------
>
> Key: ISPN-6869
> URL: https://issues.jboss.org/browse/ISPN-6869
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.0.0.Alpha3
> Reporter: Vojtech Juranek
> Assignee: Vojtech Juranek
> Attachments: server.log.gz
>
>
> When new cache is started during ISPN shutdown, it can result into a deadlock.
> When new cache is created, first {{DefaultCacheManager.CacheWrapper}} is created with a latch. This latch is release once cache is fully started. If in meantime {{DefaultCacheManager#stop}} is called, it will first stop and lock {{GlobalComponentRegistry}} and after that will try to access and stop all caches. However, if there is present half-created cache (one with latch in {{DefaultCacheManager.CacheWrapper}} not released yet), if will result into a deadlock, as {{cache#start}} tries to access and lock {{GlobalComponentRegistry}}, already lock by {{DefaultCacheManager}}.
> Relevant pieces of stack traces are bellow, whole stack trace is attached.
> Locking of {{GlobalComponentRegistry}} by {{DefaultCacheManager#stop}}:
> {noformat}
> at org.infinispan.factories.AbstractComponentRegistry.stop(AbstractComponentRegistry.java:569)
> - locked <0x00000000e1606fc0> (a org.infinispan.factories.GlobalComponentRegistry)
> at org.infinispan.factories.GlobalComponentRegistry.stop(GlobalComponentRegistry.java:282)
> - locked <0x00000000e1606fc0> (a org.infinispan.factories.GlobalComponentRegistry)
> at org.infinispan.manager.DefaultCacheManager.stop(DefaultCacheManager.java:699)
> - locked <0x00000000e1606bb0> (a org.infinispan.manager.DefaultCacheManager)
> at org.infinispan.manager.impl.AbstractDelegatingEmbeddedCacheManager.stop(AbstractDelegatingEmbeddedCacheManager.java:173)
> {noformat}
> and later of waiting for cache latch:
> {noformat}
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00000000fd59db80> (a java.util.concurrent.CountDownLatch$Sync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231)
> at org.infinispan.manager.DefaultCacheManager$CacheWrapper.getCache(DefaultCacheManager.java:968)
> {noformat}
> Waiting for a lock for {{GlobalComponentRegistry}} when cache is created:
> {noformat}
> at org.infinispan.factories.AbstractComponentRegistry.getOrCreateComponent(AbstractComponentRegistry.java:277)
> - waiting to lock <0x00000000e1606fc0> (a org.infinispan.factories.GlobalComponentRegistry)
> at org.infinispan.factories.GlobalComponentRegistry.getTimeService(GlobalComponentRegistry.java:167)
> at org.infinispan.factories.ComponentRegistry.getTimeService(ComponentRegistry.java:271)
> at org.infinispan.distexec.DefaultExecutorService.<init>(DefaultExecutorService.java:190)
> [...]
> org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:636)
> at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:587)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:452)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:438)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (ISPN-6869) Deadlock during stopping CacheManager
by Vojtech Juranek (JIRA)
[ https://issues.jboss.org/browse/ISPN-6869?page=com.atlassian.jira.plugin.... ]
Vojtech Juranek updated ISPN-6869:
----------------------------------
Status: Open (was: New)
> Deadlock during stopping CacheManager
> -------------------------------------
>
> Key: ISPN-6869
> URL: https://issues.jboss.org/browse/ISPN-6869
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.0.0.Alpha3
> Reporter: Vojtech Juranek
> Assignee: Vojtech Juranek
> Attachments: server.log.gz
>
>
> When new cache is started during ISPN shutdown, it can result into a deadlock.
> When new cache is created, first {{DefaultCacheManager.CacheWrapper}} is created with a latch. This latch is release once cache is fully started. If in meantime {{DefaultCacheManager#stop}} is called, it will first stop and lock {{GlobalComponentRegistry}} and after that will try to access and stop all caches. However, if there is present half-created cache (one with latch in {{DefaultCacheManager.CacheWrapper}} not released yet), if will result into a deadlock, as {{cache#start}} tries to access and lock {{GlobalComponentRegistry}}, already lock by {{DefaultCacheManager}}.
> Relevant pieces of stack traces are bellow, whole stack trace is attached.
> Locking of {{GlobalComponentRegistry}} by {{DefaultCacheManager#stop}}:
> {noformat}
> at org.infinispan.factories.AbstractComponentRegistry.stop(AbstractComponentRegistry.java:569)
> - locked <0x00000000e1606fc0> (a org.infinispan.factories.GlobalComponentRegistry)
> at org.infinispan.factories.GlobalComponentRegistry.stop(GlobalComponentRegistry.java:282)
> - locked <0x00000000e1606fc0> (a org.infinispan.factories.GlobalComponentRegistry)
> at org.infinispan.manager.DefaultCacheManager.stop(DefaultCacheManager.java:699)
> - locked <0x00000000e1606bb0> (a org.infinispan.manager.DefaultCacheManager)
> at org.infinispan.manager.impl.AbstractDelegatingEmbeddedCacheManager.stop(AbstractDelegatingEmbeddedCacheManager.java:173)
> {noformat}
> and later of waiting for cache latch:
> {noformat}
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00000000fd59db80> (a java.util.concurrent.CountDownLatch$Sync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231)
> at org.infinispan.manager.DefaultCacheManager$CacheWrapper.getCache(DefaultCacheManager.java:968)
> {noformat}
> Waiting for a lock for {{GlobalComponentRegistry}} when cache is created:
> {noformat}
> at org.infinispan.factories.AbstractComponentRegistry.getOrCreateComponent(AbstractComponentRegistry.java:277)
> - waiting to lock <0x00000000e1606fc0> (a org.infinispan.factories.GlobalComponentRegistry)
> at org.infinispan.factories.GlobalComponentRegistry.getTimeService(GlobalComponentRegistry.java:167)
> at org.infinispan.factories.ComponentRegistry.getTimeService(ComponentRegistry.java:271)
> at org.infinispan.distexec.DefaultExecutorService.<init>(DefaultExecutorService.java:190)
> [...]
> org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:636)
> at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:587)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:452)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:438)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (ISPN-6869) Deadlock during stopping CacheManager
by Vojtech Juranek (JIRA)
[ https://issues.jboss.org/browse/ISPN-6869?page=com.atlassian.jira.plugin.... ]
Vojtech Juranek updated ISPN-6869:
----------------------------------
Attachment: server.log.gz
> Deadlock during stopping CacheManager
> -------------------------------------
>
> Key: ISPN-6869
> URL: https://issues.jboss.org/browse/ISPN-6869
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.0.0.Alpha3
> Reporter: Vojtech Juranek
> Assignee: Vojtech Juranek
> Attachments: server.log.gz
>
>
> When new cache is started during ISPN shutdown, it can result into a deadlock.
> When new cache is created, first {{DefaultCacheManager.CacheWrapper}} is created with a latch. This latch is release once cache is fully started. If in meantime {{DefaultCacheManager#stop}} is called, it will first stop and lock {{GlobalComponentRegistry}} and after that will try to access and stop all caches. However, if there is present half-created cache (one with latch in {{DefaultCacheManager.CacheWrapper}} not released yet), if will result into a deadlock, as {{cache#start}} tries to access and lock {{GlobalComponentRegistry}}, already lock by {{DefaultCacheManager}}.
> Relevant pieces of stack traces are bellow, whole stack trace is attached.
> Locking of {{GlobalComponentRegistry}} by {{DefaultCacheManager#stop}}:
> {noformat}
> at org.infinispan.factories.AbstractComponentRegistry.stop(AbstractComponentRegistry.java:569)
> - locked <0x00000000e1606fc0> (a org.infinispan.factories.GlobalComponentRegistry)
> at org.infinispan.factories.GlobalComponentRegistry.stop(GlobalComponentRegistry.java:282)
> - locked <0x00000000e1606fc0> (a org.infinispan.factories.GlobalComponentRegistry)
> at org.infinispan.manager.DefaultCacheManager.stop(DefaultCacheManager.java:699)
> - locked <0x00000000e1606bb0> (a org.infinispan.manager.DefaultCacheManager)
> at org.infinispan.manager.impl.AbstractDelegatingEmbeddedCacheManager.stop(AbstractDelegatingEmbeddedCacheManager.java:173)
> {noformat}
> and later of waiting for cache latch:
> {noformat}
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00000000fd59db80> (a java.util.concurrent.CountDownLatch$Sync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231)
> at org.infinispan.manager.DefaultCacheManager$CacheWrapper.getCache(DefaultCacheManager.java:968)
> {noformat}
> Waiting for a lock for {{GlobalComponentRegistry}} when cache is created:
> {noformat}
> at org.infinispan.factories.AbstractComponentRegistry.getOrCreateComponent(AbstractComponentRegistry.java:277)
> - waiting to lock <0x00000000e1606fc0> (a org.infinispan.factories.GlobalComponentRegistry)
> at org.infinispan.factories.GlobalComponentRegistry.getTimeService(GlobalComponentRegistry.java:167)
> at org.infinispan.factories.ComponentRegistry.getTimeService(ComponentRegistry.java:271)
> at org.infinispan.distexec.DefaultExecutorService.<init>(DefaultExecutorService.java:190)
> [...]
> org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:636)
> at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:587)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:452)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:438)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (ISPN-6868) Expose extra configuration for the SSLContext protocol in the Hot Rod client
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-6868?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes updated ISPN-6868:
------------------------------------
Description:
Currently in the HotRod client the {{SSLContext}} is created with the hardcoded "TLS" protocol, and this can only be overriden by providing a whole custom instance of {{SSLContext}} programmatically. We should provide an extra property to change the protocol for the default SSLContext case, allowing it to be supported via properties files
was:
Currently in the HotRod client the {{SSLContext}} is created with the hardcoded "TLS" protocol, and this can only be overriden by providing a whole custom instance of {{SSLContext}} programmatically. We should provide an extra property to change the protocol for the default SSLContext case, allowing it to be used via properties files
> Expose extra configuration for the SSLContext protocol in the Hot Rod client
> ----------------------------------------------------------------------------
>
> Key: ISPN-6868
> URL: https://issues.jboss.org/browse/ISPN-6868
> Project: Infinispan
> Issue Type: Bug
> Components: Security
> Affects Versions: 9.0.0.Alpha3, 8.2.3.Final
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
>
> Currently in the HotRod client the {{SSLContext}} is created with the hardcoded "TLS" protocol, and this can only be overriden by providing a whole custom instance of {{SSLContext}} programmatically. We should provide an extra property to change the protocol for the default SSLContext case, allowing it to be supported via properties files
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months