On 10/24/05, Remy Maucherat <[EMAIL PROTECTED]> wrote: > > For sending a file on a socket - I'm sure using apr would be faster ( > > is sendfile wrapper implemented ? ), you shouldn't have to read the > > file in java. > > You need to look a bit into the code ;) > > There is: > - APRized HTTP connector with sendfile and poller usage for keepalive > - HTTPS support using OpenSSL > - APRized AJP connector with poller usage for keepalive
I tought there is something for keepalive in the java connector as well - I guess I was looking in the wrong place, I know apr can do all the cool things, but I couldn't find the equivalent code. It may be nice - and maybe that would make the apr and java code share more code :-) > > An unrelated subject - don't know if you saw > > http://www.mortbay.com/MB/log/gregw/?permalink=Jetty6Continuations.html > > > > I don't like very much the implementation ( with Exceptions to control > > the flow ), but I think there is a good idea to have support in the > > thread pool to temporary release the thread for long-running servlets, > > and then get a thread back on some event. How this is made visible to > > servlets is debatable - I think there are few better ways than what > > jetty is doing - but the low level is probably more important. > > I don't like it: > - the naming is bad (this is using a poller to get read events, so it's > basically an IO event mechanism) Yes, the naming is horible - just some buzzwords with little connection with the real feature. It is a way to do even-based IO for servlets - but regardless of name, the actual feature can be usefull. At least for a sandbox setting :-) Not a big priority for me - I was hoping other people would be interested too. > - it shouldn't just reinvoke the service method unless it can actually > just continue transparently execution (also, in the "compatibility" > mode, the execution path isn't the same), and creates the need for > proprietary routing logic I agree, the high-level doesn't look good - and it never does, for all event-based systems :-), even those who don't try to hide this behind a thread-based interface like service(). > - it encourages a design for servlets which will run very badly on other > servlet containers Well, long running servlets ( bound to events or slow IO ) will run bad anyway on pure threads servers. But if more servers support the concept - maybe a good solution would emerge, and become part of a future standard. It would certainly be better than seeing it in the next servlet spec - without enough implementation experimentation. > It could be implemented relatively easily in the APRized connectors, but > given the cost to process a small request over a keepalive connection > (it's cheap; for example, the use case for this being a chat room, I > don't see how it would perform bad if using separate requests for each > message), I don't see any reason to support this. In the chat room case - you can never get 'instant' messages, you depend on the polling frequency. Costin --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
