[nas] sleep(1)s in ConnSvr.c

[Kris Marsh]

On Mon, Aug 4, 2008 at 5:25 AM, Jon Trulson <jon at radscan.com> wrote:
> On Sun, 3 Aug 2008, Kris Marsh wrote:
>
>> Hi guys,
>>
>> I'm just wondering about the rationale for the sleep(1) at
>> ConnSvr.c:895 ConnSvr.c:1060 and ConnSvr.c:1104.
>>
>> It seems to me that they're all basically pausing after a failed
>> {UNIX,tcp} socket connection. What I'm wondering is why this is
>> happening, and also the reasoning behind the retries. Is it expected
>> that re-trying a failed connection after a second would ever succeed?
>>
>
>  Apparently (according to the comments) it wasn't possible to
>  distinguish between the case where a server was not even listening
>  on the port, and the case where a server was present, but it's
>  listen() backlog was exceeded.  In that case, it is probable that
>  the client could succeed in a future attempt.
>
>  That said, I am not sure how valid that is anymore - specifically,
>  is there now a way to properly distinguish between the two events?
>  If so then the sleep/retry would be correct for the backlog case,
>  and a waste of time for the no-server case :)
>
>> Ultimately, I would love to see these sleeps removed (attached patch),
>> and also the #define AU_CONNECTION_RETRIES 5 at ConnSvr.c:84 set to 0
>> - is there any likelihood of this happening? My application is pausing
>> for 5 secs before it can continue if a NAS server is unable to be
>> contacted.
>>
>
>  To be honest, I am not sure how often a backlog-exceeded condition
>  appears these days.
>
>  It looks like the code would work as you prefer if you simply
>  re-defined AU_CONNECTION_RETRIES to 0.  Have you tried this?
>
>  Maybe that should be the default (or configurable)?
>
> --
> Happy cheese in fear                 | Jon Trulson
> against oppressor, rebel!            | mailto:jon at radscan.com
> Brocolli, hostage.       -Unknown    | #include <std/disclaimer.h>
>

Hi Jon,

Thanks for the response. This is for an application that is using the
NAS client library, rather than linking at compile time, so I don't
think it will be possible to do this (correct me if I'm wrong though!)
- the user would likely have AU_CONNECTION_RETRIES set to the default
(of 5). Having this defaulted to 0 would be a great improvement, as I
guess it would mean a 1 second delay rather than a 5 second delay.

Thanks,
Kris