HTTP performance markers use blocking reads about davix

[gbitzes]

Hi Brian,

request->readLine returns data as it becomes available, ie as soon as there's a complete header line separated by \r\n.

1024 is just a protection against buffer overflow, an instruction never to write more than 1024 bytes into the buffer.

What you're observing is probably due to this check: https://github.com/cern-it-sdc-id/davix/blob/devel/src/modules/copy/copy.cpp#L332

The performance information is only updated once a second to avoid printing too much text into the terminal. I could make this behaviour configurable if you're interested, ie changing the time interval, or disabling altogether and printing performance markers as they're received.

[bbockelm]

Look at the case of the first performance marker (assuming no data is buffered in NEONRequest).

The readLine method calls readSegment here:

https://github.com/cern-it-sdc-id/davix/blob/5af51b01abdebeb93915faf4d58e511cd69500aa/src/neon/neonrequest.cpp#L773

Then, readSegment invokes readBlock (which appears to pull in a single encoded chunk from the HTTP transfer) repeatedly:

https://github.com/cern-it-sdc-id/davix/blob/5af51b01abdebeb93915faf4d58e511cd69500aa/src/neon/neonrequest.cpp#L803

As far as I can tell, this is repeated until all 1024 characters (the buffer size in this case) are read.

Playing with a few transfers of multi-GB files with performance markers sent every 2 seconds, it seems that the symptoms match blocking behavior.

[gbitzes]

ahhh, yes... you're totally right.

I committed a fix, want to try?

[bbockelm]

Appears to work -- thanks!