Does it do about the same of behavior as the APR endpoint ? (I didn't try it - I run Windoze for my dev, BTW ;) )
ChannelNioSocket works ok on Windows on low concurrency, but what's the point? ;-). After that, NIO starts throwing weird NPEs.
I haven't tried the APR endpoint on Solaris yet. If I get some time, I'll try compiling it and give it a spin. However the NIO tests suggest that PoolTcpEndpoint will win. There is just not much downside to simply increasing maxThreads on Solaris, but the additional syncs and context-switching do cost.
That's a good question. On Windows, raw throughput (ab on localhost, I suck ...) is slower, but any kind of real test seem more or less equivalent, with sendfile bringing in gains. I don't know if this counts as real testing (probably not).
Linux is faster according to Mladen.
Solaris is untested, but would be interesting indeed.
I would like AJP and HTTP to share more code. Do you think that NIO is a better choice, or should it remain an experiment ? To me, it seems less mature, robust and portable (the most annoying problem probably being that to get bugfixes and feature updates, you need to upgrade the JVM), but I don't have a whole lot of experience.
Most of the split was because Costin designed Jk-Coyote around the JNI stuff. Also, at the time PoolTcpEndpoint didn't support the master-slave model he settled on.
Actually, I'm thinking of leaving ChannelNioSocket in mostly to have something to point to when people show up on the list asking "why doesn't Tomcat use this great NIO stuff?". ;-) The non-blocking io actually works well for AJP (since all of the reads and writes are at most 8K). Using ByteBuffer vs byte [] seems mostly a matter of taste :). Otherwise, I agree that NIO should probably remain an experiment for now.
Of course, it's good comparison, especially since it was done quickly.
Rémy
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]