geode-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Smith (JIRA)" <>
Subject [jira] [Assigned] (GEODE-542) Race in FunctionService.onMembers can result in hang during member startup
Date Wed, 11 Nov 2015 02:02:11 GMT


Dan Smith reassigned GEODE-542:

    Assignee: Dan Smith

> 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