[JBoss JIRA] (ISPN-11553) Add BlockHound to cluster locks
by Will Burns (Jira)
Will Burns created ISPN-11553:
---------------------------------
Summary: Add BlockHound to cluster locks
Key: ISPN-11553
URL: https://issues.redhat.com/browse/ISPN-11553
Project: Infinispan
Issue Type: Enhancement
Components: Clustered Locks
Reporter: Will Burns
Fix For: 11.0.0.Dev04
Cluster Locks use a blocking pool for a few things. This should be removable, assuming functional map is properly non blocking. We should introduce block hound and find out!
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 1 month
[JBoss JIRA] (ISPN-11552) Cluster Locks should be non blocking
by Will Burns (Jira)
Will Burns created ISPN-11552:
---------------------------------
Summary: Cluster Locks should be non blocking
Key: ISPN-11552
URL: https://issues.redhat.com/browse/ISPN-11552
Project: Infinispan
Issue Type: Sub-task
Components: Clustered Locks
Reporter: Will Burns
Cluster Locks currently use a blocking executor to process lock and unlock calls. The API for these methods are non blocking and we should ensure they do not block down the stack.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 1 month
[JBoss JIRA] (ISPN-11551) Add checkstyle to prevent invoking parallelStream
by Will Burns (Jira)
Will Burns created ISPN-11551:
---------------------------------
Summary: Add checkstyle to prevent invoking parallelStream
Key: ISPN-11551
URL: https://issues.redhat.com/browse/ISPN-11551
Project: Infinispan
Issue Type: Sub-task
Reporter: Will Burns
Assignee: Will Burns
Creating a Stream via parallelStream uses common thread pool threads to perform the operation. This is not what we want as we have our cpu thread pool. These callers should be updated to invoke the non blocking thread pool or just use a regular stream (latter preferred if possible).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 1 month
[JBoss JIRA] (ISPN-11550) Add way to detect if calling context is blocking or not
by Will Burns (Jira)
[ https://issues.redhat.com/browse/ISPN-11550?page=com.atlassian.jira.plugi... ]
Will Burns commented on ISPN-11550:
-----------------------------------
Looking more closely many commands would require 8 bytes to add the boolean. We could trim down segments, but not sure if that is desired yet.
Doing different invocation context impls is doable, but kinda ugly.
A thread local is also not desirable.
At this point the best option appears to be using a Flag in the command to signal to further down components.
> 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
> Priority: Major
>
> 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)
4 years, 1 month
[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)
4 years, 1 month