[
https://issues.apache.org/jira/browse/GEODE-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15765414#comment-15765414
]
ASF GitHub Bot commented on GEODE-2109:
---------------------------------------
Github user upthewaterspout commented on the issue:
https://github.com/apache/geode/pull/296
Hi @deepakddixit
Sorry for the slow response. I'm a little concerned that with your changes
to the test in ef4d38d, the test is no longer actually testing what happens if
the runnable passed to the executor throws an exception.
I think those changes *do* show that the problem is not with SystemErrRule,
since with your change the test passes consistently. What that means is that
there might be a product issue.
I did a little bit of investigation, and I found that if I set an uncaught
exception handler in the product, your original test passes consistently. I'm
not quite sure why the default uncaught exception handler was not consistently
working, but I think it's better to send the error to the log anyway.
I stuck my changes up as a pull request to your branch if want to look at
them. Let me know what you think, if this looks good to you I can merge this
stuff:
https://github.com/deepakddixit/incubator-geode/pull/1
> 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)
