[JBoss JIRA] (ISPN-11830) Provide invocation based non blocking detection to test suite
by Will Burns (Jira)
Will Burns created ISPN-11830:
---------------------------------
Summary: Provide invocation based non blocking detection to test suite
Key: ISPN-11830
URL: https://issues.redhat.com/browse/ISPN-11830
Project: Infinispan
Issue Type: Task
Components: Test Suite
Reporter: Will Burns
Assignee: Will Burns
Fix For: 11.0.0.CR1
Currently we support block hound based blocking detection on a per thread basis. But this isn't sufficient if a test wants to detect if a blocking operation in a more natural way. Instead a user would have to submit a task to a different thread just for that invocation. This is ugly and quite error prone as it changes how the code would normally work (ThreadLocal etc.)
We should instead use the new dynamic thread predicate added in BlockHound 1.0.3 to support this.
I have also logged https://github.com/reactor/BlockHound/issues/121 which makes part of the code uglier until we can upgrade to 1.0.4.RELEASE.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 8 months
[JBoss JIRA] (ISPN-11800) Convert BackupReceiver to component
by Will Burns (Jira)
[ https://issues.redhat.com/browse/ISPN-11800?page=com.atlassian.jira.plugi... ]
Will Burns updated ISPN-11800:
------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> 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)
4 years, 8 months
[JBoss JIRA] (ISPN-11674) Clean up RemoteCache method overrides
by Pedro Ruivo (Jira)
[ https://issues.redhat.com/browse/ISPN-11674?page=com.atlassian.jira.plugi... ]
Pedro Ruivo updated ISPN-11674:
-------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Clean up RemoteCache method overrides
> -------------------------------------
>
> Key: ISPN-11674
> URL: https://issues.redhat.com/browse/ISPN-11674
> Project: Infinispan
> Issue Type: Enhancement
> Components: Hot Rod
> Reporter: Will Burns
> Assignee: Will Burns
> Priority: Major
> Fix For: 11.0.0.CR1
>
>
> There are a lot of various method overrides in the RemoteCache. This is because of async, versions and expiration overrides bloating almost all methods by eight times. We should consolidate these so they are simpler to handle and harder to mess up.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 8 months