Thus said Gerald Gutierrez on Sat, 10 May 2014 01:53:56 -0700:
> frame #8: 0x0000000105719ba2 fossil`ssl_receive(NotUsed=<unavailable>,
> pContent=<unavailable>, N=<unavailable>) + 50 at http_ssl.c:399
> 396 size_t got;
> 397 size_t total = 0;
> 398 while( N>0 ){
> -> 399 got = BIO_read(iBio, pContent, N);
> 400 if( got<=0 ) break;
> 401 total += got;
> 402 N -= got;
>
So, it's blocking in the BIO_read function. Hard to say why without more
data about both ends. netstat -na (on both sides) will probably provide
some interesting information (e.g. are there blocks of data queued in
either Recv-Q or Send-Q on either end of the ESTABLISHED connection).
gdb on the remote fossil would provide some other details.
I did find this particular comment about using BIO_read and non-blocking
I/O in OpenBSD's manpage (specifically the last sentence):
One technique sometimes used with blocking sockets is to use
a system call (such as select(), poll() or equivalent) to
determine when data is available and then call read() to read
the data. The equivalent with BIOs (that is call select() on
the underlying I/O structure and then call BIO_read() to read
the data) should not be used because a single call to
BIO_read() can cause several reads (and writes in the case of
SSL BIOs) on the underlying I/O structure and may block as a
result. Instead select() (or equivalent) should be combined
with non blocking I/O so successive reads will request a
retry instead of blocking.
I'm not sure if using this technique would fare any better without
understanding why it's blocking. Is there a firewall reacting to
something it doesn't like? Some other network problem that exists like
lost packets? Does it only happen when using cron? If so, why?
Andy
--
TAI64 timestamp: 40000000536e49ee
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
