Re: [cpp-netlib-devel] Unable to build tests

[Dean M. B. <mik...@gm...>]

On Wed, Feb 16, 2011 at 11:28 AM, Oleg Malashenko
<ole...@gm...> wrote:
> On 16.02.2011 12:46, Dean Michael Berris wrote:
>> On Wed, Feb 16, 2011 at 10:38 AM, Oleg Malashenko
>> <ole...@gm...> wrote:
>>> On 16.02.2011 03:38, Gregory Symons wrote:
>>>> The following tests FAILED:
>>>>        14 - cpp-netlib-hello_world (Failed)
>>>>        15 - cpp-netlib-http_async_server (Failed)
>>>>        16 - cpp-netlib-http_server_async_less_copy (Failed)
>>>>        17 - mime-roundtrip (Failed)
>>>>
>>>> Looking closely at the verbose test output, it looks like they all
>>>> failed because the address they were trying to bring up the server on
>>>> was still in use.
>>>>
>>>
>>> Will you please try it with the following patch?
>>>
>>
>> Why isn't this a pull request Oleg? :D
>>
>
> Because I don't know if it is going to work.

Actually, you're right. It won't work...

> In fact, terminating test
> applications is not the best way to close network sockets (see
> http_server_async_less_copy). If test suite doesn't actually try to run
> several tests simultaneously and they all try bind to the same port,
> than I think we hit TIME_WAIT problem here.
> http://hea-www.harvard.edu/~fine/Tech/addrinuse.html
>

... because there's no cross-platform reliable way to run the test
from Python and tell the spawned process to die -- unless you want to
deal with pipes and all that (not-so-)goodness.

Unless someone wants to maintain a signal handler for Windows and
various flavors of Unix just for the test servers (I don't), it's
better to have the port be a runtime parameter to the application, and
use one port for each test. Also maybe making a test-specific "kill
handler", like a special URL that would actually trigger a call to a
server's stop method would be a good way to do it. Even then though
the TIMED_WAIT problem would still be there on the server port in
which case we'll still need the runtime port number option.

> Oh, and Gregory, I almost forgot about sync server. Here is the new
> patch, that sets SO_REUSEADDR in sync_server as well as in async_server.
>

This will only work if it's the same binary trying to re-use the
address. In 0.9-devel I already have this as a constructor parameter.

Also, this has some serious weirdness on Windows too as reported by
Erik a while back -- which is why the SO_REUSEADDR setting was removed
from the server core and moved into a Boost.Parameter option in
0.9-devel.

HTH

-- 
Dean Michael Berris
about.me/deanberris