You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@isis.apache.org by "Daniel Keir Haywood (Jira)" <ji...@apache.org> on 2020/02/09 13:05:00 UTC

[jira] [Created] (ISIS-2277) To avoid memory starvation, each background commands should run in its own session.

Daniel Keir Haywood created ISIS-2277:
-----------------------------------------

             Summary: To avoid memory starvation, each background commands should run in its own session.
                 Key: ISIS-2277
                 URL: https://issues.apache.org/jira/browse/ISIS-2277
             Project: Isis
          Issue Type: Improvement
    Affects Versions: 1.17.0
            Reporter: Daniel Keir Haywood
            Assignee: Daniel Keir Haywood
             Fix For: 1.18.0


The current behaviour (at least, as exploited by the Incode Platform's command service implementation) is:
 * a bunch of commands might be queued up to run in the background say 3000 of them
 * every 10 seconds, quartz schedules to execute the RunBackgroundCommandsWithReplicationAndReplayJob.
 ** nb: this is annotated with @DisallowConcurrentExecution and 
@PersistJobDataAfterExecution ... so quartz won't run another instance until this one has completed.
 * this delegates to BackgroundCommandExecutionFromBackgroundCommandServiceJdo
 * this in turn finds the 3000 commands
 * in the superclass, BackgroundCommandExecution#doExecute(). these commands are processed one by one, each in their own transaction
 * HOWEVER, there is only one session for all of this work, meaning that the size of that session can result in memory starvation (both DataNucleus and Isis hold hashes of all objects that have been modified).

The fix is to create a new session for each command, rather than just a single session.

 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)