Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1148514

Summary:	Engine may kill session that is still in use
Product:	[oVirt] ovirt-engine	Reporter:	Juan Hernández <juan.hernandez>
Component:	General	Assignee:	Ravi Nori <rnori>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Lukas Svaty <lsvaty>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	---	CC:	bugs, gklein, iheim, juan.hernandez, lsurette, mperina, oourfali, rbalakri, rnori, sbonazzo, s.kieske, srevivo, ykaul
Target Milestone:	ovirt-4.0.0-beta	Flags:	rule-engine: ovirt-4.0.0+ rule-engine: planning_ack+ mperina: devel_ack+ pstehlik: testing_ack+
Target Release:	4.0.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-08-22 12:27:37 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Infra	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1157751

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-4.0.2.6-0.1.el7ev.noarch

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