Bug 1148514 - Engine may kill session that is still in use
Summary: Engine may kill session that is still in use
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: General
Version: ---
Hardware: Unspecified
OS: Unspecified
Target Milestone: ovirt-4.0.0-beta
: 4.0.0
Assignee: Ravi Nori
QA Contact: Lukas Svaty
Depends On:
Blocks: 1157751
TreeView+ depends on / blocked
Reported: 2014-10-01 15:40 UTC by Juan Hernández
Modified: 2016-08-22 12:27 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2016-08-22 12:27:37 UTC
oVirt Team: Infra
rule-engine: ovirt-4.0.0+
rule-engine: planning_ack+
mperina: devel_ack+
pstehlik: testing_ack+

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
oVirt gerrit 55409 0 master MERGED engine: Engine may kill session that is still in use 2016-04-22 07:05:53 UTC
oVirt gerrit 55424 0 master MERGED engine : Add session info to jobs table 2016-04-22 07:38:51 UTC

Description Juan Hernández 2014-10-01 15:40:14 UTC
Currently the engine considers sessions expired when the user logs out or after 30 minutes of inactivity configurable with the UserSessionTimeOutInterval parameter. It doesn't matter if the session is in use or not, it will just be removed. A long running command can have the session it is using killed before it finishes. Also, queued tasks can have their session removed even before they start. This is particularly feasible with the REST API, as a user can start an asynchronous request (wiping a large disk) and then close the session. To fix this the backend needs to keep track of what commands are using a session, and avoid removing the session when there are still pending commands. In addition the backend needs to provide a mechanism that the REST API can use to indicate that an asynchronous task (submitted via ThreadPoolUtil.execute(...)) requires a session, so that this session won't be killed before the task starts the required commands.

Comment 1 Juan Hernández 2014-10-27 15:58:41 UTC
Not strictly the same, but bug 1157751 is another manifestation of the lack of sync between the HTTP session and the backend session. My be considered a duplicate.

Comment 2 Yair Zaslavsky 2015-01-19 11:22:32 UTC
Based on your experience with SDK/REST-API in previous versions - is that a regression?
Backend did not have a mechanism as you described before.
Looks like something we need to involve Command Coordinator (CoCo) in as well.

Comment 3 Juan Hernández 2015-01-19 11:23:39 UTC
No, it isn't a regression.

Comment 5 Alon Bar-Lev 2015-04-14 12:55:07 UTC
without knowing that I anticipated this but was told it cannot happen.

the simplest solution for this case (async) is duplicate the current session into the async context, this session will live as long as the async context lives.

Comment 6 Red Hat Bugzilla Rules Engine 2015-10-19 10:49:48 UTC
Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.

Comment 7 Lukas Svaty 2016-08-19 08:51:51 UTC
verified in ovirt-engine-

checked multiple times, all successful 

verification steps:
1. set UserSessionTimeOutInterval to 1 minute so I don't need 30 minute long tasks
2. create async task that lasts more than 1 minute (preallocated disk creation)
3. make sure async task runs more than a minute
4. check after task is complete for success

Note You need to log in before you can comment on or make changes to this bug.