Bug 738376 - grinder doesnt handle concurrent write collision causing size mismatch
Summary: grinder doesnt handle concurrent write collision causing size mismatch
Keywords:
Status: MODIFIED
Alias: None
Product: Grinder
Classification: Retired
Component: core
Version: unspecified
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Todd Sanders
QA Contact: Preethi Thomas
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-09-14 16:13 UTC by Pradeep Kilambi
Modified: 2013-02-27 02:37 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:

Attachments (Terms of Use)
Add an attachment (proposed patch, testcase, etc.)

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
Note You need to log in before you can comment on or make changes to this bug.