Eclipse Community Forums: EMF » [CDO] Managing async view invalidation

Help

Home

Home » Modeling » EMF » [CDO] Managing async view invalidation

Show: Today's Messages :: Show Polls :: Message Navigator

[CDO] Managing async view invalidation [message #1860351]

Mon, 31 July 2023 18:07

Alain Picard

Messages: 266
Registered: July 2009

Senior Member

Just started encountering an issue with invalidation, so guess we don't often go there :).

Our code expects any thread to run with some MDC values to manage the session state at our end and here those are not there.

In CDOSessionImpl#invalidateView, async is always set to true which makes the invalidation use the ViewInvalidation and its executor. Looking at the executor it trickles all the way up to the Transport to get the actual executor AFAICT.

So question is, shouldn't the async mode be configurable and secondly, is there a way to supply a custom executor. Note that we have our own store if that can help.

At the moment, I'm tempted to just comment the async true line to get pass this issue, but doesn't sound like a real solution.

Thanks
Alain

Report message to a moderator

Re: [CDO] Managing async view invalidation [message #1860361 is a reply to message #1860351]

Tue, 01 August 2023 07:46

Eike Stepper

Messages: 6682
Registered: July 2009

Senior Member

Hi Alain,

The "async mode" is not meant to be configurable by users or client code. It's a parameter that's used by the three different functions in CDO that can trigger view invalidation:

(a) Processing of change notifications sent from the server
(b) Processing of session refreshing (initiated by the client)
(c) Processing of view target switches (initiated by the client)

Only (a) already runs on a separate thread (the Net4j signal thread), so does not need to fork to another thread. Changing the async parameter will lead to deadlocks and perhaps other problems.

Your issue should probably be addressed at the thread pool level. You can use a custom thread pool by contributing a custom ExecutorServiceFactory with, e.g., factoryType="picard". Then you can make your factory be used by the TransportInjector by specifying the system property -Dorg.eclipse.net4j.util.concurrent.ExecutorServiceFactory.type=picard .

In your custom thread pool you can override these methods to set/remove thread local variables:

- ThreadPoolExecutor.beforeExecute(Thread, Runnable)
- ThreadPoolExecutor.afterExecute(Runnable, Throwable)

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper

Report message to a moderator