From a58586f0e4973aa6855142222ed8be124add9ad5 Mon Sep 17 00:00:00 2001 From: John Chilton Date: Mon, 20 Nov 2017 10:54:14 -0500 Subject: [PATCH] Cleanup SA objects between workflow invocation scheduling attempts. This would seem to be a fairly serious memory leak in the abstract but I don't have data that it fixes anything. None the less if it gets into dev and the tests seem to pass I'll open a PR to backport it to at least 17.05 and maybe back even more. --- lib/galaxy/workflow/scheduling_manager.py | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/lib/galaxy/workflow/scheduling_manager.py b/lib/galaxy/workflow/scheduling_manager.py index 5b6d1ee52dd..9c30615adc5 100644 --- a/lib/galaxy/workflow/scheduling_manager.py +++ b/lib/galaxy/workflow/scheduling_manager.py @@ -202,10 +202,10 @@ class WorkflowRequestMonitor(object): sa_session = self.app.model.context workflow_invocation = sa_session.query(model.WorkflowInvocation).get(invocation_id) - if not workflow_invocation or not workflow_invocation.active: - return False - try: + if not workflow_invocation or not workflow_invocation.active: + return False + # This ensures we're only ever working on the 'first' active # workflow invocation in a given history, to force sequential # activation. @@ -218,6 +218,8 @@ class WorkflowRequestMonitor(object): # TODO: eventually fail this - or fail it right away? log.exception("Exception raised while attempting to schedule workflow request.") return False + finally: + sa_session.expunge_all() # A workflow was obtained and scheduled... return True