#1505 closed defect (fixed)

Error in Latency Report on MDMF Retrieve

Reported by: zancas Owned by: kevan
Priority: major Milestone: 1.9.0
Component: unknown Version: 1.9.0a1
Keywords: mdmf latency statistics response-time Cc:
Launchpad Bug:


I viewed a write cap to a MDMF, with an associated 8MB file, in the WUI. The retrieve operation reported a 41 year latency in Per-Server Fetch Response Times. All servers were running on the same machine. (My laptop.)

Attachments (1)

response_time_error.html (3.1 KB) - added by zancas at 2011-08-26T18:22:07Z.

Download all attachments as: .zip

Change History (8)

Changed at 2011-08-26T18:22:07Z by zancas

comment:1 Changed at 2011-08-27T16:46:11Z by kevan

  • Owner changed from nobody to kevan
  • Status changed from new to assigned

comment:2 follow-up: Changed at 2011-08-27T16:59:40Z by kevan

This specific issue is due to a bug around line 806 of retrieve.py:

         # validate this block, then generate the block hash root.
         self.log("validating share %d for segment %d" % (reader.shnum,
         self._status.add_fetch_timing(reader.peerid, started)
         self._status.set_status("Valdiating blocks for segment %d" % segnum)

started is the time at which the fetch was started. RetrieveStatus.add_fetch_timing wants the elapsed time, though, so what we really want is time.time() - started. I'll attach a patch with this change.

While investigating this bug, I noticed several other rough spots in how the retrieve process interacts with its status object. In particular,

  • The progress field is set to 0.0 in Retrieve.__init__, then never touched again, so it says 0.0% even though the retrieve is finished.
  • The decrypt and decode timing doesn't take into account multiple segments, so later segments clobber the timing data for earlier segments and the report page only shows decrypt and decode timing data for the last segment.
  • The status field says "decrypting" even though the retrieval process has finished.

It's easy enough to be attentive about updating the status and progress fields. We can measure cumulative decryption and decoding time to address the second point; this requires minor modifications to the retrieve code and status code, and a wording tweak on the status template.

(Do these issues deserve their own ticket? I'll open one if so.)

comment:3 in reply to: ↑ 2 Changed at 2011-08-28T03:39:19Z by davidsarah

Replying to kevan:

Do these issues deserve their own ticket? I'll open one if so.

I don't think so, this one is short enough.

comment:4 Changed at 2011-08-28T23:25:42Z by warner

I've been in a fix-everything-in-sight mood this weekend, so I took care of this one in 9756146d61673552.

comment:5 Changed at 2011-08-28T23:27:07Z by warner

  • Milestone changed from undecided to 1.9.0

comment:6 follow-up: Changed at 2011-08-29T06:37:08Z by warner

  • Resolution set to fixed
  • Status changed from assigned to closed

hm, not sure why the auto-closer didn't notice the comment in 9756146d61673552. Closing it manually.

comment:7 in reply to: ↑ 6 Changed at 2011-08-29T14:38:01Z by davidsarah

Replying to warner:

hm, not sure why the auto-closer didn't notice the comment in 9756146d61673552.

I think the action name ("fixes") is case-sensitive, so didn't match "Fixes". Code here.

Note: See TracTickets for help on using tickets.