On Fri, 04 Jun 2010 19:52:50 -0000, Robert Collins <email address hidden> wrote:
> Well, for recv to be hung, we need the tcp session to appear live and
> the sender to not send us data.
>
> Some possibilities:
> - its not hung, they are deliberately drip feeding us
> - the sender has died but some networking config has prevented us
> noticing (e.g. tcp keepalive is off and the other machine rebooted
> without shutting down the links, or a firewall in the middle was
> rebooted and lost its state, and because we're only receiving, we
> don't get notified that its rejecting packets.)
>
> For the former, asking them is best, for all of the latter cases,
> making sure we have a tcp keepalive that is set nice and low would be
> a good strategy: we don't want any idle connections in this service,
> so setting it to (say) 5 minutes might help.
That's at the software level, or configuration?
It's using urllib2 to get the lists, and bzr transports for the
packages.
On Fri, 04 Jun 2010 19:52:50 -0000, Robert Collins <email address hidden> wrote:
> Well, for recv to be hung, we need the tcp session to appear live and
> the sender to not send us data.
>
> Some possibilities:
> - its not hung, they are deliberately drip feeding us
> - the sender has died but some networking config has prevented us
> noticing (e.g. tcp keepalive is off and the other machine rebooted
> without shutting down the links, or a firewall in the middle was
> rebooted and lost its state, and because we're only receiving, we
> don't get notified that its rejecting packets.)
>
> For the former, asking them is best, for all of the latter cases,
> making sure we have a tcp keepalive that is set nice and low would be
> a good strategy: we don't want any idle connections in this service,
> so setting it to (say) 5 minutes might help.
That's at the software level, or configuration?
It's using urllib2 to get the lists, and bzr transports for the
packages.
Thanks,
James