[JBoss JIRA] (ISPN-11550) Add way to detect if calling context is blocking or not
by Will Burns (Jira)
Will Burns created ISPN-11550:
---------------------------------
Summary: Add way to detect if calling context is blocking or not
Key: ISPN-11550
URL: https://issues.redhat.com/browse/ISPN-11550
Project: Infinispan
Issue Type: Enhancement
Components: Core
Reporter: Will Burns
A user can use either our blocking (Cache#put) or non blocking (Cache#putAsync) API. We should be able to optimize our usage of blocking threads based on this. In the case that the user is using the blocking API, we can assume the thread is a blocking thread (even though we don't control it), which would allow us to not have to spawn additional threads to wait providing for less context switching and better resource utilization.
The main question is how do we detect such things. An idea is a thread local, command boolean, context flag etc.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (ISPN-11548) Update BlockHound to 1.0.3
by Will Burns (Jira)
Will Burns created ISPN-11548:
---------------------------------
Summary: Update BlockHound to 1.0.3
Key: ISPN-11548
URL: https://issues.redhat.com/browse/ISPN-11548
Project: Infinispan
Issue Type: Task
Reporter: Will Burns
Assignee: Will Burns
BlockHound now has support for newer versions of JRE. We should make sure to update to get this detection as well.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (ISPN-11489) TransactionCoordinator updated for non blocking
by Dan Berindei (Jira)
[ https://issues.redhat.com/browse/ISPN-11489?page=com.atlassian.jira.plugi... ]
Dan Berindei updated ISPN-11489:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> TransactionCoordinator updated for non blocking
> -----------------------------------------------
>
> Key: ISPN-11489
> URL: https://issues.redhat.com/browse/ISPN-11489
> Project: Infinispan
> Issue Type: Sub-task
> Reporter: Will Burns
> Assignee: Will Burns
> Priority: Major
> Fix For: 11.0.0.Dev04
>
>
> TransactionCoordinator is utilized when working with transactions. Unfortunately due to transaction API being inherently blocking, we need to make some exceptions to how this is handled.
> # TransactionCoordinator should only be invokable by a blocking method, the inverse of the PersistenceManagerImpl
> # We should invoke all the non blocking code of TransactionCoordinator in a non blocking thread and then block on its completion in the blocking thread.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (ISPN-11543) Add BlockingHandler to simplify running blocking operations
by Will Burns (Jira)
[ https://issues.redhat.com/browse/ISPN-11543?page=com.atlassian.jira.plugi... ]
Will Burns updated ISPN-11543:
------------------------------
Status: Open (was: New)
> Add BlockingHandler to simplify running blocking operations
> -----------------------------------------------------------
>
> Key: ISPN-11543
> URL: https://issues.redhat.com/browse/ISPN-11543
> Project: Infinispan
> Issue Type: Sub-task
> Reporter: Will Burns
> Assignee: Will Burns
> Priority: Major
> Fix For: 11.0.0.Dev04
>
>
> We have quite a few places that must run blocking operations that cannot be changed. These places must run the operation in a blocking thread and return on a non blocking thread. All of these places must register both a blocking and non blocking thread pool and properly handle them. This is both error prone and a lot of extra code. We should isolate this to a shared component which will in turn provide for an easier way to find such operations.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years