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 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? > > int sendfile(int out_fd, int in_fd, off_t *_offset, size_t count) > > Waldek > > On Thursday, August 31, 2017 at 6:41:12 PM UTC-4, Waldek Kozaczuk wrote: >> >> 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 cases when -1 is returned: >> 1) >> https://github.com/cloudius-systems/osv/blob/master/fs/vfs/main.cc#L2053 >> - from fstat (what is this comment about one extent?) >> 2) >> https://github.com/cloudius-systems/osv/blob/master/fs/vfs/main.cc#L2071 >> - mmap failing >> >> Is my thinking correct? >> >> Waldek >> >> On Thursday, August 31, 2017 at 6:21:42 PM UTC-4, Waldek Kozaczuk wrote: >>> >>> 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: >>> >>> ngx_log_debug2(NGX_LOG_DEBUG_EVENT, c->log, 0, >>> "sendfile: @%O %uz", file->file_pos, size); >>> n = sendfile(c->fd, file->file->fd, &offset, size); >>> ... - error handling >>> >>> ngx_log_debug3(NGX_LOG_DEBUG_EVENT, c->log, 0, "sendfile: %z of %uz @%O" >>> , >>> n, size, file->file_pos) >>> so why n (equal to what was returned by sendfile() was *4294967295?* >>> >>> It looks like sendfile() lied about bytes copied between descriptors. >>> Why? >>> >>> Waldek >>> >>> On Thursday, August 31, 2017 at 9:14:06 AM UTC-4, Waldek Kozaczuk wrote: >>>> >>>> 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 of the requests fail (2-4 of 5) with dropped >>>> connections. It seems that ab is only getting subset of data for those >>>> failed requests. >>>> >>>> In the browser when I try to reload entire HTML page that involves >>>> fetching 10 or more resources simultaneously most GET requests succeed but >>>> some fail eventually with error like so :net::ERR_CONTENT_LENGTH_MISMATCH >>>> which seems to indicate that data received was different from what was >>>> advertised in Content-Length header received initially from nginx. >>>> >>>> I bumped up the nginx error log settings to debug and I have not seen >>>> any errors. However in case of 5 concurrent requests scenario I only saw >>>> it >>>> handle only 4 requests. Is it because OSv drops connections prematurely? >>>> Or >>>> is it because I am testing it on qemu on OSx and there is some limitation >>>> around virtual networking and timeouts. >>>> >>>> Here are my QEMU arguments: >>>> /usr/local/bin/qemu-system-x86_64 -nographic -m 1024 -smp 4 -device >>>> virtio-blk-pci,id=blk0,bootindex=0,drive=hd0 -drive >>>> file=/my_app/disk.qcow2,if=none,id=hd0,aio=threads,cache=unsafe -device >>>> virtio-rng-pci -chardev stdio,mux=on,id=stdio,signal=off -device >>>> isa-serial,chardev=stdio -netdev user,id=un0,net= >>>> 192.168.122.0/24,host=192.168.122.1,hostfwd=tcp::8000-:8000,hostfwd=tcp::8080-:80 >>>> >>>> -device virtio-net-pci,netdev=un0 -chardev >>>> socket,id=charmonitor,path=/my_app/osv.monitor,server,nowait -mon >>>> chardev=charmonitor,id=monitor,mode=control >>>> >>>> Please see attached ab outputs and nginx log outputs for both single >>>> request and 5 concurrent requests. How can I better debug the problem? >>>> User >>>> traffic sniffer on host side or connect to OSv using debugger? If debugger >>>> then where in call stack put breakpoint? >>>> >>>> I appreciate help solving this problem. I am trying to port existing >>>> static HTML5 app from Apache on Linux to nginx on OSv and would love to >>>> see >>>> it fully work. >>>> >>>> Regards, >>>> Waldek >>>> >>> -- You received this message because you are subscribed to the Google Groups "OSv Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to osv-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
