[
https://issues.apache.org/jira/browse/ISIS-2277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Keir Haywood closed ISIS-2277.
-------------------------------------
> 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
> Priority: Critical
> Fix For: v1 maintenance
>
>
> 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)
