Question on Processing Pattern Sessions - not behaving as expected

Question

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):-
@Override
     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 {
                    session.shutdown();
               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 3.6.0.4 <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 3.6.0.4 <Error> (thread=DistributedCache:DistributedServiceForProcessingPatternSubmissionResults:EventDispatcher, member=1):
java.util.concurrent.RejectedExecutionException
     at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:1760)
     at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:767)
     at java.util.concurrent.ScheduledThreadPoolExecutor.delayedExecute(ScheduledThreadPoolExecutor.java:216)
     at java.util.concurrent.ScheduledThreadPoolExecutor.schedule(ScheduledThreadPoolExecutor.java:366)
     at java.util.concurrent.ScheduledThreadPoolExecutor.execute(ScheduledThreadPoolExecutor.java:438)
     at com.oracle.coherence.patterns.processing.internal.DefaultProcessingSession.removeCacheObjectsAsynch(DefaultProcessingSession.java:313)
     at com.oracle.coherence.patterns.processing.internal.DefaultProcessingSession.handleResultChange(DefaultProcessingSession.java:288)
     at com.oracle.coherence.patterns.processing.internal.DefaultProcessingSession$1.onMapEvent(DefaultProcessingSession.java:204)
     at com.tangosol.util.MultiplexingMapListener.entryUpdated(MultiplexingMapListener.java:42)
     at com.tangosol.util.MapEvent.dispatch(MapEvent.java:270)
     at com.tangosol.util.MapEvent.dispatch(MapEvent.java:226)
     at com.tangosol.util.MapListenerSupport.fireEvent(MapListenerSupport.java:557)
     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(MapEvent.java:270)
     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(MapEvent.java:270)
     at com.tangosol.coherence.component.util.CacheEvent.run(CacheEvent.CDB:18)
     at com.tangosol.coherence.component.util.daemon.queueProcessor.Service$EventDispatcher.onNotify(Service.CDB:26)
     at com.tangosol.coherence.component.util.Daemon.run(Daemon.CDB:42)
     at java.lang.Thread.run(Thread.java:619)
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 !
TIA
Martin

Answer 1

I agree, believe me. However, one goes to war with the army one has, not the army one wishes one had, to quote somebody who, um... okay, failed miserably. Hmm...
It's a flat-rate project, so the troubleshooting isn't costing them any more, and their IT department wags the rest of the company and won't buy stuff. Eventually they'll have CS4 and these problems will go away, but probably not until next year.
If I were willing to give up the CS4-specific features (which I'm not; maximum efficiency in long documents is the core competency of my business), working in CS3 still wouldn't be an option because I don't own it. I'm also not likely to be able to talk the client into the idea that I'll take care of the last-minute tweaks instead of their having to do it all.
(Keep in mind, too, that there's more behind the scenes than I'm necessarily sharing in a quick forum post. If I can keep the typesetting from shifting in the .inx for now, I'm good.)
I filed that bug report--thanks!
UPDATE: Client says it looks right. Off we go...