apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marco Spinetti <m.spine...@pisa.iol.it>
Subject FW: RedHat Linux 7.1 Problem apr
Date Tue, 13 Jan 2004 10:10:46 GMT
Well,

there is another information: really my fprint is outside if: so 
apr_socket_send return APR_SUCCESS but the number of bytes written is 0.

Is it possible?

What could be the possible causes?

What could I do?


--Marco




Marco Spinetti wrote:

> Hi
>
> I have update to latest CVS version, but the problem is still alive.
>
> I have discovered that the problem isn't apr_socket_recv, but 
> apr_socket_send.
>
> I call this function in this way:
>
> .....
> length = strlen(p->query) + 1;
> if (apr_socket_send(sock, p->query, &length) != APR_SUCCESS) {
>        apr_socket_close(sock);
>       fprintf(stderr, "Num caratteri scritti = %d\n", length);
>       .......
> }
>
> The print inside if prints 0: so apr_socket_send writes nothing!!!!
>
> Shall I put apr_socket_send inside a do-while cycle or shall 
> apr_socket_send manage everything?
>
>
> Bye
>
>
> --Marco
>
>
>
> Jeff Trawick wrote:
>
>> Marco Spinetti wrote:
>>
>>>  > ./testall -v testsockets
>>> Partial APR Tests:
>>>   Socket Creation:          ..FFF.
>>>
>>> 6 tests run:  3 passed, 3 failed, 0 not implemented.
>>>
>>> Failed tests in Socket Creation:
>>> 1) tcp6_socket: expected <0> but was <97>
>>> 2) udp6_socket: expected <0> but was <97>
>>> 3) sendto_receivefrom: expected <0> but was <97>
>>
>>
>>
>> Ignore this for now...  testsockets problem (needs to deal with 
>> inability to get IPv6 sockets)
>>
>>>  > ./testall -v testtime
>>> Partial APR Tests:
>>>   Time:                     ..F....F....
>>>
>>> 12 tests run:  10 passed, 2 failed, 0 not implemented.
>>>
>>> Failed tests in Time:
>>> 1) test_localstr: expected
>>> ---->
>>> 2002-08-14 12:05:36.186711 -25200 [257 Sat] DST
>>> <----
>>> but saw
>>> ---->
>>> 2002-08-14 21:05:36.186711 +7200 [257 Sat] DST
>>> <----
>>> 2) test_ctime: expected
>>> ---->
>>> Sat Sep 14 12:05:36 2002
>>> <----
>>> but saw
>>> ---->
>>> Sat Sep 14 21:05:36 2002
>>> <----
>>
>>
>>
>> this was a test driver (not APR) problem fixed on Nov 24th...  if 
>> you're using newer code than Nov 24th, let us know
>>
>>> I have enclose between ** what it seems starnge to me.
>>
>>
>>
>>>  >./testsock
>>
>>
>>
>>> apr_socket_sendfile()->0, sent 25988 bytes
>>> After apr_socket_sendfile(), the kernel file pointer is at offset 0.
>>> ***********apr_socket_recv()->11/Resource temporarily unavailable 
>>> (expected APR_EOF)*******************
>>
>>
>>
>> The problem is that the test program had a non-blocking socket and 
>> didn't handle the case that the peer might not have already closed 
>> the socket by the time apr_socket_recv() was called.  So depending on 
>> timing , the apr_socket_recv() could get APR_EAGAIN instead of APR_EOF.
>>
>> Try this patch.  This is to APR HEAD...  slightly different patch may 
>> be necessary for APR_0_9_BRANCH.
>>
>> Index: sendfile.c
>> ===================================================================
>> RCS file: /home/cvs/apr/test/sendfile.c,v
>> retrieving revision 1.28
>> diff -u -r1.28 sendfile.c
>> --- sendfile.c    24 Nov 2003 13:22:46 -0000    1.28
>> +++ sendfile.c    9 Jan 2004 17:56:22 -0000
>> @@ -484,6 +484,16 @@
>>          exit(1);
>>      }
>>
>> +    /* set socket timeout now; we're just waiting for EOF */
>> +
>> +    rv = apr_socket_timeout_set(sock, apr_time_from_sec(3));
>> +    if (rv != APR_SUCCESS) {
>> +        fprintf(stderr, "apr_socket_timeout_set()->%d/%s\n",
>> +                rv,
>> +        apr_strerror(rv, buf, sizeof buf));
>> +        exit(1);
>> +    }
>> +
>>      bytes_read = 1;
>>      rv = apr_socket_recv(sock, buf, &bytes_read);
>>      if (rv != APR_EOF) {
>>
>>
>
>
>



Mime
View raw message