[
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)