[jira] [Commented] (GEODE-2109) calling submit on ExecutionService can cause exceptions to be lost

["ASF GitHub Bot (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/GEODE-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15730340#comment-15730340 ] 

ASF GitHub Bot commented on GEODE-2109:
---------------------------------------

Github user upthewaterspout commented on the issue:

    https://github.com/apache/geode/pull/296
  
    I looking at pulling this, and I see what one of the unit tests failed for me. It's failing intermittently in the IDE:
        SingleHopClientExecutorSubmitTaskWithExceptionTest.submittedTaskShouldLogFailure
    
        java.lang.RuntimeException: I am expecting this to be logged
    	at  org.apache.geode.cache.client.internal.SingleHopClientExecutorSubmitTaskWithExceptionTest$1.run(SingleHopClientExecutorSubmitTaskWithExceptionTest.java:52)
    	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    	at java.lang.Thread.run(Thread.java:745)


> calling submit on ExecutionService can cause exceptions to be lost
> ------------------------------------------------------------------
>
>                 Key: GEODE-2109
>                 URL: https://issues.apache.org/jira/browse/GEODE-2109
>             Project: Geode
>          Issue Type: Bug
>          Components: regions
>            Reporter: Darrel Schneider
>
> Geode has a number of places that call submit on ExecutionService. The submit method returns a Future object. If the caller makes sure it calls "get" on the Future then all is well. But in many places geode is not calling get. In that case if the Runnable that was submitted throws an exception it gets stored in the get and never logged. This can make it very hard to diagnose problems.
> If the caller does not want to call get on the returned Future then it should instead call the "execute" method. In that case the exception will be unhandled and the unhandled exception handler code we have on the LoggingThreadGroup class will cause the exception to be logged.
> Here are the places that should be changed to use execute instead of submit:
> org.apache.geode.internal.util.concurrent.CustomEntryConcurrentHashMap.clear()
> org.apache.geode.internal.cache.DiskStoreImpl.executeDiskStoreTask(Runnable)
> org.apache.geode.internal.cache.lru.HeapEvictor.onEvent(MemoryEvent)
> org.apache.geode.distributed.internal.InternalLocator.restartWithDS(InternalDistributedSystem, GemFireCacheImpl)
> org.apache.geode.distributed.internal.FunctionExecutionPooledExecutor.FunctionExecutionPooledExecutor(BlockingQueue<Runnable>, int, PoolStatHelper, ThreadFactory, int, boolean)
> org.apache.geode.internal.cache.PRHARedundancyProvider.scheduleCreateMissingBuckets()
> org.apache.geode.distributed.internal.InternalLocator.startSharedConfigurationService(GemFireCacheImpl)
> org.apache.geode.cache.client.internal.SingleHopClientExecutor.submitTask(Runnable)
> org.apache.geode.management.internal.FederatingManager.submitTask(Callable<DistributedMember>)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)