Hi, > The implementation would be an alternate endpoint implementation, > replacing PoolTcpEndpoint. Alternate HTTP/1.1 processor and socket > channel (for AJP) will be provided. Development required is actually > fairly small (significant testing will be required, however). I didn't > do the updated socket channel yet, but after 3 days of hacking, HTTP > works (and the AJP stuff should be much faster to do).
If it's truly independent, with an alternative PoolTcpEndpoint java class and some additional dependencies (APR and the specific JNI wrapper), then +1. At least for the first few releases, users should have the choice to use this technology, and not have it be required. I think that's what you meant anyways, just stating it for clarity. We can call it "experimental," advertise it, and get 3rd party (e.g. Peter Lin) benchmarks. It'd be a very nice selling point to have a non-blocking IO option ;) > - is it appropriate for 5.5 ? I'd say yes, as it will be a separate > independent implementation I'd also say yes. Yoav --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
