Bug 738376

Summary:	grinder doesnt handle concurrent write collision causing size mismatch
Product:	[Retired] Grinder	Reporter:	Pradeep Kilambi <pkilambi>
Component:	core	Assignee:	Todd Sanders <tsanders>
Status:	CLOSED EOL	QA Contact:	Preethi Thomas <pthomas>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	unspecified	CC:	jslagle, tsanders
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Pradeep Kilambi 2011-09-14 16:13:12 UTC

Description of problem:

If multiple progresses try to write a downloaded file to same location, grinder probably is not handling the write collisions correctly causing checksum mismatch. This however is self-corrected on its own when checksum validation happens.

We probably need to put in a lock around the writefunction callback. curl might already have a built in opt we might use.

Comment 1 James Slagle 2011-09-14 16:54:50 UTC

This bug probably explains the error messages like this in the grinder log:

grinder.log.3:45037:2011-09-14 02:58:43,094 11105:140718217619200: grinder.BaseFetch:ERROR: activeobject:171 python-2.6.6-20.el6.x86_64.rpm size mismatch, read: 10086936 bytes, was expecting 5043468 bytes

Notice how the read size is exactly twice what the expected size is.

Eventually, we end up in a good state because of the download retries, so that's good.

Comment 2 Pradeep Kilambi 2011-09-19 14:21:29 UTC

fixed! commit 493f87bc20609a1a1b83d56b25d69295f3fd14ad