[
https://issues.apache.org/jira/browse/GEODE-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15767585#comment-15767585
]
ASF GitHub Bot commented on GEODE-2109:
---------------------------------------
Github user deepakddixit commented on the issue:
https://github.com/apache/geode/pull/296
@upthewaterspout Thanks for the detailed review. I agree with you,
SingleHopClientExecutor was not having uncaught exception handler which is
causing exceptions not handled and ultimately not logged. Setting an
uncaughtExceptionHandler would help in logging uncaught exceptions.
Only change I would like to suggest is instead of adding
uncaughtExceptionHandler can we set LoggingThreadGroup? The other pooled
executors are using LoggingThreadGroup which handles uncauhtExceptions. I have
changed code a bit and added LoggingThreadGroup, unit tests are passing. Let me
know your view on using LoggingThreadGroup.
> 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
> Assignee: Deepak Dixit
>
> 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)
