mturk 2004/12/16 00:42:19
Modified:jk/native/common jk_worker.c jk_worker_list.h
Log:
Move the static variable from header to source file.
Revision ChangesPath
1.24 +4 -1 jakarta-tomcat-connectors/jk/native/common/jk_worker.c
Index: jk_worker.c
mturk 2004/12/16 01:25:15
Modified:jk/native/common jk_version.h
Log:
Increment the version to 1.2.8 and add release candidate flag.
Revision ChangesPath
1.29 +11 -4 jakarta-tomcat-connectors/jk/native/common/jk_version.h
Index: jk_version.h
mturk 2004/12/16 01:56:31
Modified:jk/native/common jk_ajp_common.c
Log:
No need to reset the endpoint while closing cause it will be unusable.
Revision ChangesPath
1.70 +2 -3
jakarta-tomcat-connectors/jk/native/common/jk_ajp_common.c
Index:
mturk 2004/12/16 02:56:03
Modified:jk/native/common jk_lb_worker.c
Log:
Make load balancer thread safe, since we can have a cross request
corruption of data, so that we don't use the worker that some other
thread marked as in error state.
Revision ChangesPath
1.36
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=32729.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
derrick, I have changed the subject for this email as you hijacked my one which
i am still researching.
-Original Message-
From: Derrick Koes [mailto:[EMAIL PROTECTED]
Sent: 15 December 2004 23:19
To: Tomcat Developers List
Cc: Tim Lucia
Subject: RE: JK throws
Hi Guys,
Well I have trace logging on but there do not appear to be errors in the logs.
You can clearly see from the timestamps on the logging below that the errors
are linked to each other. As soon as I request a JSP that does not exist, e.g I
request
http://testserver/nosuchjsp.jsp
I get
Hi all,
i'b been used for a long time with Tomcat 4, during development, to use
install task to install a webapp directly from the ant build directory
and remove task to clear that webapp from tomcat.
Now i've jumped to 5.5.4 and i saw that install/remove tasks are still
mentioned in the doc
Gabriele Garuglieri wrote:
Hi all,
i'b been used for a long time with Tomcat 4, during development, to use
install task to install a webapp directly from the ant build directory
and remove task to clear that webapp from tomcat.
Now i've jumped to 5.5.4 and i saw that install/remove tasks are
mturk 2004/12/16 07:07:55
Modified:jk/native/common jk_lb_worker.c
Log:
Reorganize logging for getting candidate worker. It is not an error
if the domain is for the worker is not set.
Revision ChangesPath
1.37 +5 -8
- Original Message -
From: Allistair Crossley [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Thursday, December 16, 2004 6:22 AM
Subject: RE: JK throws java.lang.NumberFormatException when JSP is not
found. (trace logging)
Hi Guys,
Well I have trace logging on but
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=32729.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
Hi,
OK, just generated it again, and taken more trace ... I can see this ERROR ...
[Thu Dec 16 16:14:22 2004] [2196:1556] [error]
ajp_connection_tcp_get_message::jk_ajp_common.c (857): ERROR: can't receive the
response message from tomcat, network problems or tomcat is down
(127.0.0.1:8009),
The documentation for setting up a logger for JK2 is below. I've tried using
logger.file and logger.win32 for my IIS configuration, but no luck. Can
someone please send the right configuration steps to configure JK2 logging with
IIS? I'm trying to locate a bug in JK (not present in JK2) by
remm2004/12/16 07:49:36
Modified:webapps/manager/WEB-INF/classes/org/apache/catalina/manager
ManagerServlet.java
Log:
- Remove the remove method, and use the undeploy methos instead.
Revision ChangesPath
1.25 +2 -56
From the JK debug log, I suspect the jsessionid part of the URL is being
dropped somewhere between these two log lines. Or, I suppose it could be added
to the header. In any event it is not longer part of the URL. If anyone has
any further insight that would be most helpful.
[Thu Dec 16
remm2004/12/16 07:39:28
Modified:webapps/manager/WEB-INF/classes/org/apache/catalina/manager
ManagerServlet.java
Log:
- 32729: stop is optional and may fail, so it needs to be in a separate
try/catch.
Revision ChangesPath
1.24 +6 -2
Derrick Koes wrote:
From the JK debug log, I suspect the jsessionid part of the URL is being dropped somewhere between these two log lines. Or, I suppose it could be added to the header. In any event it is not longer part of the URL. If anyone has any further insight that would be most
How come it works as expected/desired with JK2?
In other words, request.isRequestedSessionIdFromURL() is true for JK2, but
false for JK.
Thanks,
Derrick
-Original Message-
From: Mladen Turk [mailto:[EMAIL PROTECTED]
Sent: Thursday, December 16, 2004 1:46 PM
To: Tomcat Developers
I *think*, from quick source code scanning, that JK does not call SetHeader
with the correct/complete URL, whereas JK2 does.
Can anyone verify this?
Thanks,
Derrick
-Original Message-
From: Mladen Turk [mailto:[EMAIL PROTECTED]
Sent: Thursday, December 16, 2004 1:46 PM
To: Tomcat
At 05:51 AM 12/14/2004, Allistair Crossley wrote:
Copying in DEV on this JK issue/solution on Mladen's request. The release
build worked fine.
Seems that the problem is caused by the fact that beta3 binaries
are compiled as 'debug' so tolower function is issuing an assertion.
I'll make a
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=32741.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
Jess Holle wrote:
And finally, here are the patches against 5.5.6 (same as HEAD at this
moment in this case).
Ok, but I still dislike the patch ;)
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
Remy Maucherat wrote:
Jess Holle wrote:
And finally, here are the patches against 5.5.6 (same as HEAD at this
moment in this case).
Ok, but I still dislike the patch ;)
I'd appreciate comments as to what's wrong with the patch :-)
I am clearly new to this area of Tomcat, but there were clear
Jess Holle wrote:
It is not useful without the rest of the changes as without the rest of
the changes there are intolerable race conditions.
Right. I suppose that's the end of the discussion then, it would be a
waste of time to continue. -1 for your patch.
If you really feel insecure, then you
Remy Maucherat wrote:
Jess Holle wrote:
It is not useful without the rest of the changes as without the rest
of the changes there are intolerable race conditions.
Right. I suppose that's the end of the discussion then, it would be a
waste of time to continue. -1 for your patch.
If you really
Remy Maucherat wrote:
Jess Holle wrote:
Where have I faked robustness? I will not claim I actually achieve
it, but I certainly tried, fixed real race condition cases, and don't
know of ones I missed.
The only race condition that I can possibly imagine is on accessCount,
which I think is
On further analysis it seems that StandardSession is only constructed by
ManagerBase and indirectly from SimpleTcpReplicationManager via the
ReplicatedSession subclass.
Given that SimpleTcpReplicationManager is mutually exclusive of
PersistentManager, it would appear I should move my
billbarker2004/12/16 19:02:41
Modified:jk/java/org/apache/jk/common HandlerRequest.java
Log:
Fix weird NumberFormatException.
Apache never sends Content-Length as a String, which is probably why this
one has been here so long.
Reported By: Allistair Crossley [EMAIL
billbarker2004/12/16 19:14:56
Modified:jk/native/apache-1.3 mod_jk.c
jk/native/apache-2.0 mod_jk.c
Log:
Now that the SC lookup is case-insensitive, don't waste cycles converting the
header names to lower case
Revision ChangesPath
1.60 +2 -6
Attached are a new PersistentManagerBase patch and a new
PersistentSession class. Together these eliminate the need for the
changes to ManagerBase and StandardSession (but not to Request, but this
change is an innocuous reordering of a couple of lines of code).
I've not had a chance to test
mturk 2004/12/16 00:38:05
Modified:jk/native/common jk_ajp_common.c
Log:
Backport method parsing from ajp project. It's more efficient then
previous.
Revision ChangesPath
1.68 +173 -95
jakarta-tomcat-connectors/jk/native/common/jk_ajp_common.c
Index:
This is an automated message that will hopefully answer any questions you might
have:
HOW TO UNSUBSCRIBE:
Visit www.insanepictures.com/unsubscribe.shtml and enter your email address
into the unsubscribe box.
HOW TO SUBSCRIBE:
Visit www.insanepictures.com and enter your email address into the
mturk 2004/12/16 01:49:42
Modified:jk/native/common jk_ajp_common.c jk_ajp_common.h
Log:
Use zero for default cache timeout value, and properly set the last
access time value.
Revision ChangesPath
1.69 +9 -9
Hi, I know that I should not cross-post but I did not get any reply from
the users list and actually this may be a better place for this type of
post...
I have written a j2me application that connects to any running tomcat
server and provided that a proper manager username and password is
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=32729.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
And finally, here are the patches against 5.5.6 (same as HEAD at this
moment in this case).
--
Jess Holle
Jess Holle wrote:
Here's the patches against 5.5.4
Jess Holle wrote:
For those who tried finding through the patches only to find that
they did not properly map against CVS (as I just
- Original Message -
From: Allistair Crossley [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Thursday, December 16, 2004 8:18 AM
Subject: RE: JK throws java.lang.NumberFormatException when JSP is not
found. (trace logging)
Hi,
OK, just generated it again, and
Jess Holle wrote:
Remy Maucherat wrote:
Jess Holle wrote:
And finally, here are the patches against 5.5.6 (same as HEAD at
this moment in this case).
Ok, but I still dislike the patch ;)
I'd appreciate comments as to what's wrong with the patch :-)
Sorry I missed your previous comments somehow.
Jess Holle wrote:
Remy Maucherat wrote:
I'd appreciate comments as to what's wrong with the patch :-)
I am clearly new to this area of Tomcat, but there were clear issues in
this area of the code that I cannot ignore if I am to depend on
PersistentManager.
* Extremely inefficient behavior
Remy Maucherat wrote:
Jess Holle wrote:
Remy Maucherat wrote:
I'd appreciate comments as to what's wrong with the patch :-)
I am clearly new to this area of Tomcat, but there were clear issues
in this area of the code that I cannot ignore if I am to depend on
PersistentManager.
* Extremely
Jess Holle wrote:
Where have I faked robustness? I will not claim I actually achieve
it, but I certainly tried, fixed real race condition cases, and don't
know of ones I missed.
The only race condition that I can possibly imagine is on accessCount,
which I think is something quite unimportant
42 matches
Mail list logo
