DVIDNodeService.body_exists takes a long time with some body ids

[csweaver]

For example body id 711583 takes ~ 1 min to return with a 400 status

node_service.body_exists('bodies3', 711583)

---

RuntimeError Traceback (most recent call last)
in ()
----> 1 node_service.body_exists('bodies3', 711583)

RuntimeError: DVID Error (0): DVIDConnection error: http://emdata1.int.janelia.org:8500/api/node/4c832/bodies3/sparsevol/711583

[stephenplaza]

If you try it again does it take a long time. I wonder if the server is just hanging up a bit once in awhile. We could extend the timeout for these requests as well.

[csweaver]

It is always the same body ids that cause it to fail.
1, 1009560, 1009716 are some other examples.

I'll send you an ipython notebook with a minimal example.

[DocSavage]

It should be faster than using sparse volume GET for those bodies, but on
checking over the code, I see the issue: after finding any active RLEs, it
should abort the sequential range query. Currently, there is not a
mechanism to abort a sequential scan, but that should make this much
faster. Will add an issue on DVID repo.

On Tue, Sep 1, 2015 at 3:54 PM, Charlotte Weaver [email protected]
wrote:

It is always the same body ids that cause it to fail.
1, 1009560, 1009716 are some other examples.

I'll send you an ipython notebook with a minimal example.

—
Reply to this email directly or view it on GitHub
#14 (comment)
.

[stephenplaza]

I don't understand. If I call the URI with GET instead of HEAD it is not that big of a body and returns within a few seconds. Why would the HEAD be slower than a normal GET.

[DocSavage]

It shouldn't be unless the range query is incorrect and it's scanning a lot more than necessary. I'm assuming this isn't a driver issue.

[stephenplaza]

I am using curl from the command line and I fetch a 16MB file <1 second using GET. You can try the command because the debug printed that which failed. Calling HEAD is slower and I didn't wait for it to complete. sparsevol-coarse is even faster of course.

[stephenplaza]

Could it be some tombstone issue? I am getting back 200 for non-head calls and I am getting more data than just a few bytes.

[DocSavage]

Don't know. I'll escalate this on the DVID repo to a bug issue from an
enhancement. Something's not right even though it passed the
(non-benchmarking) test. This routine is the first use of a channel-based
range query so there could be some issue, either limited channel buffer or
an outright bug. Let's move the conversation over there.

On Tue, Sep 1, 2015 at 4:11 PM, Stephen Plaza [email protected]
wrote:

Could it be some tombstone issue? I am getting back 200 for non-head calls
and I am getting more data than just a few bytes.

—
Reply to this email directly or view it on GitHub
#14 (comment)
.