> -----Original Message----- > From: Rainer Jung [mailto:[EMAIL PROTECTED] > Sent: 09 December 2008 13:45 > To: Tomcat Users List > Subject: Re: Can not fail over a web service call using mod_jk > > [EMAIL PROTECTED] schrieb: > > From a design point of view do you feel that this is beyond the scope > of > > mod_jk to buffer request bodies? From one point of view it does make > > sense to have the retry logic completely in mod_jk, but I can > certainly > > understand the point of view to have retry logic on the client. > > Not completely, but it would be a serious problem to buffer the full > request bodies by default. Imagine someone who does upload a DVD iso > image. So it's much safer (with respect to ressource consumption) to > only buffer a first chunk for the usual case, that a problem is > detected > early. > > It could be an option though, to buffer requests with a configurable > limit depending on the URL. It would not be to hard to implement that, > but the whole thing gets more and more complex. It might make more > sense
That might just be very handy. We have some network devices higher up the application stack which have request retry capabilities, it is another possible place to have retries. If retries were implemented in some form in modjk having the ability to define what a failure is would be very handy. The ability in modjk 27 to have a separate process/thread that monitors the connection pool (connection probing)makes request retry very much a boarder case in my opinion. It would probably be better to have more customization ability to exactly specify what a failure is for the connection probing watchdog thread rather than implementing request retry. Regards ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
