[
https://issues.jboss.org/browse/ISPN-9714?page=com.atlassian.jira.plugin....
]
William Burns commented on ISPN-9714:
-------------------------------------
I am not a fan of that. This would lead me to think that users will never change their
code. They could be doing anything inside there. By off loading the call to another
thread, we ensure our code is much safer, and the user has to change their code to ensure
their listener doesn't block. We have so many listeners in our code base that can
block for quite a bit of time as well as use other resources (ie. CacheManager#getCache,
Cache#put).
Let us take the inverse, how would a user implement a blocking method that should prevent
the operation from completing? Setting a listener as async doesn't block the current
operation from completing. We would have to add another method override of some type for
this, further complicating the options.
Update CacheNotifier to return CompletionStage
----------------------------------------------
Key: ISPN-9714
URL:
https://issues.jboss.org/browse/ISPN-9714
Project: Infinispan
Issue Type: Sub-task
Components: Core, Listeners
Reporter: William Burns
Assignee: William Burns
Priority: Major
Fix For: 10.0.0.Alpha2
We need to update CacheNotifier to return CompletionStage for all its appropriate
methods. We also need to update all the internals to use these appropriately.
Not all notification usages may provide support non blocking, but our listener internals
should support non blocking listeners for all.
The simplest way internally is to treat all current listeners as "alien" and
invoke them in the notification thread pool. If it is sync we would wait for this task to
complete. We would also now allow a listener to return a CompletionStage. If this is
returned we will use this operate in a non blocking way.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)