Mailing-List: contact issues-help@geode.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geode.incubator.apache.org
Date: Wed, 11 Nov 2015 02:02:11 +0000 (UTC)
From: "Dan Smith (JIRA)" <jira@apache.org>
To: issues@geode.incubator.apache.org
Message-ID: <JIRA.12912048.1447207300000.35448.1447207331174@Atlassian.JIRA>
In-Reply-To: <JIRA.12912048.1447207300000@Atlassian.JIRA>
References: <JIRA.12912048.1447207300000@Atlassian.JIRA>
 <JIRA.12912048.1447207300174@arcas>
Subject: [jira] [Assigned] (GEODE-542) Race in FunctionService.onMembers can
 result in hang during member startup
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/GEODE-542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dan Smith reassigned GEODE-542:
-------------------------------

    Assignee: Dan Smith

> Race in FunctionService.onMembers can result in hang during member startup
> --------------------------------------------------------------------------
>
>                 Key: GEODE-542
>                 URL: https://issues.apache.org/jira/browse/GEODE-542
>             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(CacheFactory.java:292)
> 	at com.gemstone.gemfire.internal.cache.execute.util.RollbackFunction.execute(RollbackFunction.java:82)
> 	at com.gemstone.gemfire.internal.cache.MemberFunctionStreamingMessage.process(MemberFunctionStreamingMessage.java:194)
> 	at com.gemstone.gemfire.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:380)
> 	at com.gemstone.gemfire.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:451)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at com.gemstone.gemfire.distributed.internal.DistributionManager.runUntilShutdown(DistributionManager.java:701)
> 	at com.gemstone.gemfire.distributed.internal.DistributionManager$9$1.run(DistributionManager.java:1158)
> 	at java.lang.Thread.run(Thread.java:745)
> {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
(v6.3.4#6332)