im on Windows XP pro, jdk1.4.1_02, tomcat 4.1.24. my guess would be the
classpath is too long and gets truncated hence the "C:\Tomc?".
thois would be a good point for ANT-guys! because they could use the
CLASSPATH-env-variable instead, so the command-line would stay short.
"[javac] Since fork is
3. On top of regular request/response. Almost everything related with auth,
pings, discovery, reconfiguration can be implemented by just using regular
Ajp13 requests - with a special URL. That is by far my favorite mechanism.
It also has the advantage that it can reuse other parts of tomcat - mappe
I took a short look at the ajp13 protocol draft, and the design of the
protocol is really simple, too simple.
There are few knwon problems with the protocol - both sides of jk2 are
designed to support multiple protocols and extensions.
yes, but how? how can either client or server guess, which ext
There is another problem with how mod_jk handles the ajp connetor sockets.
That is the one to one mapping of apache child process to an ajp connector.
On an apache server that serves normal http requests you can end up with
many idle socket connections to Tomcat, and Tomcat will spawn many more
Con
Yes, Exception is a special object which is costly to create and costly
to trap.
i hope, that catching Exception is optimized by the Java, because it
happens quite often in java-programs.
creating on exception object, throwing it etc. should happen quite seldom.
When Apache will be closing conne
read-error should not happen, as mod_jk could send a quit-paket or
something (analog to the ftp-protocol)
read-error happen BECAUSE APACHE HTTPD server close client
when it recycle them.
i hoped, you would react on this one.
What's the problem with this connection closing handling ?
tomcat detect
i looked into these sources, and i am shocked!!!
this.receive() uses this.read(), and this method finally calls the
InputStream.read(). as everybody should know, InputStrean.read()
returns -1 if the end of the inputstream is reached.
this case is checked, but instead of doing something useful, t
read-error should not happen, as mod_jk could send a quit-paket or
something (analog to the ftp-protocol)
read-error happen BECAUSE APACHE HTTPD server close client
when it recycle them.
i hoped, you would react on this one.
i'm not very much into apache httpd's internals, but i guess, that a
ch
void processConnection(MsgContext ep) {
try {
MsgAjp recv=new MsgAjp();
while( running ) {
int status= this.receive( recv, ep );
i looked into these sources, and i am shocked!!!
this.receive() uses this.read(), and this method finally calls the
I
Could you give us more information :
- jk version you're using (jk or jk2)
mod_jk (not mod_jk 2) version 1.2.2
- Apache webserver (1.3/2.0)
apache 1.3.27
- Operating system hosting tomcat and apache
it's suse linux 7.3 with kernel 2.4.20 with sun jdk 1.4.1_01
This message appears in tomcat in w
Is this mod_jk 2?
no, i'm not using mod_jk 2 because i read, that it isn't that well
testet yet.
I am very familiar with mod_jk 1.2/AJP13 and could answer your questions
for it, but your log message imply you are using mod_jk 2 which I am not
familiar with enough to answer your question. Costin?
I am getting the exact same messages as of upgrading from 3.2.3 to 4.1.18 yesterday.
i think everbody gets these messages, but nobody has ever states, if
they are normal, should be fixed, can be fixed or where the hell they
came from!
when will finally somebody of the tomcat-team comment the s
hi,
i didn't get any useful response in the tomcat-user-mailinglist.
many users have messages in their catalina.out, saying that a socket
times out, or a connection had been closed.
these messages look like this:
25.02.2003 20:22:48 org.apache.jk.common.ChannelSocket processConnection
INFO: conn
13 matches
Mail list logo
