On 11/18/05, Remy Maucherat <[EMAIL PROTECTED]> wrote: > Costin Manolache wrote: > > So for NIO - we should create another copy of 5 large files ? Most of > > the functions are complete duplicates - a simple extend would eliminate > > them. > > > > The problems are in few abstractions - like Handler - which can be > > easily fixed to > > accomodate NIO / APR or traditional. > > > > NIO is a valid solution - and may be as fast as APR, in particular > > with JDK1.6 - > > and it avoids the JNI layer. > > > > I like APR more too - but I don't think it's wise to say there will be > > no better solution > > in the future :-) It just happens that today APR is faster - and has a > > lot of features beyond > > NIO. > > > > IMO the future is in features integrated at the low-level with the VM > > - in particular > > if they can bypass JNI or use non-garbage-collected heaps ( as in > > real-time java ). It > > would be hard for any JNI solution to beat this - but of course, > > that's future, not so easy > > to predict... > > I completely disagree. APR is a well accepted IO impl for webservers > (obviously), and works very well.
For C++ servers - yes. For Java servers - is anyone else using it besides tomcat ? Even in tomcat - how many people are using the bindings ( compared with the non-apr connector ) ? Unfortunately - NIO is the well-accepted solution for java servers ( all except tomcat are using it ). We know APR is better - but can't pretend it's an 'accepted' solution. > There's room for experimentation as > separate implementations, but should NIO get better and support the > features we need (somehow, I doubt the second one will ever be the case > ...), there's going to be ample time to switch to it later (emphasis on > later; Java 6 as the Tomcat target is quite far away). In the meantime, > I don't see the point of yet another abstraction layer. Not a new abstraction layer - just adjustments to the current one. For example - add the 'long' socket to TcpConnection - and adjust comments in TcpConnectionHandler - so it can be used instead of the Handler. Then most Apr classes could extend the corresponding non-APR classes, and only override what's different. It's not the perfect abstraction - but if you also add NIO, you could later extract a base class that has none of the apr/nio/classic methods, and avoid duplication. Adding NIO in the same way as APR was added would be a nightmare - the current APR code is already messy ( Sendfile for example ). I'm sorry, I like APR, but I can't like the current implementation ( except as a good initial step ). Costin --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
