>> Now the only performance issue on my list is mod_jk ( the >java side still >> need work to improve a bit the performance ). But fixing the bugs and >> making tomcat easier to use is far more important - and the connector >> module can be released independently, as a standalone module >( i.e. after >> 3.3 is released - stability is also more important than performance, >> I would vote for an ajp14 for performance and other "dev" >enhancements, >> and making ajp13 the "stable" protocol instead of 12 ). > +1. >We're still shaking weird little bugs out of the ajp13 >implementation(s), >and people are relying on it for production use. I don't >think we should >muck around with the protocol itself. Yep, we're even using mod_jk native code against tc 3.2.1 in production >When ajp14 is developed, the spec should really contain a >standard response >for an "unknown packet", so new packet types (or messages) can >be added to >the protocol without breaking backward compatability. If we >had this in >ajp13, we could add some very nice things as negotiated features (e.g. >encrypted and/or authenticated connections). However, because >ajp13 has no >way to respond to an unknown packet, the implementations >generally behaves >very badly if you send them something they're not expecting. A general solution to handle unknown packet will be to encapsulate them with header len ie : CMD1 - CMD1-LEN - CMD1-DATA - CMD2 - CMD2-LEN - CMD2-DATA .... I allways use that method and got code handling unknown message. We could also exchange at init of the link protocol level message negociation. ie Do you known X, Y, Z, and the other part respond with YES, YES, NO..... And to help restore an init state, we could introduce the RESET COMMAND that will trash data in both buffs and restart in a clean situation. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
