geode-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <>
Subject [jira] [Commented] (GEODE-542) Race in FunctionService.onMembers can result in hang during member startup
Date Mon, 16 Nov 2015 20:16:10 GMT


ASF subversion and git services commented on GEODE-542:

Commit d6c58e86a2abdb1670b02e4ac8089edb894f8f7c in incubator-geode's branch refs/heads/feature/GEODE-151
from [~upthewaterspout]
[;h=d6c58e8 ]

GEODE-542: Send a function response after a CancelException

There was a catch clause of a CancelException that was causing us not to
reply to a function call if a CacheClosedException was thrown from the
function. That caused as hang waiting for replies.

> Race in FunctionService.onMembers can result in hang during member startup
> --------------------------------------------------------------------------
>                 Key: GEODE-542
>                 URL:
>             Project: Geode
>          Issue Type: Bug
>            Reporter: Dan Smith
>            Assignee: Dan Smith
> I hit this while doing some internal tests of FunctionService. I have a function that
calls CacheFactory.getAnyInstance(). I was seeing that occasionally, my function would never
see a reply while a member was starting up.
> Turning on debug logging, I found this is the logs
> {noformat}
> [fine 2015/10/28 17:15:41.903 PDT clientgemfire2_gluon_2055 <Function Execution Processor2>
tid=0x37] shutdown caught, abandoning message: A cache has not yet been created.
> com.gemstone.gemfire.cache.CacheClosedException: A cache has not yet been created.
> 	at com.gemstone.gemfire.cache.CacheFactory.getAnyInstance(
> 	at com.gemstone.gemfire.internal.cache.execute.util.RollbackFunction.execute(
> 	at com.gemstone.gemfire.internal.cache.MemberFunctionStreamingMessage.process(
> 	at com.gemstone.gemfire.distributed.internal.DistributionMessage.scheduleAction(
> 	at com.gemstone.gemfire.distributed.internal.DistributionMessage$
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(
> 	at java.util.concurrent.ThreadPoolExecutor$
> 	at com.gemstone.gemfire.distributed.internal.DistributionManager.runUntilShutdown(
> 	at com.gemstone.gemfire.distributed.internal.DistributionManager$9$
> 	at
> {noformat}
> This seems wrong, because by not replying to the function the caller then can hang. I
think this code was intended for use during shutdown, but it also gets hit during startup
because members are available to process functions before the cache is created. That in itself
is perhaps problematic.

This message was sent by Atlassian JIRA

View raw message