[EMAIL PROTECTED] schrieb: >> [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.
I'm looking forward to httpd 2.4 with mod_luau aka mod_wombat, an embedded Lua interpreter that has access to httpd objects (like the request object) and will allow us to inject custom logic e.g. for balancing and error reaction. Not sure yet, whether having a Lua script in the loop for every request is a performance killer (that will obviously depend on your expected throughput), but it certainly is lightweight enough for the watchdog thread and most likely also for handling error cases. More to come in 2009 as 2.4 gets closer. Regards, Rainer --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
