While playing with 4.1.15, I discovered some nasty problem with the
AJP13 implementation from JTC.
1) TC 4.1.15 set socket timeout (2 = 20s) which make give you
Read exception after 20s of inactivity between webserver and Tomcat :
90577 [Thread-6] ERROR common.ChannelSocket - Error,
http://localhost:8080/mht/servlet/HttpReceive is the url...
HTTP Status 405 - HTTP method GET is not supported by this URL
type Status report
message HTTP method GET is not supported by this URL
description The specified HTTP method is not allowed for the requested
resource (HTTP method GET is
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14699.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Mladen Turk wrote:
Hi,
Seems that we have some problems reading POST data from Apache2.
My proposal is to add the read ahead buffer.
Looking at some modules I found that most of them has that feature.
For example mod_isapi has a default read ahead buffer length of 49152
bytes (48 k). (Why?)
Hi,
the nightly build of Tomcat 3.3.x seems to have stopped at 08-Nov-2002.
Any Idea, why?
Cheers,
Hans
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Hans Schmid wrote:
Hi,
the nightly build of Tomcat 3.3.x seems to have stopped at 08-Nov-2002.
Any Idea, why?
Cheers,
Hans
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
What's the error ?
--
To unsubscribe, e-mail:
How can i change the default port number which is 8080 to any number ?
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14282.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Just take a look in the server.xml configuration file. In this file you find
a xml document that represents the configuration for Tomcat
$TOMCAT_HOME/conf/server.xml).
Here :
!--
Define a non-SSL HTTP/1.1 Connector on port 8080
--
Connector
Check out if the servlet supports GET requests.
Pedro Igor
- Original Message -
From: myAyala TAN, Nelson C. [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, November 20, 2002 5:28 AM
Subject: Probem: HTTP Status 405 - HTTP method GET is not supported by this
URL
Last time they were created was 08-Nov-2002 but today is the 20.11.2002 ;)
http://jakarta.apache.org/builds/jakarta-tomcat/nightly-3.3.x/
Parent Directory -
JmxSupport.war 08-Nov-2002 06:28 459K
PasswordPrompter.war
Hi,
Apache isn't the bugger here. The jni itself is unable to process the
POST data.
The channel_jni is invoked for the getChunk (id 6), but then nothing
happens (at least I wasn't been able to trace any jni_send).
It invokes the response dispatcher, but then nothing happens. (Think
that this
Hi Hans,
The 3.3.x nightly is currently run by hand so that the zips
are built on Windows and the tar.gzs are build under Unix.
I typically update it after I see changes come through.
I'll run another build to get things more current, in case
I have missed something.
I hope to start helping more
remm2002/11/20 05:47:48
Modified:coyote/src/java/org/apache/coyote/tomcat5 CoyoteWriter.java
Log:
- Full reimplementation of PrintWriter (more optimized for web oriented
applications).
- Fix bug 14658.
Revision ChangesPath
1.2 +181 -15
remm2002/11/20 05:47:58
Modified:coyote/src/java/org/apache/coyote/tomcat4 CoyoteWriter.java
Log:
- Full reimplementation of PrintWriter (more optimized for web oriented
applications).
- Fix bug 14658.
Revision ChangesPath
1.2 +181 -15
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14658.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
hgomez 2002/11/20 06:14:20
Modified:jk/java/org/apache/ajp/tomcat4 Ajp13Connector.java
Log:
Add Linger support, and add some comments about IP settings for AJP13
Revision ChangesPath
1.16 +64 -6
hgomez 2002/11/20 06:16:46
Modified:jk/java/org/apache/jk/common ChannelSocket.java
Log:
When a socket timeout exception appears
(why set timeout for ajp13 connections ?), the socket is not closed,
and even if tomcat remove the thread the socket is still open and make
Does anyone know if the javac memory leak still exists (1.4.1 docs say
it does not).
I have a test the goes through a bunch of jsp pages and if they are not
precompiled I get a out of memory exception.
Thanks,
John
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional
I haven't seen the memory leak on solaris or windows, but isn't the leak
only on linux?
I thought jasper2 fixes the problem with com.sun.tools.javac.Main since
it uses the system native javac?
peter
John Trollinger wrote:
Does anyone know if the javac memory leak still exists (1.4.1 docs
We are using Tomcat 4.1.12 on windows and when running an automated test
that navigates through a set of about 75 jsp pages (they have includes
in them that kick of more compiles) it gets a OutOfMemoryException
halfway through the compile. Our system is quite complex so I don't
know if I can get
Hmm, that sounds bizzare. I'm been using/testing 4.1.10-4.1.12 on both
solaris and windows with jdk1.4.1. I've ran several stress test using
JMeter simulating light to medium (64 concurrent connections) load for
1-10K requests without any problems. My pages are heavy on JSTL, so they
are fairly
If the pages are precompiled I do not have any problems at all, it is
only when the jsp cache has been deleted that this shows up.
John
-Original Message-
From: peter lin [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, November 20, 2002 9:57 AM
To: Tomcat Developers List
Subject: Re:
mturk 2002/11/20 07:03:19
Modified:jk/native2/jni jk_jni_aprImpl.c
Log:
Fix the POST data.
The reply buffer shuld containg the endpoint's post message.
Revision ChangesPath
1.42 +1 -1 jakarta-tomcat-connectors/jk/native2/jni/jk_jni_aprImpl.c
Index:
by any chance do you have multiple webapps or just one? in my case, I
only have one webapp which has some services it loads when tomcat
starts. All of my pages are dynamic with all the text in
resourceBundles. The dynamic data is retrieved from a middle layer in
XML format. JSTL is used to get
We have 2, one is webdav and the other is our actual application. We
use a lot of custom tags and a lot of both types of includes (when I say
a lot we have jsp pages that include over 500 other jsp pages, and no,
this is not my design :) )
-Original Message-
From: peter lin
John Trollinger wrote:
We have 2, one is webdav and the other is our actual application. We
use a lot of custom tags and a lot of both types of includes (when I say
a lot we have jsp pages that include over 500 other jsp pages, and no,
this is not my design :) )
I'm guessing there's
But that would not account for the leak only occuring when pages need a
compile. If the pages are compiled I never see the leak.
-Original Message-
From: peter lin [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, November 20, 2002 10:43 AM
To: Tomcat Developers List
Subject: Re: Javac
you never know. if it's a slow leak, precompiled pages may not exhibit
the leak. I only discovered the leak in our custom tag when I put the
app under moderate/medium load. Under light load the bug wasn't
apparent.
I'm guessing if you hit each page individuall slowly, the bug doesn't
appear. If
mturk 2002/11/20 08:40:10
Modified:jk/native2/jni jk_jni_aprImpl.c
Log:
Revert the usage of post msg.
Use the suplied reply, and fix the 4 byte out-of-bounds exception
Revision ChangesPath
1.43 +1 -1 jakarta-tomcat-connectors/jk/native2/jni/jk_jni_aprImpl.c
mturk 2002/11/20 08:41:15
Modified:jk/native2/common jk_handler_response.c
Log:
Use the supplied msg instead of directly referencing
endpoint's post msg. That fixex the JNI post readings.
Revision ChangesPath
1.25 +1 -2
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14714.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
I also have no memory leak problems now with Tomcat 4.1.12.
But i'm using jikes instead of javac as jsp page compiler.
Whats about switching to jikes. If the memory leak problem is gone
with jikes, javac still leaks memory, otherwise it is a problem in the jsp
pages.
Cheers
Holger
-
mturk 2002/11/20 09:25:41
Modified:jk/native2/common jk_workerEnv.c jk_handler_response.c
Log:
For stream channels (sockets) use the supplied msg for
getChunk handler.
Revision ChangesPath
1.58 +2 -2
I'm running a webmail aplication on tomcat4.1.10 + apache2.0.34 +
mod_jk2
when a user breaks the browser connection while downloading data (=mail
attachment) from tomcat i get the following error on the apache side:
[Wed Nov 20 18:03:24 2002] [error] Error ajp_process_callback - write
failed
mturk 2002/11/20 09:29:11
Modified:jk/native2/common jk_msg_ajp.c
Log:
Use the logger for dump method instead of using stderr.
Revision ChangesPath
1.20 +2 -1 jakarta-tomcat-connectors/jk/native2/common/jk_msg_ajp.c
Index: jk_msg_ajp.c
Alexander Leyke wrote:
Costin Manolache wrote:
In jk2 we use ajp13 for all channels, including JNI. That allows us to
reuse the buffers and avoid object allocations from C - which improves a
lot the performance of the code ( we also avoid a lot of expensive calls,
etc ). Same technique is also
-Original Message-
From: Jacco Braat
[Wed Nov 20 18:03:24 2002] [error] Error ajp_process_callback
- write failed [Wed Nov 20 18:03:24 2002] [error]
ajp13.service() ajpGetReply unrecoverable error 3 [Wed Nov 20
18:03:24 2002] [error] ajp13.service() Error forwarding
Mladen Turk wrote:
Hi,
Apache isn't the bugger here. The jni itself is unable to process the
POST data.
The channel_jni is invoked for the getChunk (id 6), but then nothing
happens (at least I wasn't been able to trace any jni_send).
It invokes the response dispatcher, but then nothing
We could use the gump-generated builds.
( it seems we just need to zip the build tree and add a symlink )
Costin
Larry Isaacs wrote:
Hi Hans,
The 3.3.x nightly is currently run by hand so that the zips
are built on Windows and the tar.gzs are build under Unix.
I typically update it after
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8763.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
-Original Message-
From: Costin Manolache
It's most likely a bug. I know Nacho is using JNI with IIS - and the
code looks fine.
Yeah, it was... Just fixed it in the cvs. We were sending reply msg and
the handler was feeding post msg.
Looks fine now (tested with 100K POST data)
http://webperformanceinc.com/library/ServletReport/index.html
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Hi,
Interesting. Thank you for sharing.
Yoav Shapira
Millennium ChemInformatics
-Original Message-
From: Andrew C. Oliver [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, November 20, 2002 2:11 PM
To: [EMAIL PROTECTED]
Subject: new Performance benchmarks/comparisons on tomcat
on 2002/11/20 7:34 AM, John Trollinger [EMAIL PROTECTED] wrote:
We have 2, one is webdav and the other is our actual application. We
use a lot of custom tags and a lot of both types of includes (when I say
a lot we have jsp pages that include over 500 other jsp pages, and no,
this is not my
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14718.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
... about the IIS connector? Every post that I have made with respect to it
has been more or less ignored over the last couple of weeks. First when I
reported the problem and asked for advice on how I might implement a
solution. Then when I implemented a solution without advice and posted the
Steven, I normally do care of the IIS connector, sorry for not being
quick but as everyone i'm overloaded, your change althought optional is
big and until yesterday i did not reviewed it, and i'll plan to apply it
asap.. If someone can take it and apply, ok from me, but as everybody
here apply
Using 4.0.6 I'm getting a lot of exceptions (for every jar in
/WEB-INF/lib/) on startup like this one:
ContextConfig[]: tldConfigJar(/WEB-INF/lib/xerces.jar):
java.io.IOException: No such file or directory
Which is problematic because if an exception happens in tldConfigJar(),
Ignacio,
Thanks for the reply. I'm sorry that my e-mail sounded a bit edgy, but I
felt it had to be that way to get some info back. I know that people can
get busy at times (I did not know the state of your personal work load at
the moment) so take your time. I was mostly concerned about not
Figured it out myself! :-)
I printed out the IOException stack trace, saw that the error happened
when a temp file was being created. Turns out my CATALINA_TMPDIR was
set to a non-existing directory. I created it and no more IOExceptions.
Now I just hope my classloader issue is fixed...
Nick
I think that the following error message is incorrect:
- Scripting elements ( %@, %!, %=, % ) are disallowed here.
Since directives (%@) are not scripting elements.
I've attached a patch to correct the messages.properties.
Index: messages.properties
Steven,
JK2 is aproaching Stable state at very good pace, and the help there is
much more needed than in jk1, testing and reporting bugs, and
implemeting features like yours, is preferred.. in any case yours is ok
for jk1.. thought..
in to jk2. Do you think it's better to do this sooner or
Thanks for the reply, Costin. There are some more questions below.
Costin Manolache wrote:
Ajp13 protocol ( marshalling, etc ) is used for in-process communication
and out of process communication. By marshalling the data we avoid some
expensive and complex JNI operations, and benefit of all
I've been a bad boy by not taking care of this. This is just the kind
of encouragement I need to movitate my guilty butt. I'll work on it
tonight and with any luck commit it tomorrow.
Which branch do I commit this to? And if the answer is the 4.x branch,
who/how does it get forward-ported?
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14722.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14724.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14724.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14725.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12145.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14724.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Is anyone opposed to looking at bug 14724? It replaces a similiar
enhancment [bug 12145](with patch) logged a few months ago.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14724
The patch also enables writing out Cookies, incoming headers, Session
attributes, and HttpServletRequest
Did anyone notice that Tomcat 4.1.12 does not respect the port attribute for
the AJP13 connector
I have a connector defined like this,
Connector className=org.apache.coyote.tomcat4.CoyoteConnector
port=8010 minProcessors=5 maxProcessors=75
enableLookups=true
I believe it's a bug. You can get around it by defining the port in
conf/jk2.properties ...
http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jk2/jk2/configtcex.html
On Wednesday, November 20, 2002, at 08:26 PM, Filip Hanik wrote:
Did anyone notice that Tomcat 4.1.12 does not respect the port
mturk 2002/11/20 23:46:41
Modified:jk/native2/common jk_workerEnv.c jk_worker_lb.c
Log:
Fix the client aborted connections.
Instead of setting the entire worker to a error state, check the service
return value, and if it is set to the JK_HANDLER_ERROR, close the
connection
65 matches
Mail list logo
