On Sun, Sep 3, 2017 at 10:26 AM, Nadav Har'El wrote:
>
> On Fri, Sep 1, 2017 at 7:08 PM, Waldek Kozaczuk
> wrote:
>
>> I changed
>> int sendfile(int out_fd, int in_fd, off_t *_offset, size_t count)
>> to
>> ssize_t sendfile(int out_fd, int in_fd, off_t *_offset, size_t count)
>>
>> and all works
On Fri, Sep 1, 2017 at 7:08 PM, Waldek Kozaczuk
wrote:
> I changed
> int sendfile(int out_fd, int in_fd, off_t *_offset, size_t count)
> to
> ssize_t sendfile(int out_fd, int in_fd, off_t *_offset, size_t count)
>
> and all works like a charm.
>
Wow, thanks, great detective work. When you first
Also turns out that -1 returned by sendfile and corresponding errno is set
to indicate that there is simply not space in the network buffer and nginx
now properly handles this back pressure scenario:
788 2017/09/01 15:56:07 [debug] 0#245: *9 writev: 256 of 256
789 2017/09/01 15:56:07 [debug] 0
I changed
int sendfile(int out_fd, int in_fd, off_t *_offset, size_t count)
to
ssize_t sendfile(int out_fd, int in_fd, off_t *_offset, size_t count)
and all works like a charm.
On Friday, September 1, 2017 at 10:32:24 AM UTC-4, Waldek Kozaczuk wrote:
>
> In all headers and per Linux headers sen
In all headers and per Linux headers sendfile returns values of type
ssize_t (which I think in OSv maps to long). The definition of sendfile in
OSv
(per https://github.com/cloudius-systems/osv/blob/master/fs/vfs/main.cc#L2011)
returns int. This seems to be wrong! Shall it be changed to ssize_t?
It seems like a number conversion issue. *4294967295 *is I think -1 but
when returned to nginx code it becomes *4294967295 *and if(n == -1) does
not happen ... Why
Besides conversion sendfile probably fails.
Per https://github.com/cloudius-systems/osv/blob/master/fs/vfs/main.cc
there are 2 cas
I think the key question is why it is trying to "sendfile" *4294967295 *bytes
of data if file is only *614770 *bytes big?
If you look at the source code
(https://github.com/firebase/nginx/blob/master/src/os/unix/ngx_linux_sendfile_chain.c)
and implementation of ngx_linux_sendfile it does this:
I tested the same exact image on QEMU on Linux host and the app behaves
even worse. It seems that GET requests of files above certain size simply
hang when using curl and eventually timeout with curl complaining it did
not receive enough data back.
Here is more concrete example:
>From curl:
c
Recently I have been playing with nginx on OSv and seeing some errors on
client side (web browser or ab - Apache benchmark) tool.
In general all works fine when I make single request to fetch individual
file. However when I use ab to fetch same file (around 600K big)
concurrently 5 times some o
