[JBoss JIRA] (ISPN-7114) Consistency checker
by Vittorio Rigamonti (JIRA)
[ https://issues.jboss.org/browse/ISPN-7114?page=com.atlassian.jira.plugin.... ]
Vittorio Rigamonti updated ISPN-7114:
-------------------------------------
Fix Version/s: (was: 9.1.0.Beta1)
> Consistency checker
> -------------------
>
> Key: ISPN-7114
> URL: https://issues.jboss.org/browse/ISPN-7114
> Project: Infinispan
> Issue Type: Feature Request
> Components: Core
> Reporter: Tristan Tarrant
> Assignee: Ryan Emerson
> Fix For: 9.1.0.Final
>
>
> We should implement a consistency checker that can either be run on demand via management (e.g. JMX) or triggered by a merge or a topology change caused by abrupt leavers. It should perform per-segment analysis of each key/value pair between primary and backup. The design should incorporate pluggable repair strategies (e.g. latest wins, primary wins, discard, degrade segment, custom)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (ISPN-7889) BaseDistributionInterceptor.remoteGet may cause concurrency issues
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-7889?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-7889:
------------------------------------
You're right, {{beforeGet}} is not thread-safe, and neither is its {{thenApply()}} callback.
I wonder if we need a method {{InvocationStage.afterBothAccept(InvocationStage, InvocationContext, VisitableCommand, InvocationSuccessAction)}} to emulate {{CompletableFuture.allOf}}, something like this:
{code}
InvocationStage remoteGet(..., InvocationStage previousRemoteGet) {
...
return makeStage(asyncValue(rpcManager.invokeRemotely(...)).afterBothAccept(previousRemoteGet, ctx, command, this::storeRemoteValueInContext));
}
{code}
OTOH this is exactly the kind of thing I had in mind in ISPN-6971 when I made the calls to {{ResponseCollector}} methods protected by a lock, so if possible I'd use something like {{Transport.invokeCommands()}} (the corresponding {{RpcManager}} method doesn't exist yet) and save the entries in the context in the {{ResponseCollector}} implementation.
Multiple invocations could also share the same collector, but then you have to somehow cancel the collector after the first exception. Or you could cache the exception in the collector, and only throw it after you got a reply from all the targets...
> BaseDistributionInterceptor.remoteGet may cause concurrency issues
> ------------------------------------------------------------------
>
> Key: ISPN-7889
> URL: https://issues.jboss.org/browse/ISPN-7889
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.1.0.Alpha1
> Reporter: Radim Vansa
>
> {{BaseDistributionInterceptor.remoteGet}} or any call that accesses the context in an async future handler that is called multiple times in parallel may lead to concurrent modifications of the context.
> These calls are usually handled using {{CompletableFuture.allOf()}} or using a CF with counter, but if one of the calls results in exceptional completion of the composed future, the processing continues (e.g. with a retry). The other parallel operation handlers are not stopped, though.
> {{BaseDistributionInterceptor.remoteGet}} shouldn't be called in parallel because it does not even synchronize regular successful invocations.
> A problem like this caused failures in {{GetAllCommandStressTest}}, and the issue was addressed for {{GetAllCommand}} in ISPN-7884.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (ISPN-7933) Investigate moving the request id from a message header to the buffer
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-7933?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo commented on ISPN-7933:
-----------------------------------
I would go for a {{InfinispanHeader}} with request-id + cache-name for the following reasons:
* remove the cache name from commands
* remove {{CacheRpcCommand}}
* Debug info in JGroups protocol
* don't interact with marshaller (lookup externalizers)
* we know what cache we are going to hit before unmarshall the command
* we may possible do some application batch without repeating the cache-name
The only disadvantage is we need to add the {{ByteString}} to the {{invokeCommand*}} methods in {{Transport}} (when null, assume a global command)
> Investigate moving the request id from a message header to the buffer
> ---------------------------------------------------------------------
>
> Key: ISPN-7933
> URL: https://issues.jboss.org/browse/ISPN-7933
> Project: Infinispan
> Issue Type: Task
> Components: Core
> Affects Versions: 9.1.0.Alpha1
> Reporter: Dan Berindei
> Assignee: Dan Berindei
>
> The ISPN-6971 pull request removes the usage of JGroups' {{MessageDispatcher}}, but keeps using {{RequestCorrelator.Header}} to put the request id in the message. We could eliminate the header allocation and put the request id in the buffer.
> OTOH having a separate header means the request id is visible in the logs of various JGroups protocols, so we may want to only replace {{RequestCorrelator.Header}} with our own header class.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (ISPN-7901) Postgres drop-on-exit remove index fails
by Ryan Emerson (JIRA)
[ https://issues.jboss.org/browse/ISPN-7901?page=com.atlassian.jira.plugin.... ]
Ryan Emerson updated ISPN-7901:
-------------------------------
Fix Version/s: 9.0.2.Final
> Postgres drop-on-exit remove index fails
> ----------------------------------------
>
> Key: ISPN-7901
> URL: https://issues.jboss.org/browse/ISPN-7901
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 9.1.0.Alpha1
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Fix For: 9.0.2.Final, 9.1.0.Beta1
>
>
> When drop-on-exit is true and indexing is enabled the following error occurs:
> {code:java}
> ERROR: ISPN008011: Error while creating table; used DDL statement: 'DROP INDEX "test_table_postgres_timestamp_index" ON "test_table_postgres"'
> org.postgresql.util.PSQLException: ERROR: syntax error at or near "ON"
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (ISPN-7114) Consistency checker
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-7114?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-7114:
----------------------------------
Fix Version/s: 9.1.0.Beta1
> Consistency checker
> -------------------
>
> Key: ISPN-7114
> URL: https://issues.jboss.org/browse/ISPN-7114
> Project: Infinispan
> Issue Type: Feature Request
> Components: Core
> Reporter: Tristan Tarrant
> Assignee: Ryan Emerson
> Fix For: 9.1.0.Final, 9.1.0.Beta1
>
>
> We should implement a consistency checker that can either be run on demand via management (e.g. JMX) or triggered by a merge or a topology change caused by abrupt leavers. It should perform per-segment analysis of each key/value pair between primary and backup. The design should incorporate pluggable repair strategies (e.g. latest wins, primary wins, discard, degrade segment, custom)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months