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 Wed, 11 Nov 2015 20:27:11 GMT


ASF subversion and git services commented on GEODE-542:

Commit a25a662b6e0117b79c0f1987ecf34fd94e73dda1 in incubator-geode's branch refs/heads/feature/GEODE-542
from [~upthewaterspout]
[;h=a25a662 ]

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