Calling another cache from within AbstractProcessor.process fails, why?

Question

I want to enrich a certain data object in a distributed cache via the EntryProcessor framework. The new data is looked up from another nearby cache.
However, when calling otherCache.get(id) Coherence throws an exception saying that it does not allow blocking calls from within a processor:
*[java] Caused by: com.tangosol.util.AssertionException: poll() is a blocking call and cannot be called on the Service thread...*
Is this fixable? What am I missing? Does anyone recommend alternative ways to read data from other caches inside AbstractProcessor?
Thanks in advance,
-Stefan
This is the calling code that executes in the node where the primary object is:
public class ExternalPropertiesUpdateProcessor extends AbstractProcessor implements PortableObject {
@Override
public Object process(InvocableMap.Entry entry) {
Session session = null;
if (entry.isPresent()) {
session = (Session) entry.getValue();
NamedCache cidCache = CacheFactory.getCache("cidCache");
Long oldCid = new Long(97);
CidConversion cidCon = (CidConversion) cidCache.get(oldCid); // * it fails here with above exception!
session.setCid(cidCon.getNewCid());
session.setState(Session.SESSION_CLOSED);
entry.setValue(session); // make session changes durable in cache
return session;
Edited by: [email protected] on Dec 10, 2009 9:35 AM

Answer 1

Ben Stopford wrote:
Hi Rob
You mention:
If you call back to the same cache service via an invocation service, you still risk a deadlock or a livelock due to thread-pool depletion. It looks like it is working, then you may run into the problem. It is not 100% safe.which sparked my interest. Would you mind elaborating a little further. I'd always assumed that the threadpools for separate services were independent and thus there was no chance of deadlock from cross-service calls such as this.
Thanks in advance
BenHi Ben,
as I mentioned, it can cause a problem if you indirectly call back to a service which was on the call stack.
Let's see an example:
You send an entry processor to a cache in service A, which synchronously (with the query() method) calls to Invocation service I in which the invocable agent sends an entry-processor to service A (again) targeted to an entry on the same node.
Let's for the sake of the simplicity of the example suppose service A has a thread pool of size 2.
You send two such entry-processors on entries residing in the same node.
We now have a possible deadlock. If both entry-processors entered the first process() method (doesn't matter what entry as long as they are on the same node), they can both proceed into the invocation service call, but from that none of them can proceed further to the inner invoke() call, because there are no more free threads in service A!!! Poof, deadlock, both threads will wait until a thread becomes available... and none will become available because none of the service calls can proceed.
Of course, starting with 3.5 the Guardian will kill one of the threads (at least), and in earlier version it will also time out, but the point is that they will not be able to complete in this scenario.
Best regards,
Robert