This discussion is archived
0 Replies Latest reply: Apr 3, 2012 8:30 AM by 923522 RSS

Question on Processing Pattern Sessions - not behaving as expected

923522 Newbie
Currently Being Moderated
I have implemented some schedulable jobs in my extensible cache configuration that are scheduled at a fixed rate and then use the processing pattern to submit work to the grid.
However I am seeing some unexpected behaviour which does not seem to make much sense. My jobs are submitted to the grid as follows (some code edited for brevity):-

     public void run() {
          ProcessingSession session = null;
          try {
          session = new DefaultProcessingSession(StringBasedIdentifier.newInstance("MySession"));
          SubmissionOutcome outcome = session.submit(this, new DefaultSubmissionConfiguration(),
     new TaskSubmissionCallback(taskName));
          catch (Throwable t) {
               log.error("Failed to Submit Process Pattern Task [{}] For Session [{}]", taskName, nodeName);
          finally {
               try {
               catch (Throwable t) {
                    log.error("[{}] Failed to Shutdown Processing Pattern Session [{}]", this, nodeName);

My tasks get scheduled and then submiited and executed in the grid. I am currently only running a single node through eclipse for testing.
But after the task has excecuted my TaskSubmissionCallback class gets invoked and the onDone() gets called and returns my result:-

public void onDone(Object oResult)
     log.debug("[{}] Submission done - Result = [{}]", m_sTaskName, oResult);

So all is working. However a couple of milliseconds later I see the following in the logs:-

2012-04-03 17:15:50.407/19.274 Oracle Coherence GE <Error> (thread=DistributedCache:DistributedServiceForProcessingPatternSubmissionResults:EventDispatcher, member=1): The following exception was caught by the event dispatcher:
2012-04-03 17:15:50.407/19.274 Oracle Coherence GE <Error> (thread=DistributedCache:DistributedServiceForProcessingPatternSubmissionResults:EventDispatcher, member=1):
     at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(
     at java.util.concurrent.ThreadPoolExecutor.reject(
     at java.util.concurrent.ScheduledThreadPoolExecutor.delayedExecute(
     at java.util.concurrent.ScheduledThreadPoolExecutor.schedule(
     at java.util.concurrent.ScheduledThreadPoolExecutor.execute(
     at com.tangosol.util.MultiplexingMapListener.entryUpdated(
     at com.tangosol.util.MapEvent.dispatch(
     at com.tangosol.util.MapEvent.dispatch(
     at com.tangosol.util.MapListenerSupport.fireEvent(
     at com.tangosol.coherence.component.util.SafeNamedCache.translateMapEvent(SafeNamedCache.CDB:7)
     at com.tangosol.coherence.component.util.SafeNamedCache.entryUpdated(SafeNamedCache.CDB:1)
     at com.tangosol.util.MapEvent.dispatch(
     at com.tangosol.coherence.component.util.daemon.queueProcessor.service.grid.partitionedService.PartitionedCache$ViewMap$ProxyListener.dispatch(PartitionedCache.CDB:22)
     at com.tangosol.coherence.component.util.daemon.queueProcessor.service.grid.partitionedService.PartitionedCache$ViewMap$ProxyListener.entryUpdated(PartitionedCache.CDB:1)
     at com.tangosol.util.MapEvent.dispatch(
     at com.tangosol.coherence.component.util.daemon.queueProcessor.Service$EventDispatcher.onNotify(Service.CDB:26)

I have managed to solve this by removing the session.shutdown() call in the class that submits the job for processing using the Processing Pattern. However this seems odd to me
as the submitter should not need to hang around until the job completes (as that is surely the point of the Callback handler). I can of course code around this by having a Singleton
class which keeps the Processing session alive constantly and stores this in the Environment. But the question is why ???

This is running Coherence 3.6 and coherence-processingpattern-1.3.423238.

Would be grateful to know if this is a bug or my understanding is somehow confused !



  • Correct Answers - 10 points
  • Helpful Answers - 5 points