[JBoss JIRA] (ISPN-7550) Remove TriangleAckInterceptor
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-7550?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-7550:
------------------------------
Status: Open (was: New)
> Remove TriangleAckInterceptor
> -----------------------------
>
> Key: ISPN-7550
> URL: https://issues.jboss.org/browse/ISPN-7550
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Reporter: Pedro Ruivo
> Assignee: Pedro Ruivo
> Fix For: 9.0.0.Final
>
>
> {{TriangleAckInterceptor}} has 2 main goals
> 1. sends the from backup/primary to originator
> 2. in originator, waits for the acks
> ... and has 2 issues:
> 1. if an exception occurs before it, the ack will not be sent!
> 2. waiting for the acks here will add more complexity to the following interceptor if they need the operation outcome.
> So, by removing the interceptor will have:
> 1. acks are sent in inbound handler (where the replies are sent too)
> 2. waiting for ack will happen on {{TriangleDistributionInterceptor}}.
> Other changes:
> * before sending the ack, notify the {{TriangleOrderManager}} that the next command can proceed.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 10 months
[JBoss JIRA] (ISPN-7550) Remove TriangleAckInterceptor
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-7550?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-7550:
------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/4930
> Remove TriangleAckInterceptor
> -----------------------------
>
> Key: ISPN-7550
> URL: https://issues.jboss.org/browse/ISPN-7550
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Reporter: Pedro Ruivo
> Assignee: Pedro Ruivo
> Fix For: 9.0.0.Final
>
>
> {{TriangleAckInterceptor}} has 2 main goals
> 1. sends the from backup/primary to originator
> 2. in originator, waits for the acks
> ... and has 2 issues:
> 1. if an exception occurs before it, the ack will not be sent!
> 2. waiting for the acks here will add more complexity to the following interceptor if they need the operation outcome.
> So, by removing the interceptor will have:
> 1. acks are sent in inbound handler (where the replies are sent too)
> 2. waiting for ack will happen on {{TriangleDistributionInterceptor}}.
> Other changes:
> * before sending the ack, notify the {{TriangleOrderManager}} that the next command can proceed.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 10 months
[JBoss JIRA] (ISPN-7553) Replicated cache with numOwners=1 doesn't send writes to backups
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-7553?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-7553:
-------------------------------
Status: Open (was: New)
> Replicated cache with numOwners=1 doesn't send writes to backups
> ----------------------------------------------------------------
>
> Key: ISPN-7553
> URL: https://issues.jboss.org/browse/ISPN-7553
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.0.0.CR2
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Critical
> Fix For: 9.0.0.Final
>
>
> {{BaseDistributionInterceptor.primaryReturnHandler()}} doesn't replicate writes to the backups if {{cacheConfiguration.clustering().hash().numOwners() == 1}}. That check is incorrect, because a segment can have more owners than configured:
> 1. In a replicated cache, the configured {{numOwners}} is ignored, and all the members are owners.
> 1. Even in a distributed cache, during rebalance, the segments being moved will have more than {{numOwners}} owners.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 10 months
[JBoss JIRA] (ISPN-7554) JGroupsTransport should expose the cluster view information atomically
by Dan Berindei (JIRA)
Dan Berindei created ISPN-7554:
----------------------------------
Summary: JGroupsTransport should expose the cluster view information atomically
Key: ISPN-7554
URL: https://issues.jboss.org/browse/ISPN-7554
Project: Infinispan
Issue Type: Bug
Reporter: Dan Berindei
Assignee: Dan Berindei
Currently the view is updated while holding a lock, but reading the view id, members, or coordinator is done without a lock. This means when a thread sends a request and receives a {{SuspectException}}, it cannot simply wait for a new view before retrying: the initial request may have used the latest view, and only the members list could be outdated (even if read later).
To allow atomically reading the view id and the member list, we should use an immutable structure similar to {{CacheTopology}}.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 10 months
[JBoss JIRA] (ISPN-4984) JdbcStringBasedStore with MySQL sets up column that uses case-insensitive comparisons for keys
by Ryan Emerson (JIRA)
[ https://issues.jboss.org/browse/ISPN-4984?page=com.atlassian.jira.plugin.... ]
Ryan Emerson reassigned ISPN-4984:
----------------------------------
Assignee: Ryan Emerson
> JdbcStringBasedStore with MySQL sets up column that uses case-insensitive comparisons for keys
> ----------------------------------------------------------------------------------------------
>
> Key: ISPN-4984
> URL: https://issues.jboss.org/browse/ISPN-4984
> Project: Infinispan
> Issue Type: Enhancement
> Reporter: Randall Hauch
> Assignee: Ryan Emerson
>
> By default MySQL performs case-insensitive comparisons. This results in a problem when Infinispan entries use Strings that are distinct only in case-sensitive ways, since by default Infinispan's JdbcStringBasedStore (and maybe JdbcBinaryCacheStore) use {{VARCHAR(255)}} for the default {{idColumn}} type.
> This can of course be corrected in the Infinispan configuration. Rather than specifying this (which is equivalent to the default):
> {code}
> <idColumn name="ID_COLUMN" type="VARCHAR(255)"/>
> {code}
> the following can be specified instead:
> {code}
> <idColumn name="ID_COLUMN" type="VARCHAR(255) CHARACTER SET utf8 COLLATE utf8_unicode_ci"/>
> {code}
> This will make MySQL perform case-sensitive comparisons and will work for all string keys.
> This enhancement request asks that the Infinispan JDBC-based stores use this by default so that it works automatically for MySQL users.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 10 months
[JBoss JIRA] (ISPN-4159) DefaultTwoWayKey2StringMapper encodes objects to strings in a manner that is incompatible with string handling of some databases
by Ryan Emerson (JIRA)
[ https://issues.jboss.org/browse/ISPN-4159?page=com.atlassian.jira.plugin.... ]
Ryan Emerson reassigned ISPN-4159:
----------------------------------
Assignee: Ryan Emerson (was: Adrian Nistor)
> DefaultTwoWayKey2StringMapper encodes objects to strings in a manner that is incompatible with string handling of some databases
> --------------------------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-4159
> URL: https://issues.jboss.org/browse/ISPN-4159
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 6.0.0.Final
> Reporter: Adrian Nistor
> Assignee: Ryan Emerson
> Fix For: 9.0.0.Final
>
>
> DefaultTwoWayKey2StringMapper uses two neat tricks.
> 1. it does not encode all supported types, it only encodes non-Strings. Strings are kept unmodified.
> 2. it uses a special prefix (unicode char 0xfeff) to mark which strings were encoded and which are plain.
> Unfortunately some databases, notably MySql, interpret the endianness mark (0xfeff, 0xfffe), convert to native byte order and then drop it.
> This leaves us with no clue the string is not an actual String but an encoded representation of another type. This misinterpretation leads later to ClassCastExceptions in various places in core and user code.
> Proposed fix: get rid of #1 and #2 optimisations. Encode all objects, including Strings and always use the ?n prefix (where n stands for the original type). Drop the 0xFEFF marker prefix.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 10 months
[JBoss JIRA] (ISPN-7469) Administration console - JDBC store elements have the same IDs
by Vladimir Blagojevic (JIRA)
[ https://issues.jboss.org/browse/ISPN-7469?page=com.atlassian.jira.plugin.... ]
Vladimir Blagojevic updated ISPN-7469:
--------------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 9.0.0.Final
Resolution: Done
> Administration console - JDBC store elements have the same IDs
> --------------------------------------------------------------
>
> Key: ISPN-7469
> URL: https://issues.jboss.org/browse/ISPN-7469
> Project: Infinispan
> Issue Type: Bug
> Components: JMX, reporting and management
> Affects Versions: 9.0.0.CR1
> Reporter: Roman Macor
> Assignee: Ryan Emerson
> Fix For: 9.0.0.Final
>
>
> Some elements have the same IDs.
> Steps to reproduce:
> Click on cache container -> cache -> configuration -> store -> select String keyed JDBC store -> click on String keyed table -> several input elements have the same ID
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 10 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: Pull Request Sent)
> 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
(v7.2.3#72005)
7 years, 10 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, https://github.com/infinispan/infinispan/pull/4929 (was: 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
(v7.2.3#72005)
7 years, 10 months