Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

srm: Fix saving of transient states to database #2080

Merged
merged 2 commits into from
Jan 7, 2016

Conversation

gbehrmann
Copy link
Collaborator

Motivation:

SRM has options of controlling whether job history is stored to the
database as well as whether transient (unimportant) states are
stored.

Yet, the various job storage decorators apply filtering based
on whether job history is enabled. Specifically this means that
if storage of transient states is enabled while job history is
disabled, transient states are not stored.

Modification:

Remove the unnecessary filtering from various job storage implementations.
Renamed FinalStateOnlyJobStorageDecorator to ForceOnlyJobStorageDecorator
since the Scheduler is already forcing save of jobs in final states and
there is no reason to check for final states in the decorator.

Result:

Fixed interpretation of srm.persistence.enable.store-transient-state when
srm.persistence.enable.history is disabled. This may put additional load
on the SRM database if store-transient-state is true and enable.history
is false - the old behaviour can be restored by setting both properties
to false.

Target: trunk
Require-notes: yes
Require-book: no
Request: 2.14
Request: 2.13
Acked-by: Paul Millar paul.millar@desy.de
Patch: https://rb.dcache.org/r/8889/
(cherry picked from commit cadec14)

Motivation:

SRM has options of controlling whether job history is stored to the
database as well as whether transient (unimportant) states are
stored.

Yet, the various job storage decorators apply filtering based
on whether job history is enabled. Specifically this means that
if storage of transient states is enabled while job history is
disabled, transient states are not stored.

Modification:

Remove the unnecessary filtering from various job storage implementations.
Renamed FinalStateOnlyJobStorageDecorator to ForceOnlyJobStorageDecorator
since the Scheduler is already forcing save of jobs in final states and
there is no reason to check for final states in the decorator.

Result:

Fixed interpretation of srm.persistence.enable.store-transient-state when
srm.persistence.enable.history is disabled. This may put additional load
on the SRM database if store-transient-state is true and enable.history
is false - the old behaviour can be restored by setting both properties
to false.

Target: trunk
Require-notes: yes
Require-book: no
Request: 2.14
Request: 2.13
Acked-by: Paul Millar <paul.millar@desy.de>
Patch: https://rb.dcache.org/r/8889/
(cherry picked from commit cadec14)
Motivation:

We have observed incosistencies in the srm database content in which the
request state was different than the last logged transition.

Modification:

Place a read lock on the job to get a consistent view of the job's state.

Result:

Hopefully a more consistent srm database.

Target: trunk
Request: 2.14
Request: 2.13
Require-notes: yes
Require-book: no
Acked-by: Paul Millar <paul.millar@desy.de>
Acked-by: Dmitry Litvintsev <litvinse@fnal.gov>
Patch: https://rb.dcache.org/r/8890/
(cherry picked from commit b77d532)
paulmillar added a commit that referenced this pull request Jan 7, 2016
srm: Fix saving of transient states to database
@paulmillar paulmillar merged commit 56485c3 into dCache:2.13 Jan 7, 2016
@gbehrmann gbehrmann deleted the fix/2.13/rb8889 branch May 19, 2016 12:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants