[JBoss JIRA] (ISPN-9393) getAsync() and getWithMetadata() does not check NearCache
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-9393?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-9393:
----------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> getAsync() and getWithMetadata() does not check NearCache
> ---------------------------------------------------------
>
> Key: ISPN-9393
> URL: https://issues.jboss.org/browse/ISPN-9393
> Project: Infinispan
> Issue Type: Bug
> Components: Hot Rod, Remote Protocols
> Reporter: Pedro Ruivo
> Assignee: Tristan Tarrant
> Priority: Blocker
> Fix For: 9.4.0.Beta1, 9.4.0.Final
>
>
> In ISPN-8618, the java client was made async.
> However, the {{getAsync()}} method isn't checking the {{NearCache}} anymore.
> EDIT: {{getWithMetadata()}} isn't check the {{NearCache}}. I'm not sure if it is supposed to check it or not.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 5 months
[JBoss JIRA] (ISPN-7956) Investigate removing PartitionHandlingInterceptor
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-7956?page=com.atlassian.jira.plugin.... ]
Radim Vansa updated ISPN-7956:
------------------------------
Fix Version/s: 9.4.0.Final
> Investigate removing PartitionHandlingInterceptor
> -------------------------------------------------
>
> Key: ISPN-7956
> URL: https://issues.jboss.org/browse/ISPN-7956
> Project: Infinispan
> Issue Type: Task
> Components: Core
> Affects Versions: 9.1.0.Beta1
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 9.4.0.Final
>
>
> When all the owners of a key leave the cluster, the distribution interceptor doesn't know how to handle that key. Instead, it has to signal that to the {{PartitionHandlingInterceptor}} somehow, and PHI decides whether to return a {{null}} value or throw an {{AvailabilityException}}.
> Single-key read commands and write commands are handled by throwing an {{AllOwnersLostException}} (initially an {{RpcException}}) from the distribution interceptor and catching it in {{PartitionHandlingInterceptor}}. If partitioning handling is disabled, the {{AllOwnersLostException}} is instead caught by {{StateTransferInterceptor}}, which returns the {{null}} value (for read commands) or waits for a new topology and retries (for write commands).
> For multi-key read commands the distribution interceptor can't throw an exception, because that would lose the values that were retrieved successfully. For {{GetAllCommand}} we could get away with storing the values in the context, but that wouldn't work for functional commands because they transform the values on the remote node. ISPN-7884 removing the values with missing owners from the result collection, but that means values that are simply missing have to be treated differently, and {{StateTransferInterceptor}} has to iterate through the list of results again in order to remove them.
> It should be simpler to move all the availability checks to the distribution interceptor, and remove the {{PartitionHandlingInterceptor}}. DI already calls some {{PartitionHandlingManager}} methods directly, in order to keep track of partially committed transactions.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 5 months
[JBoss JIRA] (ISPN-8123) Provide multiple server offerings
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-8123?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-8123:
----------------------------------
Fix Version/s: (was: 9.4.0.Final)
> Provide multiple server offerings
> ---------------------------------
>
> Key: ISPN-8123
> URL: https://issues.jboss.org/browse/ISPN-8123
> Project: Infinispan
> Issue Type: Enhancement
> Components: Server
> Affects Versions: 9.1.0.Final
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
>
> In order to reduce the memory footprint of Infinispan in server mode, we need to remove as many of the unnecessary dependencies from the server as possible. Some use-cases require more functionality than others, therefore our intention is to provide the server in two flavours:
> # A "lean" server, that exposes all management operations over JMX and is based on jboss-modules
> # A server based upon widlfly-core, which provides users with standalone/domain modes that they're currently accustomed to as well as DMR operations via the CLI.
> This JIRA is simply a parent issues to keep track of all the sub-tasks required.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 5 months
[JBoss JIRA] (ISPN-8124) Create Lean Infinispan Server
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-8124?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-8124:
----------------------------------
Fix Version/s: (was: 9.4.0.Final)
> Create Lean Infinispan Server
> -----------------------------
>
> Key: ISPN-8124
> URL: https://issues.jboss.org/browse/ISPN-8124
> Project: Infinispan
> Issue Type: Sub-task
> Components: Server
> Affects Versions: 9.1.0.Final
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
>
> We need to create an infinispan server that utilises the minimum number of dependencies during run time. This is in order to reduce the server's memory footprint as much as possible. The resulting server will have the following characteristics:
> * Based upon jboss-modules
> * Compatible with existing standalone configuration
> * Expose management operations via Jolokia
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 5 months
[JBoss JIRA] (ISPN-7889) BaseDistributionInterceptor.remoteGet may cause concurrency issues
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-7889?page=com.atlassian.jira.plugin.... ]
Radim Vansa commented on ISPN-7889:
-----------------------------------
Shoot, we should really address this (in general). When fixing ISPN-8213 I've found another case where we need synchronization (I need to fetch some values and remoteGet would be convenient) but that would cause concurrency issues.
> 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
> Assignee: Dan Berindei
>
> {{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.5.0#75005)
6 years, 5 months
[JBoss JIRA] (ISPN-8213) Functional commands are not replayed in tx on non-read owner
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-8213?page=com.atlassian.jira.plugin.... ]
Radim Vansa commented on ISPN-8213:
-----------------------------------
Transaction recovery is not working correctly either - when the node fetches remote values it applies all functional modifications that are currently in the transaction. When we do a recovery (EntryWrappingInterceptor.wrapEntriesForPrepareAndApply, isReplayEntryWrapping is set) and we remote-fetch a value, we apply **all** modifications (including those that are later in the modifications list).
> Functional commands are not replayed in tx on non-read owner
> ------------------------------------------------------------
>
> Key: ISPN-8213
> URL: https://issues.jboss.org/browse/ISPN-8213
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.1.0.Final
> Reporter: Radim Vansa
> Assignee: Radim Vansa
> Fix For: 9.4.0.Final
>
>
> When a functional command is executed on a node that is rebalancing and is not a read owner, we don't fetch the value (it does not end up in context's looked-up entries) but execute the command remotely in a read-only way.
> The entry should be later written on this node, too, but EWI tries to commit only looked-up entries.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 5 months