Bug 840418 - ovirt-engine-backend [RACE]: java.lang.reflect.InvocationTargetException when removing vm and exporting it at the same time
Summary: ovirt-engine-backend [RACE]: java.lang.reflect.InvocationTargetException when...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 3.1.0
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: ---
: 3.1.0
Assignee: mkublin
QA Contact: Dafna Ron
URL:
Whiteboard: storage
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-07-16 10:16 UTC by Dafna Ron
Modified: 2016-02-10 16:41 UTC (History)
11 users (show)

Fixed In Version: SI13
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:
oVirt Team: Storage
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
log (142.56 KB, application/x-xz)
2012-07-16 10:16 UTC, Dafna Ron
no flags Details

Description Dafna Ron 2012-07-16 10:16:21 UTC
Created attachment 598410 [details]
log

Description of problem:

we can remove a vm and export it. 
in one vm we will probably fail on CanDoAction for vm has no disks (which shows that we are not locking this action in the first place) 
in multiple action we would get java.lang.reflect.InvocationTargetException and task will be sent to vdsm: 

root@orange-vdsd ~]# vdsClient -s 0 getAllTasksInfo
e6b20376-0b8f-49ca-bae7-a8302596f259 :
	verb = createVolume
	id = e6b20376-0b8f-49ca-bae7-a8302596f259


Version-Release number of selected component (if applicable):

si10

How reproducible:

100%

Steps to Reproduce:
1. create several vms
2. remove vm's and export vms right away
3. 
  
Actual results:

we have a race because both commands are sent and not blocked by locking mechanism  

Expected results:

we should not be able to send both RemoveVm and ExportVm on the same object without one action failing on lock 

Additional info: full log

Comment 1 mkublin 2012-07-17 08:33:35 UTC
http://gerrit.ovirt.org/#/c/6362/

Comment 3 Dafna Ron 2012-07-30 12:41:36 UTC
verified on si12


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