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

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

    [ https://issues.apache.org/jira/browse/ISIS-2277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17033195#comment-17033195 ] 

ASF subversion and git services commented on ISIS-2277:
-------------------------------------------------------

Commit e67c3b0aedbc7f07ef9629b0fbd81bd44ba5c8ad in isis's branch refs/heads/v1 from danhaywood
[ https://gitbox.apache.org/repos/asf?p=isis.git;h=e67c3b0 ]

ISIS-2277: reworks BackgroundCommandExecution so that each command runs in its own session.

We convert all commands into bookmarks as the means to pass from one session to another


> 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: 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)