Oleg, > I find this a little extreme. My recommendation was always to disable > the stale connection check and to provide a robust request retry handler > instead. A production quality application must be prepared to deal with > and gracefully recover from all sort of I/O failures _anyways_, so what > is the point in treating I/O failures due to stale connections somehow > differently?
I think the fundamental point is encapsulation. HTTP library users should not be burdened with details and complexities of internal connection pooling/management implementation. Unlike other I/O errors, stale connections are not really failures, they are expected normal internal events that will occur very often, so they should be handled automatically and transparently by HTTP library. These are the same reasons why TCP libraries transparently handle packet retransmission instead of pushing this responsibility to all clients. BTW: when do you expect 1st alpha of HttpClient 4.0? :-) Thanks. - Andrew --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
