[JBoss JIRA] (ISPN-11800) Convert BackupReceiver to component
by Pedro Ruivo (Jira)
[ https://issues.redhat.com/browse/ISPN-11800?page=com.atlassian.jira.plugi... ]
Pedro Ruivo updated ISPN-11800:
-------------------------------
Fix Version/s: 11.0.0.CR1
> Convert BackupReceiver to component
> -----------------------------------
>
> Key: ISPN-11800
> URL: https://issues.redhat.com/browse/ISPN-11800
> Project: Infinispan
> Issue Type: Enhancement
> Components: Core, Cross-Site Replication
> Affects Versions: 11.0.0.Dev05
> Reporter: Pedro Ruivo
> Assignee: Pedro Ruivo
> Priority: Major
> Fix For: 11.0.0.CR1
>
>
> The {{BackupReceiver}} instance is created by {{BackupReceiverRepository}} and it needs access to the {{Cache}} instance for its dependencies.
> However, with the latest changes in Cross-Site Replication, it needs to be accessed by commands and the only way to do it is by doing:
> {code:java}
> BackupReceiver backupReceiver = registry.getGlobalComponentRegistry()
> .getComponent(BackupReceiverRepository.class)
> .getBackupReceiver(cache);
> {code}
> Bottom line: tt should be converted to a component.
> Another alternative would be to merge it with {{PerCacheInboundInvocationHandler}}... but it doesn't sound too good since it will increase the complexity and size of {{PerCacheInboundInvocationHandler}}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (ISPN-11800) Convert BackupReceiver to component
by Pedro Ruivo (Jira)
[ https://issues.redhat.com/browse/ISPN-11800?page=com.atlassian.jira.plugi... ]
Pedro Ruivo updated ISPN-11800:
-------------------------------
Status: Open (was: New)
> Convert BackupReceiver to component
> -----------------------------------
>
> Key: ISPN-11800
> URL: https://issues.redhat.com/browse/ISPN-11800
> Project: Infinispan
> Issue Type: Enhancement
> Components: Core, Cross-Site Replication
> Affects Versions: 11.0.0.Dev05
> Reporter: Pedro Ruivo
> Assignee: Pedro Ruivo
> Priority: Major
> Fix For: 11.0.0.CR1
>
>
> The {{BackupReceiver}} instance is created by {{BackupReceiverRepository}} and it needs access to the {{Cache}} instance for its dependencies.
> However, with the latest changes in Cross-Site Replication, it needs to be accessed by commands and the only way to do it is by doing:
> {code:java}
> BackupReceiver backupReceiver = registry.getGlobalComponentRegistry()
> .getComponent(BackupReceiverRepository.class)
> .getBackupReceiver(cache);
> {code}
> Bottom line: tt should be converted to a component.
> Another alternative would be to merge it with {{PerCacheInboundInvocationHandler}}... but it doesn't sound too good since it will increase the complexity and size of {{PerCacheInboundInvocationHandler}}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (ISPN-11800) Convert BackupReceiver to component
by Pedro Ruivo (Jira)
[ https://issues.redhat.com/browse/ISPN-11800?page=com.atlassian.jira.plugi... ]
Pedro Ruivo updated ISPN-11800:
-------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/8317
> Convert BackupReceiver to component
> -----------------------------------
>
> Key: ISPN-11800
> URL: https://issues.redhat.com/browse/ISPN-11800
> Project: Infinispan
> Issue Type: Enhancement
> Components: Core, Cross-Site Replication
> Affects Versions: 11.0.0.Dev05
> Reporter: Pedro Ruivo
> Assignee: Pedro Ruivo
> Priority: Major
> Fix For: 11.0.0.CR1
>
>
> The {{BackupReceiver}} instance is created by {{BackupReceiverRepository}} and it needs access to the {{Cache}} instance for its dependencies.
> However, with the latest changes in Cross-Site Replication, it needs to be accessed by commands and the only way to do it is by doing:
> {code:java}
> BackupReceiver backupReceiver = registry.getGlobalComponentRegistry()
> .getComponent(BackupReceiverRepository.class)
> .getBackupReceiver(cache);
> {code}
> Bottom line: tt should be converted to a component.
> Another alternative would be to merge it with {{PerCacheInboundInvocationHandler}}... but it doesn't sound too good since it will increase the complexity and size of {{PerCacheInboundInvocationHandler}}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (ISPN-11800) Convert BackupReceiver to component
by Pedro Ruivo (Jira)
[ https://issues.redhat.com/browse/ISPN-11800?page=com.atlassian.jira.plugi... ]
Pedro Ruivo updated ISPN-11800:
-------------------------------
Affects Version/s: 11.0.0.Dev05
> Convert BackupReceiver to component
> -----------------------------------
>
> Key: ISPN-11800
> URL: https://issues.redhat.com/browse/ISPN-11800
> Project: Infinispan
> Issue Type: Enhancement
> Components: Core, Cross-Site Replication
> Affects Versions: 11.0.0.Dev05
> Reporter: Pedro Ruivo
> Assignee: Pedro Ruivo
> Priority: Major
> Fix For: 11.0.0.CR1
>
>
> The {{BackupReceiver}} instance is created by {{BackupReceiverRepository}} and it needs access to the {{Cache}} instance for its dependencies.
> However, with the latest changes in Cross-Site Replication, it needs to be accessed by commands and the only way to do it is by doing:
> {code:java}
> BackupReceiver backupReceiver = registry.getGlobalComponentRegistry()
> .getComponent(BackupReceiverRepository.class)
> .getBackupReceiver(cache);
> {code}
> Bottom line: tt should be converted to a component.
> Another alternative would be to merge it with {{PerCacheInboundInvocationHandler}}... but it doesn't sound too good since it will increase the complexity and size of {{PerCacheInboundInvocationHandler}}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (ISPN-11824) Cross-Site Replication code improvements
by Pedro Ruivo (Jira)
Pedro Ruivo created ISPN-11824:
----------------------------------
Summary: Cross-Site Replication code improvements
Key: ISPN-11824
URL: https://issues.redhat.com/browse/ISPN-11824
Project: Infinispan
Issue Type: Enhancement
Components: Core, Cross-Site Replication
Reporter: Pedro Ruivo
Assignee: Pedro Ruivo
Main JIRA to split into multiple subtasks:
* Make state transfer non-blocking.
* Remove allocations related to LocalInvocation.newInstanceFromCache(). Use XSiteStateConsumer directly
* Split ClusteredCacheBackupReceiver in: Pessimitic, Optimistic and NonTx implementations
* Remove cache.getStatus() and use the start() and stop() methods
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (ISPN-11823) Automatically set driver=CONTAINER when image is provided
by Ryan Emerson (Jira)
Ryan Emerson created ISPN-11823:
-----------------------------------
Summary: Automatically set driver=CONTAINER when image is provided
Key: ISPN-11823
URL: https://issues.redhat.com/browse/ISPN-11823
Project: Infinispan
Issue Type: Enhancement
Components: Server, Test Suite
Affects Versions: 11.0.0.Dev05
Reporter: Ryan Emerson
Assignee: Ryan Emerson
Fix For: 11.0.0.CR1
When providing a base image via {{-Dorg.infinispan.test.server.container.baseImageName=}} it's also necessary to explicititly set {{-Dorg.infinispan.test.server.driver=CONTAINER}}, however it should be sufficient to simply provide the former and the driver be automatically set.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (ISPN-10373) Store/Loader Non blocking SPI
by Will Burns (Jira)
[ https://issues.redhat.com/browse/ISPN-10373?page=com.atlassian.jira.plugi... ]
Will Burns commented on ISPN-10373:
-----------------------------------
Just so it is not lost this is how we can implement RemoteStore bulk operations
// @Override
// public CompletionStage<Void> bulkSegmentedWrite(int publisherCount,
// Publisher<NonBlockingLoadWriteStore.SegmentedPublisher<MarshallableEntry<K, V>>> publisher) {
// return Flowable.fromPublisher(publisher)
// .flatMap(Functions.identity(), false, publisherCount)
// .buffer(configuration.maxBatchSize())
// .concatMapCompletable(mes -> {
// CompletableFuture<Void> putAllFuture = remoteCache.putAllAsync(
// mes.stream().collect(Collectors.toMap(this::getKey, this::getValue)));
// return RxJavaInterop.completionStageToCompletable(putAllFuture);
// })
// .doOnError(PersistenceException::new)
// .to(RxJavaInterop.completableToCompletionStage());
// }
// @Override
// public CompletionStage<Void> bulkSegmentedWrite(int publisherCount,
// Publisher<NonBlockingStore.SegmentedPublisher<MarshallableEntry<K, V>>> publisher) {
// return Flowable.fromPublisher(publisher)
// .flatMap(sp ->
// Flowable.fromPublisher(sp)
// .buffer(configuration.maxBatchSize())
// , false, publisherCount)
// .concatMapCompletable(mes -> {
// CompletableFuture<Void> putAllFuture = remoteCache.putAllAsync(
// mes.stream().collect(Collectors.toMap(this::getKey, this::getValue)));
// return RxJavaInterop.completionStageToCompletable(putAllFuture);
// })
// .doOnError(PersistenceException::new)
// .to(RxJavaInterop.completableToCompletionStage());
// }
> Store/Loader Non blocking SPI
> -----------------------------
>
> Key: ISPN-10373
> URL: https://issues.redhat.com/browse/ISPN-10373
> Project: Infinispan
> Issue Type: Feature Request
> Components: Loaders and Stores
> Reporter: Will Burns
> Assignee: Will Burns
> Priority: Major
>
> We need to add and use a non blocking SPI internally for our stores/loaders. We added ISPN-9722, which is a good step and refactored all of our internal code to use "non blocking" stores. However the stores themselves are all inherently sync even if the store itself could be non blocking. We would have to add a new SPI interface to allow for such non blocking operations. We would then remove all the explicit threading added in ISPN-9722 and move it to a wrapper around a currently sync loader instead. This way an invoking thread doesn't need to do a context switch or anything if invoking just a non blocking store operation.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (ISPN-10373) Store/Loader Non blocking SPI
by Will Burns (Jira)
[ https://issues.redhat.com/browse/ISPN-10373?page=com.atlassian.jira.plugi... ]
Will Burns edited comment on ISPN-10373 at 5/13/20 10:33 AM:
-------------------------------------------------------------
Just so it is not lost this is how we can implement RemoteStore bulk operations
{code}
// @Override
// public CompletionStage<Void> bulkSegmentedWrite(int publisherCount,
// Publisher<NonBlockingLoadWriteStore.SegmentedPublisher<MarshallableEntry<K, V>>> publisher) {
// return Flowable.fromPublisher(publisher)
// .flatMap(Functions.identity(), false, publisherCount)
// .buffer(configuration.maxBatchSize())
// .concatMapCompletable(mes -> {
// CompletableFuture<Void> putAllFuture = remoteCache.putAllAsync(
// mes.stream().collect(Collectors.toMap(this::getKey, this::getValue)));
// return RxJavaInterop.completionStageToCompletable(putAllFuture);
// })
// .doOnError(PersistenceException::new)
// .to(RxJavaInterop.completableToCompletionStage());
// }
// @Override
// public CompletionStage<Void> bulkSegmentedWrite(int publisherCount,
// Publisher<NonBlockingStore.SegmentedPublisher<MarshallableEntry<K, V>>> publisher) {
// return Flowable.fromPublisher(publisher)
// .flatMap(sp ->
// Flowable.fromPublisher(sp)
// .buffer(configuration.maxBatchSize())
// , false, publisherCount)
// .concatMapCompletable(mes -> {
// CompletableFuture<Void> putAllFuture = remoteCache.putAllAsync(
// mes.stream().collect(Collectors.toMap(this::getKey, this::getValue)));
// return RxJavaInterop.completionStageToCompletable(putAllFuture);
// })
// .doOnError(PersistenceException::new)
// .to(RxJavaInterop.completableToCompletionStage());
// }
{code}
was (Author: william.burns):
Just so it is not lost this is how we can implement RemoteStore bulk operations
// @Override
// public CompletionStage<Void> bulkSegmentedWrite(int publisherCount,
// Publisher<NonBlockingLoadWriteStore.SegmentedPublisher<MarshallableEntry<K, V>>> publisher) {
// return Flowable.fromPublisher(publisher)
// .flatMap(Functions.identity(), false, publisherCount)
// .buffer(configuration.maxBatchSize())
// .concatMapCompletable(mes -> {
// CompletableFuture<Void> putAllFuture = remoteCache.putAllAsync(
// mes.stream().collect(Collectors.toMap(this::getKey, this::getValue)));
// return RxJavaInterop.completionStageToCompletable(putAllFuture);
// })
// .doOnError(PersistenceException::new)
// .to(RxJavaInterop.completableToCompletionStage());
// }
// @Override
// public CompletionStage<Void> bulkSegmentedWrite(int publisherCount,
// Publisher<NonBlockingStore.SegmentedPublisher<MarshallableEntry<K, V>>> publisher) {
// return Flowable.fromPublisher(publisher)
// .flatMap(sp ->
// Flowable.fromPublisher(sp)
// .buffer(configuration.maxBatchSize())
// , false, publisherCount)
// .concatMapCompletable(mes -> {
// CompletableFuture<Void> putAllFuture = remoteCache.putAllAsync(
// mes.stream().collect(Collectors.toMap(this::getKey, this::getValue)));
// return RxJavaInterop.completionStageToCompletable(putAllFuture);
// })
// .doOnError(PersistenceException::new)
// .to(RxJavaInterop.completableToCompletionStage());
// }
> Store/Loader Non blocking SPI
> -----------------------------
>
> Key: ISPN-10373
> URL: https://issues.redhat.com/browse/ISPN-10373
> Project: Infinispan
> Issue Type: Feature Request
> Components: Loaders and Stores
> Reporter: Will Burns
> Assignee: Will Burns
> Priority: Major
>
> We need to add and use a non blocking SPI internally for our stores/loaders. We added ISPN-9722, which is a good step and refactored all of our internal code to use "non blocking" stores. However the stores themselves are all inherently sync even if the store itself could be non blocking. We would have to add a new SPI interface to allow for such non blocking operations. We would then remove all the explicit threading added in ISPN-9722 and move it to a wrapper around a currently sync loader instead. This way an invoking thread doesn't need to do a context switch or anything if invoking just a non blocking store operation.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months