Jim, I just committed a fix for the problem to CVS. The solution I used is slightly different from yours: Instead of the whole LiteWorker.execute() method, only the sending of the request and the parsing of the response headers are put into a try-retry wrapper. Otherwise, we'd retry to call the server even if the first call actually got through already and the error occurred somewhere later, e.g. when parsing the response.
thanks, Hannes Jim Redman wrote: > On 2002.02.27 08:43:34 -0700 Hannes Wallnöfer wrote: > >> Thanks Jim. One problem I see with your solution is that it retries >> on *every* exception, which is not what we want (or do we?). I'll >> give it a try. > > > > I'm not sure that there is sufficient information at this point to > determine whether the write failed because of an expired keep-alive or > for other reasons. In a practical sense, once the system is running > we see exceptions here only because of failed keep-alives. > > Which leads into Dan's point > On 2002.02.27 08:31:58 -0700 Daniel Rall wrote: > >> Interesting. Submit a patch >> <http://jakarta.apache.org/site/source.html> >> with multiple retries (so a constant or something can be changed to >> configure the number of retries to attempt), and remove the early >> return. > > > The number of retries is exactly one if the cause of the failure is an > expired keep-alive. The system should not just quit becuase the > keep-alive expired, but if the (single) retry doesn't succeed then the > problem is not an expired keep-alive. > >> Also, I'm not especially familiar with the client code, but >> does this change belong in the XmlRpcClient super-class? > > > I have no idea - I don't use the XmlRpcClient directly, only the Lite > so I don't know the behavior of the XmlRpcClient in this case. > > > Jim > >
