Oracle Coherence: how to set a timeout when a call is invoked in a replicated cache?

I have a replicated cache running on several weblogic nodes that also work with OSB. The cache starts with the server as a launch class. It has a very simple cache of objects that simply keep track of whether they are used or not, with the boolean attribute "available".

From OSB, I make java callouts in the same class that calls "invoke" in the cache with the processor, which puts the object as inaccessible, and then runs Thread.sleep (31000). This is a placeholder for some lengthy processing, which I want to add later.

What I want to do is if the invoke () call takes too long, the process should time out and return or throw an exception. Therefore, I am trying to set the request timeout to 30,000 milliseconds to verify this. Unfortunately, I can’t figure out how to make this timeout.

I tried:

  • Processor wrapper in PriorityProcessor and call setRequestTimeout (30000) before calling ()

  • Adding <request-timeout > 30000 </request-timeout > to the <replicated-scheme/ > element in the cache configuration

  • Adding <tasktimeout > 30000 </tasktimeout > to the <replicated-scheme/ > element in the cache configuration

  • Adding <guardian-timeout > 30000 </guardian-timeout > to the <replicated-scheme/ > element in the cache configuration

  • Creating tangosol-coherence-override.xml and adding a guard timer <init-param > to the <service > element, which "type" matches the "name" of the service in the cache configuration

  • Change the sleep () call to Thread.sleep (310000) to check if the default will fail to turn off the default after 5 minutes.

None of them lead to any timeout, the processor just sleeps, no matter how long I tell him, and then returns without errors.

Has anyone done something similar before and can give me some tips? It would be very grateful.

thanks

James

+7
source share
1 answer

Ok, so I have an answer, with the help of Tim Middleton .

Basically, the replicated cache does not support timeouts, and it turns out that this was not a suitable choice for my system!

Decision:

  • Switch to the <distributed-cache > scheme in the cache configuration.
  • Add the <thread-count > element to the schema with number> 1 (I chose 10, but just for many parallel instances that you want to support).
  • Use PriorityProcessor to wrap EntryProcessor and set a timeout with setRequestTimeoutMillis () before invoke () is called. (Note that this is the first thing I tried, but with the wrong cache type, as it turns out)
+2
source

All Articles