July 2016 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-6242) Upgrade to CDI 1.2 and use only Annotated Beans Discovery

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/ISPN-6242?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec updated ISPN-6242: -------------------------------------- Status: Open (was: New) > Upgrade to CDI 1.2 and use only Annotated Beans Discovery > --------------------------------------------------------- > > Key: ISPN-6242 > URL: https://issues.jboss.org/browse/ISPN-6242 > Project: Infinispan > Issue Type: Task > Components: CDI Integration > Reporter: Sebastian Łaskawiec > Assignee: Sebastian Łaskawiec > Priority: Minor > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6242) Upgrade to CDI 1.2 and use only Annotated Beans Discovery

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/ISPN-6242?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec updated ISPN-6242: -------------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/4463 > Upgrade to CDI 1.2 and use only Annotated Beans Discovery > --------------------------------------------------------- > > Key: ISPN-6242 > URL: https://issues.jboss.org/browse/ISPN-6242 > Project: Infinispan > Issue Type: Task > Components: CDI Integration > Reporter: Sebastian Łaskawiec > Assignee: Sebastian Łaskawiec > Priority: Minor > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[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)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6858) Prepare a plan for refactoring server parser and writer part

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-6858?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-6858: ---------------------------------- Fix Version/s: 9.0.0.Alpha4 9.0.0.Final > Prepare a plan for refactoring server parser and writer part > ------------------------------------------------------------ > > Key: ISPN-6858 > URL: https://issues.jboss.org/browse/ISPN-6858 > Project: Infinispan > Issue Type: Task > Reporter: Sebastian Łaskawiec > Assignee: Tristan Tarrant > Priority: Optional > Fix For: 9.0.0.Alpha4, 9.0.0.Final > > > Our Server Parser/Writer code doesn't look nice and has lots and lots of duplication. We should prepare a plan how to refactor it (and possibly distribute tasks all over the team). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6858) Prepare a plan for refactoring server parser and writer part

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-6858?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-6858: ---------------------------------- Status: Open (was: New) > Prepare a plan for refactoring server parser and writer part > ------------------------------------------------------------ > > Key: ISPN-6858 > URL: https://issues.jboss.org/browse/ISPN-6858 > Project: Infinispan > Issue Type: Task > Reporter: Sebastian Łaskawiec > Assignee: Ryan Emerson > Priority: Optional > > Our Server Parser/Writer code doesn't look nice and has lots and lots of duplication. We should prepare a plan how to refactor it (and possibly distribute tasks all over the team). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6858) Prepare a plan for refactoring server parser and writer part

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-6858?page=com.atlassian.jira.plugin.... ] Tristan Tarrant reassigned ISPN-6858: ------------------------------------- Assignee: Tristan Tarrant (was: Ryan Emerson) > Prepare a plan for refactoring server parser and writer part > ------------------------------------------------------------ > > Key: ISPN-6858 > URL: https://issues.jboss.org/browse/ISPN-6858 > Project: Infinispan > Issue Type: Task > Reporter: Sebastian Łaskawiec > Assignee: Tristan Tarrant > Priority: Optional > > Our Server Parser/Writer code doesn't look nice and has lots and lots of duplication. We should prepare a plan how to refactor it (and possibly distribute tasks all over the team). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6858) Prepare a plan for refactoring server parser and writer part

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-6858?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-6858: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/4461 > Prepare a plan for refactoring server parser and writer part > ------------------------------------------------------------ > > Key: ISPN-6858 > URL: https://issues.jboss.org/browse/ISPN-6858 > Project: Infinispan > Issue Type: Task > Reporter: Sebastian Łaskawiec > Assignee: Tristan Tarrant > Priority: Optional > > Our Server Parser/Writer code doesn't look nice and has lots and lots of duplication. We should prepare a plan how to refactor it (and possibly distribute tasks all over the team). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[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)

9 years, 8 months

1
0
0 / 0

[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)

9 years, 8 months

1
0
0 / 0

[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)

9 years, 8 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues July 2016