cvs commit: jakarta-tomcat-connectors/jk/native/common jk_worker.c jk_worker_list.h
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
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_worker.c,v
retrieving revision 1.23
retrieving revision 1.24
diff -u -r1.23 -r1.24
--- jk_worker.c 11 Nov 2004 19:11:56 - 1.23
+++ jk_worker.c 16 Dec 2004 08:42:19 - 1.24
@@ -35,6 +35,9 @@
unsigned num_of_workers,
jk_worker_env_t *we, jk_logger_t *l);
+/* Global worker list */
+static jk_map_t *worker_map;
+
int wc_open(jk_map_t *init_data, jk_worker_env_t *we, jk_logger_t *l)
{
char **worker_list = NULL;
1.11 +1 -3
jakarta-tomcat-connectors/jk/native/common/jk_worker_list.h
Index: jk_worker_list.h
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_worker_list.h,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- jk_worker_list.h 8 Oct 2004 07:50:40 - 1.10
+++ jk_worker_list.h 16 Dec 2004 08:42:19 - 1.11
@@ -54,8 +54,6 @@
};
typedef struct worker_factory_record worker_factory_record_t;
-static jk_map_t *worker_map;
-
static worker_factory_record_t worker_factories[] = {
/*
* AJPv12 worker, this is the stable worker.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native/common jk_version.h
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 === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_version.h,v retrieving revision 1.28 retrieving revision 1.29 diff -u -r1.28 -r1.29 --- jk_version.h 13 Dec 2004 17:03:50 - 1.28 +++ jk_version.h 16 Dec 2004 09:25:15 - 1.29 @@ -25,14 +25,17 @@ /** START OF AREA TO MODIFY BEFORE RELEASING */ #define JK_VERMAJOR 1 #define JK_VERMINOR 2 -#define JK_VERFIX 7 -#define JK_VERSTRING1.2.7 +#define JK_VERFIX 8 +#define JK_VERSTRING1.2.8 /* Beta number */ -#define JK_VERBETA 4 -#define JK_BETASTRING 4 +#define JK_VERBETA 0 +#define JK_BETASTRING 0 /* set JK_VERISRELEASE to 1 when release (do not forget to commit!) */ #define JK_VERISRELEASE 0 +#define JK_VERRC0 +#define JK_RCSTRING 0 + /** END OF AREA TO MODIFY BEFORE RELEASING */ #if !defined(PACKAGE) @@ -54,6 +57,10 @@ #define JK_VERBETA 255 #else #define JK_EXPOSED_VERSION JK_RELEASE_STR -beta- JK_BETASTRING +#endif + +#if (JK_VERRC != 0) +#define JK_EXPOSED_VERSION JK_RELEASE_STR -rc- JK_RCSTRING #endif #define JK_MAKEVERSION(major, minor, fix, beta) (((major) 24) + ((minor) 16) + ((fix) 8) + (beta)) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native/common jk_ajp_common.c
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: jk_ajp_common.c
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_ajp_common.c,v
retrieving revision 1.69
retrieving revision 1.70
diff -u -r1.69 -r1.70
--- jk_ajp_common.c 16 Dec 2004 09:49:41 - 1.69
+++ jk_ajp_common.c 16 Dec 2004 09:56:31 - 1.70
@@ -692,7 +692,6 @@
{
JK_TRACE_ENTER(l);
-ajp_reset_endpoint(ae);
jk_close_pool((ae-pool));
if (ae-sd 0) {
@@ -702,8 +701,8 @@
ae-sd = -1;/* just to avoid twice close */
}
-JK_TRACE_EXIT(l);
free(ae);
+JK_TRACE_EXIT(l);
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native/common jk_lb_worker.c
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 +25 -3 jakarta-tomcat-connectors/jk/native/common/jk_lb_worker.c
Index: jk_lb_worker.c
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_lb_worker.c,v
retrieving revision 1.35
retrieving revision 1.36
diff -u -r1.35 -r1.36
--- jk_lb_worker.c7 Dec 2004 14:29:14 - 1.35
+++ jk_lb_worker.c16 Dec 2004 10:56:03 - 1.36
@@ -28,6 +28,7 @@
#include jk_util.h
#include jk_worker.h
#include jk_lb_worker.h
+#include jk_mt.h
/*
* The load balancing code in this
@@ -86,6 +87,7 @@
int local_worker_only;
int sticky_session;
int recover_wait_time;
+JK_CRIT_SEC cs;
};
typedef struct lb_worker lb_worker_t;
@@ -262,12 +264,20 @@
int total_factor = 0;
const char *search_type = search_types[search_id];
int i;
-
+
*domain_id = -1;
+JK_ENTER_CS((p-cs), i);
+if (!i) {
+jk_log(l, JK_LOG_ERROR,
+ could not lock load balancer = %s\n,
+ p-name);
+return NULL;
+}
jk_log(l, JK_LOG_DEBUG,
searching for %s worker (%s)\n,
search_type, search_string);
+
for (i = start; i stop; i++) {
jk_log(l, JK_LOG_DEBUG,
testing worker %s (%d) for match with %s (%s)\n,
@@ -328,11 +338,13 @@
jk_log(l, JK_LOG_DEBUG,
found worker %s with new load %d in search with %s (%s)\n,
rc-name, rc-lb_value, search_type, search_string);
+JK_LEAVE_CS((p-cs), i);
return rc;
}
jk_log(l, JK_LOG_DEBUG,
found no %s (%s) worker\n,
search_type, search_string);
+ JK_LEAVE_CS((p-cs), i);
return rc;
}
@@ -669,6 +681,8 @@
int i;
lb_worker_t *p = (lb_worker_t *)pThis-worker_private;
+JK_TRACE_ENTER(log);
+
pThis-retries = jk_get_worker_retries(props, p-name,
JK_RETRIES);
@@ -679,6 +693,13 @@
if (p-recover_wait_time WAIT_BEFORE_RECOVER)
p-recover_wait_time = WAIT_BEFORE_RECOVER;
+JK_INIT_CS((p-cs), i);
+if (i == JK_FALSE) {
+JK_TRACE_EXIT(log);
+return JK_FALSE;
+}
+
+JK_TRACE_EXIT(log);
return JK_TRUE;
}
@@ -712,10 +733,11 @@
JK_TRACE_ENTER(l);
if (pThis *pThis (*pThis)-worker_private) {
+unsigned int i;
lb_worker_t *private_data = (*pThis)-worker_private;
close_workers(private_data, private_data-num_of_workers, l);
-
+JK_DELETE_CS((private_data-cs), i);
jk_close_pool(private_data-p);
free(private_data);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 32729] New: - Can deploy but not undeploy improperly configured webapps
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. http://issues.apache.org/bugzilla/show_bug.cgi?id=32729 Summary: Can deploy but not undeploy improperly configured webapps Product: Tomcat 5 Version: 5.5.4 Platform: Macintosh OS/Version: Mac OS X 10.3 Status: NEW Severity: normal Priority: P2 Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] To reproduce: introduce a typo in the web-app/servlet-mapping/servlet-name element of a web.xml of a working app, so that a url-pattern is mapped to an undefined servlet. Run ant install. Although Ant reports a successful build, there will be a number of exceptions reported in catalina.out (including IllegalArgumentException: Servlet mapping specifies an unknown servlet name ...), and the webapp won't work. Attempts to undeploy the broken web-app using ant remove or the HTML manager then fail, with complaints that the app hasn't been started (LifecycleException). The commands ant install and ant reload also fail, reporting that the Application already exists at path ... and [app] has not been started, respectively. It seems the only way out is to delete the webapp from the filesystem by hand. I expect it should not be possible to partially deploy a webapp, even if it is misconfigured. Either the deployTask should delete from webapps an app that couldn't be started, or the UndeployTask should allow such an app to be removed. I am using Ant 1.6.2. My build.xml and web.xml closely resemble the examples given in the documentation. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JK 1.2.7 beta 3 + URL rewriting scheme issue
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 java.lang.NumberFormatException when JSP is not found. I've been testing JK 1.2.7 beta 3 +. For some reason, putting the jsessionid (URL rewriting) on the URL makes JK not deliver it to Tomcat (get a new session from tomcat for every request). Running the same web app with JK2 does not exhibit the problem. HttpServletRequest.isRequestedSessionIdFromURL() returns true for the JK2 configuration, but false for the JK configuration. I'm assuming it must be JK that decides to remove it from the URL (different URL rewriting scheme?), but I suppose it *could* be a bug in Tomcat HttpServletRequest implementation. Does anyone have any suggestions? Below is a sample URL. http://dkoesxp/ilt/rd/b73d019ee9a5d0e5d43c2c64831b9f05/ilt/Ins tructorLedTraining.do;jsessionid=F63D242A6554BC9C5A2CF8D00D613 F3F.dkoesxp:8009 The url rewriting part: ;jsessionid=F63D242A6554BC9C5A2CF8D00D613F3F.dkoesxp:8009 Thanks, Derrick -Original Message- From: Allistair Crossley [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 15, 2004 5:07 PM To: Tomcat Developers List; Tomcat Developers List Subject: RE: JK throws java.lang.NumberFormatException when JSP is not found. Hi, Will add trace logging first thing tomorrow morning and let you know. I really don't want to get a reputation for being imaginative you know ;) but this looked pretty much the direct cause to me, but I being to doubt myself ;) The stack trace certainly is not my imagination, I did afterall paste it into the email ;) Will come back to you tomorrow, Cheers, Allistair. -Original Message- From: Mladen Turk [mailto:[EMAIL PROTECTED] Sent: Wed 15/12/2004 19:43 To: Tomcat Developers List Cc: Subject: Re: JK throws java.lang.NumberFormatException when JSP is not found. Allistair Crossley wrote: Hi Mladen, Just a follow-up on this decoding issue in JK. I have just this moment accidentally come upon a scenario where I can generate this error. You can generate it by requesting a JSP that does not exist, so long as you have a /*.jsp mapping in urimapping.properties. Did on IIS/WINXP/1.2.7-beta-3 No mater what files I'm asking existing or not I can not reproduce the error. Tested on 5.5.6 and 5.0.30. Really have no clue how to reproduce that. Please try turning log_level to trace, clear the logs, restart IIS, and post the jk log file. Otherwise we are stuck :(. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] FONT SIZE=1 FACE=VERDANA,ARIAL COLOR=BLUE --- QAS Ltd. Developers of QuickAddress Software a href=http://www.qas.com;www.qas.com/a Registered in England: No 2582055 Registered in Australia: No 082 851 474 --- /FONT
RE: JK throws java.lang.NumberFormatException when JSP is not found. (trace logging)
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 the NumberFormatException in Tomcat stdout and I correctly get the standard Tomcat 404 error page. Does this trace logging help anymore? Cheers, Allistair. STDOUT == Dec 16, 2004 2:19:08 PM org.apache.jk.common.HandlerRequest invoke SEVERE: Error decoding request java.lang.NumberFormatException at org.apache.tomcat.util.buf.Ascii.parseInt(Ascii.java:145) at org.apache.tomcat.util.buf.ByteChunk.getInt(ByteChunk.java:491) at org.apache.tomcat.util.buf.MessageBytes.getInt(MessageBytes.java:645) at org.apache.jk.common.HandlerRequest.decodeHeaders(HandlerRequest.java:682) at org.apache.jk.common.HandlerRequest.decodeRequest(HandlerRequest.java:504) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:361) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:745) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:675) at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:868) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:595) Dec 16, 2004 2:19:08 PM org.apache.jk.common.ChannelSocket processConnection WARNING: processCallbacks status 2 JK === [Thu Dec 16 14:19:08 2004] [2196:2232] [trace] ajp_get_reply::jk_ajp_common.c (1329): enter [Thu Dec 16 14:19:08 2004] [2196:2232] [trace] ajp_connection_tcp_get_message::jk_ajp_common.c (846): enter [Thu Dec 16 14:19:08 2004] [2196:2232] [debug] ajp_connection_tcp_get_message::jk_ajp_common.c (930): received from ajp13 pos=0 len=86 max=8192 [Thu Dec 16 14:19:08 2004] [2196:2232] [debug] ajp_connection_tcp_get_message::jk_ajp_common.c (930): 04 01 94 00 0E 2F 6E 6F 73 75 63 68 6A 73 70 2E - ./nosuchjsp. [Thu Dec 16 14:19:08 2004] [2196:2232] [debug] ajp_connection_tcp_get_message::jk_ajp_common.c (930): 00106A 73 70 00 00 02 00 0C 43 6F 6E 74 65 6E 74 2D - jsp.Content- [Thu Dec 16 14:19:08 2004] [2196:2232] [debug] ajp_connection_tcp_get_message::jk_ajp_common.c (930): 002054 79 70 65 00 00 17 74 65 78 74 2F 68 74 6D 6C - Type...text/html [Thu Dec 16 14:19:08 2004] [2196:2232] [debug] ajp_connection_tcp_get_message::jk_ajp_common.c (930): 00303B 63 68 61 72 73 65 74 3D 75 74 66 2D 38 00 00 - ;charset=utf-8.. [Thu Dec 16 14:19:08 2004] [2196:2232] [debug] ajp_connection_tcp_get_message::jk_ajp_common.c (930): 00400E 43 6F 6E 74 65 6E 74 2D 4C 65 6E 67 74 68 00 - .Content-Length. [Thu Dec 16 14:19:08 2004] [2196:2232] [debug] ajp_connection_tcp_get_message::jk_ajp_common.c (930): 005000 03 39 39 32 00 6D 69 6C 79 3A 54 61 68 6F 6D - ..992.mily:Tahom [Thu Dec 16 14:19:08 2004] [2196:2232] [trace] ajp_connection_tcp_get_message::jk_ajp_common.c (935): exit [Thu Dec 16 14:19:08 2004] [2196:2232] [trace] ajp_process_callback::jk_ajp_common.c (1220): enter [Thu Dec 16 14:19:08 2004] [2196:2232] [trace] ajp_unmarshal_response::jk_ajp_common.c (522): enter [Thu Dec 16 14:19:08 2004] [2196:2232] [debug] ajp_unmarshal_response::jk_ajp_common.c (538): status = 404 [Thu Dec 16 14:19:08 2004] [2196:2232] [debug] ajp_unmarshal_response::jk_ajp_common.c (544): Number of headers is = 2 [Thu Dec 16 14:19:08 2004] [2196:2232] [debug] ajp_unmarshal_response::jk_ajp_common.c (599): Header[0] [Content-Type] = [text/html;charset=utf-8] [Thu Dec 16 14:19:08 2004] [2196:2232] [debug] ajp_unmarshal_response::jk_ajp_common.c (599): Header[1] [Content-Length] = [992] [Thu Dec 16 14:19:08 2004] [2196:2232] [trace] ajp_unmarshal_response::jk_ajp_common.c (606): exit [Thu Dec 16 14:19:08 2004] [2196:2232] [trace] start_response::jk_isapi_plugin.c (385): enter [Thu Dec 16 14:19:08 2004] [2196:2232] [trace] start_response::jk_isapi_plugin.c (451): exit [Thu Dec 16 14:19:08 2004] [2196:2232] [trace] ajp_connection_tcp_get_message::jk_ajp_common.c (846): enter [Thu Dec 16 14:19:08 2004] [2196:2232] [debug] ajp_connection_tcp_get_message::jk_ajp_common.c (930): received from ajp13 pos=0 len=996 max=8192 [Thu Dec 16 14:19:08 2004] [2196:2232] [debug] ajp_connection_tcp_get_message::jk_ajp_common.c (930): 03 03 E0 3C 68 74 6D 6C 3E 3C 68 65 61 64 3E 3C - ...htmlhead [Thu Dec 16 14:19:08 2004] [2196:2232] [debug] ajp_connection_tcp_get_message::jk_ajp_common.c (930): 001074 69 74 6C 65 3E 41 70 61 63 68 65 20 54 6F 6D - titleApache.Tom [Thu Dec 16 14:19:08 2004] [2196:2232] [debug] ajp_connection_tcp_get_message::jk_ajp_common.c (930): 002063 61 74 2F 35 2E 35 2E 35 20 2D 20 45 72 72 6F - cat/5.5.5.-.Erro [Thu Dec 16 14:19:08 2004] [2196:2232] [debug]
Tomcat 5.5 install/remove manager tasks
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 and they are still present in the catalina-ant.jar, but using them make weird things happen. Are they really still supported? If not please remove them from the doc and from the jar. Thanks, Gabriele Here follows some description of the problems, just in case you are interested in them. If i install then remove, sometimes when i install again i get: 2004-12-16 14:55:58,301 [http-8080-Processor24] ERROR org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/manager] - Manager: ManagerServlet.install[/ConfigTest] javax.management.RuntimeOperationsException: Exception invoking method check at org.apache.commons.modeler.BaseModelMBean.invoke(BaseModelMBean.java:511) at com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke(DynamicMetaDataImpl.java:213) at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(MetaDataImpl.java:220) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:815) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:784) at org.apache.catalina.manager.ManagerServlet.check(ManagerServlet.java:1411) at org.apache.catalina.manager.ManagerServlet.deploy(ManagerServlet.java:813) at org.apache.catalina.manager.ManagerServlet.doGet(ManagerServlet.java:351) at javax.servlet.http.HttpServlet.service(HttpServlet.java:689) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:482) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:825) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:731) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:526) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:595) Caused by: java.lang.NullPointerException at org.apache.catalina.core.ContainerBase.removeChild(ContainerBase.java:875) at org.apache.catalina.startup.HostConfig.checkResources(HostConfig.java:952) at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1154) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.commons.modeler.BaseModelMBean.invoke(BaseModelMBean.java:503) ... 24 more After this the log keeps rolling, filling with a bunch of messages like this: 2004-12-16 14:56:02,645 [ContainerBackgroundProcessor[StandardEngine[Catalina]]] ERROR org.apache.catalina.core.ContainerBase - Exception invoking periodic operation: java.lang.NullPointerException at org.apache.catalina.core.ContainerBase.removeChild(ContainerBase.java:875) at org.apache.catalina.startup.HostConfig.checkResources(HostConfig.java:952) at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1139) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:292) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1293) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1553) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1562) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1542) at java.lang.Thread.run(Thread.java:595) and Tomcat become unresponsive and mus be killed. I really mean killed because if i try to use stop i
Re: Tomcat 5.5 install/remove manager tasks
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 still mentioned in the doc and they are still present in the catalina-ant.jar, but using them make weird things happen. Are they really still supported? If not please remove them from the doc and from the jar. No they are deprecated. They are also deprecated in the whole 5.0.x branch. The documentation that I can see (http://jakarta.apache.org/tomcat/tomcat-5.5-doc/manager-howto.html) as well as the deployer tool do not mention install or remove. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native/common jk_lb_worker.c
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 jakarta-tomcat-connectors/jk/native/common/jk_lb_worker.c
Index: jk_lb_worker.c
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_lb_worker.c,v
retrieving revision 1.36
retrieving revision 1.37
diff -u -r1.36 -r1.37
--- jk_lb_worker.c16 Dec 2004 10:56:03 - 1.36
+++ jk_lb_worker.c16 Dec 2004 15:07:55 - 1.37
@@ -243,9 +243,6 @@
case 5:
return JK_TRUE;
}
-jk_log(l, JK_LOG_ERROR,
-wrong search id %d\n,
-search_id);
return JK_FALSE;
}
@@ -279,10 +276,10 @@
search_type, search_string);
for (i = start; i stop; i++) {
- jk_log(l, JK_LOG_DEBUG,
- testing worker %s (%d) for match with %s (%s)\n,
- p-lb_workers[i].name, i, search_type, search_string);
if (is_worker_candidate((p-lb_workers[i]), search_id,
search_string, l)) {
+ jk_log(l, JK_LOG_DEBUG,
+ found candidate worker %s (%d) for match with %s (%s)\n,
+ p-lb_workers[i].name, i, search_type, search_string);
if (search_id == 1) {
*domain_id = i;
}
@@ -344,7 +341,7 @@
jk_log(l, JK_LOG_DEBUG,
found no %s (%s) worker\n,
search_type, search_string);
- JK_LEAVE_CS((p-cs), i);
+JK_LEAVE_CS((p-cs), i);
return rc;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: JK throws java.lang.NumberFormatException when JSP is not found. (trace logging)
- 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 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 the NumberFormatException in Tomcat stdout and I correctly get the standard Tomcat 404 error page. Does this trace logging help anymore? After the 'processCallbacks status 2', Tomcat will drop the connection to IIS, and certainly not continue with the request. The Tomcat exception should look like an error in the IIS logs. The relevant part of the Jk log is probably the part above this. Cheers, Allistair. This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 32729] - Can deploy but not undeploy improperly configured webapps
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. http://issues.apache.org/bugzilla/show_bug.cgi?id=32729 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-12-16 17:05 --- undeploy had a defect in this case, so I fixed it. remove will now simply call undeploy. install already calls deploy. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JK throws java.lang.NumberFormatException when JSP is not found. (trace logging)
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), err=-1 Tomcat is *not* down though ;) Full [Thu Dec 16 16:14:22 2004] [2196:1556] [debug] HttpFilterProc::jk_isapi_plugin.c (657): Filter started [Thu Dec 16 16:14:22 2004] [2196:1556] [debug] HttpFilterProc::jk_isapi_plugin.c (723): Virtual Host redirection of /intratestgbr/nosuchjsp.jsp [Thu Dec 16 16:14:22 2004] [2196:1556] [trace] map_uri_to_worker::jk_uri_worker_map.c (664): enter [Thu Dec 16 16:14:22 2004] [2196:1556] [debug] map_uri_to_worker::jk_uri_worker_map.c (682): Attempting to map URI '/intratestgbr/nosuchjsp.jsp' from 2 maps [Thu Dec 16 16:14:22 2004] [2196:1556] [debug] map_uri_to_worker::jk_uri_worker_map.c (699): Attempting to map context URI '/*.jsp' [Thu Dec 16 16:14:22 2004] [2196:1556] [debug] map_uri_to_worker::jk_uri_worker_map.c (781): Found a suffix match ajp13 - *.jsp [Thu Dec 16 16:14:22 2004] [2196:1556] [debug] map_uri_to_worker::jk_uri_worker_map.c (699): Attempting to map context URI '/*.do' [Thu Dec 16 16:14:22 2004] [2196:1556] [trace] map_uri_to_worker::jk_uri_worker_map.c (794): exit [Thu Dec 16 16:14:22 2004] [2196:1556] [debug] HttpFilterProc::jk_isapi_plugin.c (739): [/nosuchjsp.jsp] is a servlet url - should redirect to ajp13 [Thu Dec 16 16:14:22 2004] [2196:1556] [debug] HttpFilterProc::jk_isapi_plugin.c (809): check if [/nosuchjsp.jsp] is points to the web-inf directory [Thu Dec 16 16:14:22 2004] [2196:1556] [trace] HttpExtensionProc::jk_isapi_plugin.c (848): enter [Thu Dec 16 16:14:22 2004] [2196:1556] [trace] wc_get_worker_for_name::jk_worker.c (79): enter [Thu Dec 16 16:14:22 2004] [2196:1556] [debug] wc_get_worker_for_name::jk_worker.c (88): found a worker ajp13 [Thu Dec 16 16:14:22 2004] [2196:1556] [trace] wc_get_worker_for_name::jk_worker.c (90): exit [Thu Dec 16 16:14:22 2004] [2196:1556] [debug] HttpExtensionProc::jk_isapi_plugin.c (885): got a worker for name ajp13 [Thu Dec 16 16:14:22 2004] [2196:1556] [trace] get_endpoint::jk_ajp13_worker.c (72): enter [Thu Dec 16 16:14:22 2004] [2196:1556] [trace] ajp_get_endpoint::jk_ajp_common.c (1890): enter [Thu Dec 16 16:14:22 2004] [2196:1556] [debug] ajp_get_endpoint::jk_ajp_common.c (1932): time elapsed since last request = 13 seconds [Thu Dec 16 16:14:22 2004] [2196:1556] [trace] ajp_get_endpoint::jk_ajp_common.c (1945): exit [Thu Dec 16 16:14:22 2004] [2196:1556] [trace] get_endpoint::jk_ajp13_worker.c (74): exit [Thu Dec 16 16:14:22 2004] [2196:1556] [trace] ajp_service::jk_ajp_common.c (1478): enter [Thu Dec 16 16:14:22 2004] [2196:1556] [trace] ajp_marshal_into_msgb::jk_ajp_common.c (314): enter [Thu Dec 16 16:14:22 2004] [2196:1556] [debug] ajp_marshal_into_msgb::jk_ajp_common.c (484): ajp marshaling done [Thu Dec 16 16:14:22 2004] [2196:1556] [trace] ajp_marshal_into_msgb::jk_ajp_common.c (485): exit [Thu Dec 16 16:14:22 2004] [2196:1556] [debug] ajp_service::jk_ajp_common.c (1512): processing with 3 retries [Thu Dec 16 16:14:22 2004] [2196:1556] [trace] ajp_send_request::jk_ajp_common.c (1058): enter [Thu Dec 16 16:14:22 2004] [2196:1556] [trace] ajp_connection_tcp_send_message::jk_ajp_common.c (806): enter [Thu Dec 16 16:14:22 2004] [2196:1556] [debug] ajp_connection_tcp_send_message::jk_ajp_common.c (809): sending to ajp13 pos=4 len=332 max=8192 [Thu Dec 16 16:14:22 2004] [2196:1556] [debug] ajp_connection_tcp_send_message::jk_ajp_common.c (809): 12 34 01 48 02 02 00 08 48 54 54 50 2F 31 2E 31 - .4.HHTTP/1.1 [Thu Dec 16 16:14:22 2004] [2196:1556] [debug] ajp_connection_tcp_send_message::jk_ajp_common.c (809): 001000 00 0E 2F 6E 6F 73 75 63 68 6A 73 70 2E 6A 73 - .../nosuchjsp.js [Thu Dec 16 16:14:22 2004] [2196:1556] [debug] ajp_connection_tcp_send_message::jk_ajp_common.c (809): 002070 00 00 0F 31 35 30 2E 31 35 30 2E 31 35 33 2E - p...150.150.153. [Thu Dec 16 16:14:22 2004] [2196:1556] [debug] ajp_connection_tcp_send_message::jk_ajp_common.c (809): 003031 32 32 00 00 0F 31 35 30 2E 31 35 30 2E 31 35 - 122...150.150.15 [Thu Dec 16 16:14:22 2004] [2196:1556] [debug] ajp_connection_tcp_send_message::jk_ajp_common.c (809): 004033 2E 31 32 32 00 00 0C 69 6E 74 72 61 74 65 73 - 3.122...intrates [Thu Dec 16 16:14:22 2004] [2196:1556] [debug] ajp_connection_tcp_send_message::jk_ajp_common.c (809): 005074 67 62 72 00 00 50 00 00 08 A0 01 00 03 2A 2F - tgbr..P...*/ [Thu Dec 16 16:14:22 2004] [2196:1556] [debug] ajp_connection_tcp_send_message::jk_ajp_common.c (809): 00602A 00 A0 04 00 05 65 6E 2D 67 62 00 A0 06 00 0A - *.en-gb. [Thu Dec 16 16:14:22 2004] [2196:1556] [debug] ajp_connection_tcp_send_message::jk_ajp_common.c (809): 00704B 65 65 70 2D 41 6C 69 76 65 00 A0 0B 00 0C 69 -
JK2 logging with IIS
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 comparing logs
as a first step. Maybe I have a registry setting missing.
Registry:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation\Jakarta Isapi
Redirector\2.0]
serverRoot=C:\\jk2-connector
extensionUri=/jakarta/isapi_redirector2.dll
workersFile=C:\\jk2-connector\\conf\\workers2.properties
logLevel=INFO
Thanks,
Derrick
loggers
Any connector based on jk2, at least has a default logger, that can be reached
using the logger alias, the logger used is the more appropiate for the
plataform/server combination, Apache2 under in any platform has logger.apache2
as default, IIS on his only platform uses logger.win32, and Any apache 1
install uses logger.file as default.., the config file lets you change that
defaults, you can end using logger.file in IIs i.e
The properties shared by all loggers are: Property name Default Description
level INFO Text of the log level. Strings supported: EMERG, ERROR, INFO, DEBUG
logger.file
Property name Default Description
file ${serverRoot}/logs/jk2.log Log file. XXX you may be able to change this at
runtime, to implement rolling.
logger.win32
logger used in the IIS server by default, it ends at native Application Event
Log.
logger.apache2
Logger used in Apache2 servers, it normally in ends in error.log
cvs commit: jakarta-tomcat-catalina/webapps/manager/WEB-INF/classes/org/apache/catalina/manager ManagerServlet.java
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
jakarta-tomcat-catalina/webapps/manager/WEB-INF/classes/org/apache/catalina/manager/ManagerServlet.java
Index: ManagerServlet.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/webapps/manager/WEB-INF/classes/org/apache/catalina/manager/ManagerServlet.java,v
retrieving revision 1.24
retrieving revision 1.25
diff -u -r1.24 -r1.25
--- ManagerServlet.java 16 Dec 2004 15:39:28 - 1.24
+++ ManagerServlet.java 16 Dec 2004 15:49:36 - 1.25
@@ -32,7 +32,6 @@
import javax.naming.InitialContext;
import javax.naming.NamingEnumeration;
import javax.naming.NamingException;
-import javax.naming.directory.DirContext;
import javax.servlet.ServletException;
import javax.servlet.ServletInputStream;
import javax.servlet.UnavailableException;
@@ -56,8 +55,6 @@
import org.apache.catalina.util.ServerInfo;
import org.apache.catalina.util.StringManager;
import org.apache.commons.modeler.Registry;
-import org.apache.naming.resources.ProxyDirContext;
-import org.apache.naming.resources.WARDirContext;
/**
@@ -355,7 +352,7 @@
reload(writer, path);
} else if (command.equals(/remove)) {
// Deprecated
-remove(writer, path);
+undeploy(writer, path);
} else if (command.equals(/resources)) {
resources(writer, type);
} else if (command.equals(/roles)) {
@@ -893,15 +890,6 @@
(managerServlet.noContext, displayPath));
return;
}
-DirContext resources = context.getResources();
-if (resources instanceof ProxyDirContext) {
-resources = ((ProxyDirContext) resources).getDirContext();
-}
-if (resources instanceof WARDirContext) {
-writer.println(sm.getString
- (managerServlet.noReload, displayPath));
-return;
-}
// It isn't possible for the manager to reload itself
if (context.getPath().equals(this.context.getPath())) {
writer.println(sm.getString(managerServlet.noSelf));
@@ -912,48 +900,6 @@
(sm.getString(managerServlet.reloaded, displayPath));
} catch (Throwable t) {
log(ManagerServlet.reload[ + displayPath + ], t);
-writer.println(sm.getString(managerServlet.exception,
-t.toString()));
-}
-
-}
-
-
-/**
- * Remove the web application at the specified context path.
- *
- * @param writer Writer to render to
- * @param path Context path of the application to be removed
- * @deprecated Replaced by undeploy
- */
-protected void remove(PrintWriter writer, String path) {
-
-if (debug = 1)
-log(remove: Removing web application at ' + path + ');
-
-if ((path == null) || (!path.startsWith(/) path.equals())) {
-writer.println(sm.getString(managerServlet.invalidPath, path));
-return;
-}
-String displayPath = path;
-if( path.equals(/) )
-path = ;
-
-try {
-Context context = (Context) host.findChild(path);
-if (context == null) {
-writer.println(sm.getString(managerServlet.noContext,
displayPath));
-return;
-}
-// It isn't possible for the manager to remove itself
-if (context.getPath().equals(this.context.getPath())) {
-writer.println(sm.getString(managerServlet.noSelf));
-return;
-}
-host.removeChild(context);
-writer.println(sm.getString(managerServlet.undeployed,
displayPath));
-} catch (Throwable t) {
-log(ManagerServlet.remove[ + displayPath + ], t);
writer.println(sm.getString(managerServlet.exception,
t.toString()));
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: JK 1.2.7 beta 3 + URL rewriting scheme issue
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 11:37:58 2004] [5228:5468] [debug] jk_isapi_plugin.c (753): Virtual Host redirection of /dkoesxp/ilt/rd/8a3c3f8d03bf435b1e1f0ec005b63a8b/ilt/spMySessions.do;jsessionid=24B27CD241D89FB2A217DF21497E84B3.dkoesxp8009 [Thu Dec 16 11:37:58 2004] [5228:5468] [debug] jk_uri_worker_map.c (682): Attempting to map URI '/dkoesxp/ilt/rd/8a3c3f8d03bf435b1e1f0ec005b63a8b/ilt/spMySessions.do' from 2 maps -Original Message- From: Allistair Crossley [mailto:[EMAIL PROTECTED] Sent: Thursday, December 16, 2004 6:39 AM To: Tomcat Developers List Subject: RE: JK 1.2.7 beta 3 + URL rewriting scheme issue 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 java.lang.NumberFormatException when JSP is not found. I've been testing JK 1.2.7 beta 3 +. For some reason, putting the jsessionid (URL rewriting) on the URL makes JK not deliver it to Tomcat (get a new session from tomcat for every request). Running the same web app with JK2 does not exhibit the problem. HttpServletRequest.isRequestedSessionIdFromURL() returns true for the JK2 configuration, but false for the JK configuration. I'm assuming it must be JK that decides to remove it from the URL (different URL rewriting scheme?), but I suppose it *could* be a bug in Tomcat HttpServletRequest implementation. Does anyone have any suggestions? Below is a sample URL. http://dkoesxp/ilt/rd/b73d019ee9a5d0e5d43c2c64831b9f05/ilt/Ins tructorLedTraining.do;jsessionid=F63D242A6554BC9C5A2CF8D00D613 F3F.dkoesxp:8009 The url rewriting part: ;jsessionid=F63D242A6554BC9C5A2CF8D00D613F3F.dkoesxp:8009 Thanks, Derrick -Original Message- From: Allistair Crossley [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 15, 2004 5:07 PM To: Tomcat Developers List; Tomcat Developers List Subject: RE: JK throws java.lang.NumberFormatException when JSP is not found. Hi, Will add trace logging first thing tomorrow morning and let you know. I really don't want to get a reputation for being imaginative you know ;) but this looked pretty much the direct cause to me, but I being to doubt myself ;) The stack trace certainly is not my imagination, I did afterall paste it into the email ;) Will come back to you tomorrow, Cheers, Allistair. -Original Message- From: Mladen Turk [mailto:[EMAIL PROTECTED] Sent: Wed 15/12/2004 19:43 To: Tomcat Developers List Cc: Subject: Re: JK throws java.lang.NumberFormatException when JSP is not found. Allistair Crossley wrote: Hi Mladen, Just a follow-up on this decoding issue in JK. I have just this moment accidentally come upon a scenario where I can generate this error. You can generate it by requesting a JSP that does not exist, so long as you have a /*.jsp mapping in urimapping.properties. Did on IIS/WINXP/1.2.7-beta-3 No mater what files I'm asking existing or not I can not reproduce the error. Tested on 5.5.6 and 5.0.30. Really have no clue how to reproduce that. Please try turning log_level to trace, clear the logs, restart IIS, and post the jk log file. Otherwise we are stuck :(. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] FONT SIZE=1 FACE=VERDANA,ARIAL COLOR=BLUE --- QAS Ltd. Developers of QuickAddress Software a href=http://www.qas.com;www.qas.com/a Registered in England: No 2582055 Registered in Australia: No 082 851 474 --- /FONT
cvs commit: jakarta-tomcat-catalina/webapps/manager/WEB-INF/classes/org/apache/catalina/manager ManagerServlet.java
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
jakarta-tomcat-catalina/webapps/manager/WEB-INF/classes/org/apache/catalina/manager/ManagerServlet.java
Index: ManagerServlet.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/webapps/manager/WEB-INF/classes/org/apache/catalina/manager/ManagerServlet.java,v
retrieving revision 1.23
retrieving revision 1.24
diff -u -r1.23 -r1.24
--- ManagerServlet.java 3 Dec 2004 15:35:25 - 1.23
+++ ManagerServlet.java 16 Dec 2004 15:39:28 - 1.24
@@ -1317,11 +1317,15 @@
}
}
-// Stop the context first to be nicer
if (!isServiced(path)) {
addServiced(path);
try {
+// Try to stop the context first to be nicer
((Lifecycle) context).stop();
+} catch (Throwable t) {
+// Ignore
+}
+try {
File war = new File(getAppBase(), getDocBase(path) +
.war);
File dir = new File(getAppBase(), getDocBase(path));
File xml = new File(configBase, getConfigFile(path) +
.xml);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: JK 1.2.7 beta 3 + URL rewriting scheme issue
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 helpful. [Thu Dec 16 11:37:58 2004] [5228:5468] [debug] jk_isapi_plugin.c (753): Virtual Host redirection of /dkoesxp/ilt/rd/8a3c3f8d03bf435b1e1f0ec005b63a8b/ilt/spMySessions.do;jsessionid=24B27CD241D89FB2A217DF21497E84B3.dkoesxp8009 [Thu Dec 16 11:37:58 2004] [5228:5468] [debug] jk_uri_worker_map.c (682): Attempting to map URI '/dkoesxp/ilt/rd/8a3c3f8d03bf435b1e1f0ec005b63a8b/ilt/spMySessions.do' from 2 maps Well that's the essence of the ajp protocol. The jsessionid will be removed from url and hardcoded inside ajp packet. Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JK 1.2.7 beta 3 + URL rewriting scheme issue
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 List Subject: Re: JK 1.2.7 beta 3 + URL rewriting scheme issue 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 helpful. [Thu Dec 16 11:37:58 2004] [5228:5468] [debug] jk_isapi_plugin.c (753): Virtual Host redirection of /dkoesxp/ilt/rd/8a3c3f8d03bf435b1e1f0ec005b63a8b/ilt/spMySessions.do;j sessionid=24B27CD241D89FB2A217DF21497E84B3.dkoesxp8009 [Thu Dec 16 11:37:58 2004] [5228:5468] [debug] jk_uri_worker_map.c (682): Attempting to map URI '/dkoesxp/ilt/rd/8a3c3f8d03bf435b1e1f0ec005b63a8b/ilt/spMySessions.do' from 2 maps Well that's the essence of the ajp protocol. The jsessionid will be removed from url and hardcoded inside ajp packet. Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JK 1.2.7 beta 3 + URL rewriting scheme issue
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 Developers List Subject: Re: JK 1.2.7 beta 3 + URL rewriting scheme issue 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 helpful. [Thu Dec 16 11:37:58 2004] [5228:5468] [debug] jk_isapi_plugin.c (753): Virtual Host redirection of /dkoesxp/ilt/rd/8a3c3f8d03bf435b1e1f0ec005b63a8b/ilt/spMySessions.do;j sessionid=24B27CD241D89FB2A217DF21497E84B3.dkoesxp8009 [Thu Dec 16 11:37:58 2004] [5228:5468] [debug] jk_uri_worker_map.c (682): Attempting to map URI '/dkoesxp/ilt/rd/8a3c3f8d03bf435b1e1f0ec005b63a8b/ilt/spMySessions.do' from 2 maps Well that's the essence of the ajp protocol. The jsessionid will be removed from url and hardcoded inside ajp packet. Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FW: JK 1.2.7 Problem?
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 release build and sent it to your email directly. Can you check the results with release build? Mladen. FYI - you are familiar with the fact that you do not need to build 'debug' in order to obtain useful info? Refer to any of the httpd module build projects for the semantics of building in release mode, yet extracting all debug symbolic information into a .pdb file. Other side effect is that you have two different malloc'ator schemes going on in a release-httpd and debug-jk combination. This mishmash causes me no end of grief every time I try it with release builds of libssl32 and libeay32 - it blows up in very odd places. Almost worth a whole article '_DEBUG considered harmful' :) Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 32741] New: - committed spelled wrong in INFO message
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. http://issues.apache.org/bugzilla/show_bug.cgi?id=32741 Summary: committed spelled wrong in INFO message Product: Tomcat 5 Version: 5.0.28 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Connector:Coyote AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The following was written to my catalina.out log many times. That committed was spelled wrong made it a little harder to research the problem on google. Dec 15, 2004 5:53:12 PM org.apache.jk.server.JkCoyoteHandler action INFO: Response already commited The error message comes from this file: jakarta-tomcat-connectors/jk/java/org/apache/jk/server/JkCoyoteHandler.java -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PersistentManagerBase (etc) Patches
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: [EMAIL PROTECTED]
Re: PersistentManagerBase (etc) Patches
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 issues in this area of the code that I cannot ignore if I am to depend on PersistentManager. Primary issues encountered were: * Race condition previous noted by FIXME. o There were no guarantees that a session would not be serialized to disk, passivated, and recyled while it was being used. o There were variations on this. I fixed the more obvious ones by the admittedly unfortunately synchronization on access() and around use of swapOut() in conjunction with checks on accessCount. The less obvious case required a change access(), Request, etc, to allow an already referenced (but not accessed) session which has been swapped out (and thus recycled) to be swapped back in within access() as necessary/appropriate. * Lack of any sort of LRU prioritization to what is passivated when the maximum number of active sessions has been exceeded. o I replaced usage of HashMap with LinkedHashMap in PersistentManagerBase (only). * Extremely inefficient behavior when trying to expire passivated sessions. o All passivated sessions were fully deserialized back into memory to check if they were stale upon each and every processExpires() execution. For large numbers of large sessions (the whole reason you'd bother with passivation!), this will be a large drain on performance. o My changes make the modification time more accessible in FileStore and make more efficient staleness checks in both FileStore and JDBCStore. Additionally there was a discrepancy between lastAccessedTime and thisAccessedTime usage in normal isValid(), etc, and the behavior of PersistentManagerBase, etc In all of these cases I may have misunderstood something or overlooked more optimal solutions. I would like to see all of these issues addressed in the best fashion possible -- and if possible in the standard distribution of Tomcat rather than just in ours. I am thus more than open to suggestions for improvement. The issue is that right now there are clear, unaddressed issues which I believe I have at least improved upon though certainly not perfected. -- Jess Holle P.S. I assumed Manager, etc, interfaces should not be extended, hence my introduction of some new methods at ManagerBase and my instanceof checks. This may have been a bad assumption, but this can easily be amended as needed.
Re: PersistentManagerBase (etc) Patches
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 could try adding volatile to the accessCount field, but it's really useless. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PersistentManagerBase (etc) Patches
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 feel insecure, then you could try adding volatile to the accessCount field, but it's really useless. Volatility of accessCount is a minor (though perhaps additionally necessary) part. The bigger issues are that: * During a request, between getSession(sessionId) and session.access() the session could be passivated and recycled -- thus lousing up that request. * A truly long request (e.g. a streaming dynamic content response) can be ongoing and have its session passivated and recycled while it is still ongoing -- recycling the session object it already has access to. As I recall there were other race condition possibilities, but these by themselves were too problematic to let alone. If anyone is actually able to get any robust value out of PersistentManager as it is, then I believe my changes to the passivated session expiration algorithm are a good thing. I just don't see how the whole thing is supposed to really hold water with known race conditions (including a FIXME noting them...) -- Jess Holle
Re: PersistentManagerBase (etc) Patches
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 something quite unimportant (if you think it is, add volatile which will solve the problem). We don't care about the exactitude of lastAccessedTime in this case (or you need to tell me why we care). The only race condition after my fix or before it? I will admit that I added complexity to base classes to support more robust operation of special purpose classes for session passivation. I loathed doing this, but did not see a good way to avoid this. As I recall if there was a single factory method for creating Session objects, then I could have just subclasses StandardSession and done everything in more derived classes -- leaving ManagerBase alone. I'd like that much better. Unfortunately, a static analyzer showed other usages of StandardSession's constructors. If I am in error on this, I'd be more than happy to rectify this! Right, and next time there's an issue, we'll add postAccess, I suppose. This is not workable. I'll put code correctness over code maintainability any day -- but that's just me. Clearly you try to balance both. [The change to Request is necessary in any case I can see, however -- unless a much higher level, and thus more expensive, synchronization is done between normal session access and passivation.] You need to relax a little about this kind of issues. The rest of your patch seems like a good start overall :) So you're proposing excising the preAccess() stuff? Or what exactly? I'd happily put most of the patch into the standard distribution and maintain the rest on my own if appropriate. That would lessen the maintenance burden on me and hopefully provide some benefit to everyone else. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PersistentManagerBase (etc) Patches
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 StandardSession changes into a new PersistentSession class and move my ManagerBase changes into PersistentManagerBase. Which portions of my changes woulud be objectionable in this case? [Yes, the Request change would still be necessary to prevent the chance of requests randomly getting their sessions passivated and recycle after they findSession() but before access().] -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/common HandlerRequest.java
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 PROTECTED]
Revision ChangesPath
1.41 +3 -6
jakarta-tomcat-connectors/jk/java/org/apache/jk/common/HandlerRequest.java
Index: HandlerRequest.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/common/HandlerRequest.java,v
retrieving revision 1.40
retrieving revision 1.41
diff -u -r1.40 -r1.41
--- HandlerRequest.java 11 Dec 2004 04:00:35 - 1.40
+++ HandlerRequest.java 17 Dec 2004 03:02:41 - 1.41
@@ -675,8 +675,6 @@
hId = -1;
msg.getBytes( tmpMB );
ByteChunk bc=tmpMB.getByteChunk();
-//hName=tmpMB.toString();
-//vMB=headers.addValue( hName );
vMB=headers.addValue( bc.getBuffer(),
bc.getStart(), bc.getLength() );
}
@@ -684,12 +682,11 @@
msg.getBytes(vMB);
if (hId == SC_REQ_CONTENT_LENGTH ||
-tmpMB.equalsIgnoreCase(Content-Length)) {
+(hId == -1 tmpMB.equalsIgnoreCase(Content-Length))) {
// just read the content-length header, so set it
-int contentLength = (vMB == null) ? -1 : vMB.getInt();
-req.setContentLength(contentLength);
+req.setContentLength( vMB.getInt() );
} else if (hId == SC_REQ_CONTENT_TYPE ||
- tmpMB.equalsIgnoreCase(Content-Type)) {
+(hId == -1 tmpMB.equalsIgnoreCase(Content-Type))) {
// just read the content-type header, so set it
ByteChunk bchunk = vMB.getByteChunk();
req.contentType().setBytes(bchunk.getBytes(),
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0 mod_jk.c
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 jakarta-tomcat-connectors/jk/native/apache-1.3/mod_jk.c
Index: mod_jk.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/apache-1.3/mod_jk.c,v
retrieving revision 1.59
retrieving revision 1.60
diff -u -r1.59 -r1.60
--- mod_jk.c 13 Dec 2004 09:11:24 - 1.59
+++ mod_jk.c 17 Dec 2004 03:14:56 - 1.60
@@ -592,12 +592,8 @@
char *hname = ap_pstrdup(r-pool, elts[i].key);
s-headers_values[i] = ap_pstrdup(r-pool, elts[i].val);
s-headers_names[i] = hname;
-while (*hname) {
-*hname = tolower(*hname);
-hname++;
-}
if (need_content_length_header
-!strncmp(s-headers_values[i], content-length, 14)) {
+!strcasecmp(s-headers_values[i], content-length)) {
need_content_length_header = JK_FALSE;
}
}
1.110 +2 -6 jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c
Index: mod_jk.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c,v
retrieving revision 1.109
retrieving revision 1.110
diff -u -r1.109 -r1.110
--- mod_jk.c 13 Dec 2004 09:10:31 - 1.109
+++ mod_jk.c 17 Dec 2004 03:14:56 - 1.110
@@ -636,12 +636,8 @@
char *hname = apr_pstrdup(r-pool, elts[i].key);
s-headers_values[i] = apr_pstrdup(r-pool, elts[i].val);
s-headers_names[i] = hname;
-while (*hname) {
-*hname = tolower(*hname);
-hname++;
-}
if (need_content_length_header
-!strncmp(s-headers_values[i], content-length, 14)) {
+!strcasecmp(s-headers_values[i], content-length)) {
need_content_length_header = JK_FALSE;
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: PersistentManagerBase (etc) Patches
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 these, but this would appear to keep
almost all substantive effects out of the base classes and limit them to
the session passivation classes which need these changes. I also
managed to eliminate the need for the endAccess() override (which was
really a workaround for the unbalanced endAccess() call in swapIn() --
though other unbalanced calls might benefit from some debug code in
endAccess() as well...).
--
Jess Holle
Jess Holle wrote:
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 StandardSession
changes into a new PersistentSession class and move my ManagerBase
changes into PersistentManagerBase.
Which portions of my changes woulud be objectionable in this case?
[Yes, the Request change would still be necessary to prevent the
chance of requests randomly getting their sessions passivated and
recycle after they findSession() but before access().]
--
Jess Holle
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Index: PersistentManagerBase.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/PersistentManagerBase.java,v
retrieving revision 1.25
diff -u -r1.25 PersistentManagerBase.java
--- PersistentManagerBase.java 22 Nov 2004 16:35:18 - 1.25
+++ PersistentManagerBase.java 17 Dec 2004 05:53:42 -
@@ -20,6 +20,11 @@
import java.beans.PropertyChangeEvent;
import java.beans.PropertyChangeListener;
import java.io.IOException;
+import java.util.ArrayList;
+import java.util.Collections;
+import java.util.Comparator;
+import java.util.LinkedHashMap;
+import java.util.Map;
import java.security.AccessController;
import java.security.PrivilegedActionException;
import java.security.PrivilegedExceptionAction;
@@ -204,17 +209,44 @@
protected long processingTime = 0;
-// - Properties
+/**
+ * Whether session should be synchronously swapped out immediately upon
+ * exceeding maxActiveSessions. Defaults to 'false'.
+ */
+protected boolean immediateSwapOnMaxActiveExceeded = false;
+
+
+// -
Constructors
+
+
+public PersistentManagerBase() {
+sessions = new LinkedHashMap() {
+protected boolean removeEldestEntry(Map.Entry eldest) {
+if ( immediateSwapOnMaxActiveExceeded ) {
+ int maxActiveSessions = getMaxActiveSessions();
+ if ( maxActiveSessions = 0 )
+ if ( size() maxActiveSessions )
+ if ( isStarted() )
+ // try to swap out oldest entry; if entry is
still too fresh then processMaxActiveSwaps() will swap out sessions when
possible in the background
+ swapOutSessionIfOldEnough( (StandardSession)
eldest.getValue(), System.currentTimeMillis(), minIdleSwap,
persistentManager.swapTooManyActive );
+}
+return ( false );
+}
+};
+}
-
+// - Properties
+
+
+
/**
-* Indicates how many seconds old a session can get, after its last use
in a
-* request, before it should be backed up to the store. -1 means
sessions
-* are not backed up.
-*/
+ * Indicates how many seconds old a session can get, after its last use in
a
+ * request, before it should be backed up to the store. -1 means sessions
+ * are not backed up.
+ */
public int getMaxIdleBackup() {
return maxIdleBackup;
@@ -314,13 +346,13 @@
/**
-* Set the Container with which this Manager has been associated. If it
is a
-* Context (the usual case), listen for changes to the session timeout
-* property.
-*
-* @param container
-*The associated Container
-*/
+ * Set the Container with which this Manager has been associated. If it is
a
+ * Context (the usual case), listen for changes to the session timeout
+ * property.
+ *
+ * @param container
+ *The associated Container
+ */
public void setContainer(Container container) {
cvs commit: jakarta-tomcat-connectors/jk/native/common jk_ajp_common.c
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: jk_ajp_common.c
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_ajp_common.c,v
retrieving revision 1.67
retrieving revision 1.68
diff -u -r1.67 -r1.68
--- jk_ajp_common.c 15 Dec 2004 20:31:16 - 1.67
+++ jk_ajp_common.c 16 Dec 2004 08:38:05 - 1.68
@@ -72,106 +72,183 @@
{
const char *rc = NULL;
sc = sc 0X00FF;
-if(sc = SC_RES_HEADERS_NUM sc 0) {
+if (sc = SC_RES_HEADERS_NUM sc 0) {
rc = response_trans_headers[sc - 1];
}
return rc;
}
+#define UNKNOWN_METHOD (-1)
-static int sc_for_req_method(const char *method, unsigned char *sc)
+static int sc_for_req_method(const char *method, size_t len)
{
-int rc = JK_TRUE;
-if (0 == strcmp(method, GET)) {
-*sc = SC_M_GET;
-}
-else if (0 == strcmp(method, POST)) {
-*sc = SC_M_POST;
-}
-else if (0 == strcmp(method, HEAD)) {
-*sc = SC_M_HEAD;
-}
-else if (0 == strcmp(method, PUT)) {
-*sc = SC_M_PUT;
-}
-else if (0 == strcmp(method, DELETE)) {
-*sc = SC_M_DELETE;
-}
-else if (0 == strcmp(method, OPTIONS)) {
-*sc = SC_M_OPTIONS;
-}
-else if (0 == strcmp(method, TRACE)) {
-*sc = SC_M_TRACE;
-}
-else if (0 == strcmp(method, PROPFIND)) {
-*sc = SC_M_PROPFIND;
-}
-else if (0 == strcmp(method, PROPPATCH)) {
-*sc = SC_M_PROPPATCH;
-}
-else if (0 == strcmp(method, MKCOL)) {
-*sc = SC_M_MKCOL;
-}
-else if (0 == strcmp(method, COPY)) {
-*sc = SC_M_COPY;
-}
-else if (0 == strcmp(method, MOVE)) {
-*sc = SC_M_MOVE;
-}
-else if (0 == strcmp(method, LOCK)) {
-*sc = SC_M_LOCK;
-}
-else if (0 == strcmp(method, UNLOCK)) {
-*sc = SC_M_UNLOCK;
-}
-else if (0 == strcmp(method, ACL)) {
-*sc = SC_M_ACL;
-}
-else if (0 == strcmp(method, REPORT)) {
-*sc = SC_M_REPORT;
-}
-else if (0 == strcmp(method, VERSION-CONTROL)) {
-*sc = SC_M_VERSION_CONTROL;
-}
-else if (0 == strcmp(method, CHECKIN)) {
-*sc = SC_M_CHECKIN;
-}
-else if (0 == strcmp(method, CHECKOUT)) {
-*sc = SC_M_CHECKOUT;
-}
-else if (0 == strcmp(method, UNCHECKOUT)) {
-*sc = SC_M_UNCHECKOUT;
-}
-else if (0 == strcmp(method, SEARCH)) {
-*sc = SC_M_SEARCH;
-}
-else if (0 == strcmp(method, MKWORKSPACE)) {
-*sc = SC_M_MKWORKSPACE;
-}
-else if (0 == strcmp(method, UPDATE)) {
-*sc = SC_M_UPDATE;
-}
-else if (0 == strcmp(method, LABEL)) {
-*sc = SC_M_LABEL;
-}
-else if (0 == strcmp(method, MERGE)) {
-*sc = SC_M_MERGE;
-}
-else if (0 == strcmp(method, BASELINE-CONTROL)) {
-*sc = SC_M_BASELINE_CONTROL;
-}
-else if (0 == strcmp(method, MKACTIVITY)) {
-*sc = SC_M_MKACTIVITY;
-}
-else {
-rc = JK_FALSE;
-}
+/* Note: the following code was generated by the shilka tool from
+ the cocom parsing/compilation toolkit. It is an optimized lookup
+ based on analysis of the input keywords. Postprocessing was done
+ on the shilka output, but the basic structure and analysis is
+ from there. Should new HTTP methods be added, then manual insertion
+ into this code is fine, or simply re-running the shilka tool on
+ the appropriate input. */
+
+/* Note: it is also quite reasonable to just use our method_registry,
+ but I'm assuming (probably incorrectly) we want more speed here
+ (based on the optimizations the previous code was doing). */
+
+switch (len)
+{
+case 3:
+switch (method[0])
+{
+case 'P':
+return (method[1] == 'U'
+ method[2] == 'T'
+? SC_M_PUT : UNKNOWN_METHOD);
+case 'G':
+return (method[1] == 'E'
+ method[2] == 'T'
+? SC_M_GET : UNKNOWN_METHOD);
+default:
+return UNKNOWN_METHOD;
+}
-return rc;
-}
+case 4:
+switch (method[0])
+{
+case 'H':
+return (method[1] == 'E'
+ method[2] == 'A'
+ method[3] == 'D'
+? SC_M_GET : UNKNOWN_METHOD);
+
Re: cvs commit: jakarta-tomcat-connectors/jk/native/common jk_ajp_common.c
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 subscribe box. HOW TO CHANGE YOUR EMAIL ADDRESS: First unsubscribe, then subscribe with your new email address, using the instructions above. HOW TO CONTACT US: If you would like to send us a comment, ask a question, submit a picture or joke, or are interested in advertising, you can email us at [EMAIL PROTECTED] Regards, InsanePictures.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native/common jk_ajp_common.c jk_ajp_common.h
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
jakarta-tomcat-connectors/jk/native/common/jk_ajp_common.c
Index: jk_ajp_common.c
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_ajp_common.c,v
retrieving revision 1.68
retrieving revision 1.69
diff -u -r1.68 -r1.69
--- jk_ajp_common.c 16 Dec 2004 08:38:05 - 1.68
+++ jk_ajp_common.c 16 Dec 2004 09:49:41 - 1.69
@@ -1958,14 +1958,13 @@
if (pThis pThis-worker_private je) {
ajp_worker_t *aw = pThis-worker_private;
ajp_endpoint_t *ae = NULL;
+time_t now = time(NULL);
if (aw-ep_cache_sz) {
int rc;
JK_ENTER_CS(aw-cs, rc);
if (rc) {
unsigned i;
-time_t now;
-now = time(NULL);
for (i = 0; i aw-ep_cache_sz; i++) {
if (aw-ep_cache[i]) {
ae = aw-ep_cache[i];
@@ -1974,9 +1973,10 @@
}
}
/* Handle enpoint cache timeouts */
-if (aw-cache_timeout) {
-for (; i aw-ep_cache_sz; i++) {
-if (aw-ep_cache[i]) {
+if (ae aw-cache_timeout) {
+for (i = 0; i aw-ep_cache_sz; i++) {
+/* Skip the cached enty */
+if (aw-ep_cache[i] (ae != aw-ep_cache[i])) {
int elapsed =
(int)(now - ae-last_access);
if (elapsed aw-cache_timeout) {
@@ -1994,7 +1994,6 @@
if (ae-sd 0) {
/* Handle timeouts for open sockets */
int elapsed = (int)(now - ae-last_access);
-ae-last_access = now;
jk_log(l, JK_LOG_DEBUG,
time elapsed since last request = %u
seconds\n,
elapsed);
@@ -2007,18 +2006,19 @@
ae-sd = -1;/* just to avoid twice close
*/
}
}
+ae-last_access = now;
*je = ae-endpoint;
JK_TRACE_EXIT(l);
return JK_TRUE;
}
}
}
-
+/* Create new endpoint */
ae = (ajp_endpoint_t *) calloc(1, sizeof(ajp_endpoint_t));
if (ae) {
ae-sd = -1;
ae-reuse = JK_FALSE;
-ae-last_access = time(NULL);
+ae-last_access = now;
jk_open_pool(ae-pool, ae-buf, sizeof(ae-buf));
ae-worker = pThis-worker_private;
ae-endpoint.endpoint_private = ae;
1.27 +2 -2
jakarta-tomcat-connectors/jk/native/common/jk_ajp_common.h
Index: jk_ajp_common.h
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_ajp_common.h,v
retrieving revision 1.26
retrieving revision 1.27
diff -u -r1.26 -r1.27
--- jk_ajp_common.h 10 Nov 2004 16:36:48 - 1.26
+++ jk_ajp_common.h 16 Dec 2004 09:49:42 - 1.27
@@ -188,7 +188,7 @@
#define AJP_HEADER_LEN(4)
#define AJP_HEADER_SZ_LEN (2)
#define CHUNK_BUFFER_PAD (12)
-#define AJP_DEF_CACHE_TIMEOUT (15)
+#define AJP_DEF_CACHE_TIMEOUT (0)
#define AJP_DEF_CONNECT_TIMEOUT (0) /* NO CONNECTION TIMEOUT = NO
CPING/CPONG */
#define AJP_DEF_REPLY_TIMEOUT (0) /* NO REPLY TIMEOUT
*/
#define AJP_DEF_PREPOST_TIMEOUT (0) /* NO PREPOST TIMEOUT = NO
CPING/CPONG*/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
j2me tomcat manager
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 provided, it can start/stop and restart any of the running applications through a mobile (j2me enabled) phone. It is quite useful for these occasions where you want to reload your application at 2.00 am while clubbing :-) Is anybody interested? Do you want to include it with the tomcat distribution? Cheers, Fotis - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 32729] - Can deploy but not undeploy improperly configured webapps
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. http://issues.apache.org/bugzilla/show_bug.cgi?id=32729 --- Additional Comments From [EMAIL PROTECTED] 2004-12-16 13:50 --- I'll look at it, but using deploy and undeploy. install and remove are deprecated and unsupported. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PersistentManagerBase (etc) Patches
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 used 'diff -u' in a
directory not in a proper CVS tool...), please see the attached patch
files against 5.0.30 (which were donoe with a proper CVS tool).
I have reworked this for 5.5.4 as well, but there are a number of
changes between 5.5.4 and 5.5.6 in these same files. I thus plan to
merge up to 5.5.6 before passing these patches along. If anyone is
desparately interested in the 5.5.4 stuff now, let me know.
Overall, I do believe these are a substantial improvement over the
current code, so I'd appreciate it if someone reviewed them a bit --
especially the 5.5.6 versions as it would be good to see this merged
in to 5.5.x at least.
--
Jess Holle
Jess Holle wrote:
A week or two ago I found I had need of the persistent session
manager, PersistentManagerBase -- and also noticed its experimental
status.
Looking at the sources I found FIXME comments regarding: (1) a
race condition between session passivation and session usage and (2)
a lack of LRU sorting to passivate oldest sessions first. I also
discovered that all passivated sessions are regularly (every minuted
by default) read back into memory in their entirety to check if they
should be expired.
The attached set of patches is intended to address all of these
issues -- and seems to do so to the best of my (admittedly limited)
testing.
There are additional fixes that should be made to JDBCStore (i.e. in
general it seems to a trip to the database for every row in many
cases where 1 per 'n' would suffice), but this was of less interest
to me for the time being than FileStore, so I have not pursued
these. Also, I introduced a new attribute to PersistentManagerBase,
but have not yet exposed it via JMX. This is intentional at this
point as I am uncertain as to the merits of the non-default value of
this operation as of yet.
Comments and questions are welcome. All of the patches are against
5.0.30, but I could update them for 5.5.x if there was sufficient
interest (e.g. if a committer was interested in committing them).
--
Jess Holle
[EMAIL PROTECTED]
Index: Request.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector/Request.java,v
retrieving revision 1.18
diff -u -r1.18 Request.java
--- Request.java20 Nov 2004 21:10:47 - 1.18
+++ Request.java16 Dec 2004 17:47:20 -
@@ -2178,11 +2178,11 @@
} catch (IOException e) {
session = null;
}
-if ((session != null) !session.isValid())
-session = null;
if (session != null) {
session.access();
-return (session);
+if (session.isValid()) // check isValid() *after* access()!
+return (session);
+session = null;
}
}
Index: JDBCStore.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/JDBCStore.java,v
retrieving revision 1.12
diff -u -r1.12 JDBCStore.java
--- JDBCStore.java 2 Nov 2004 20:05:12 - 1.12
+++ JDBCStore.java 16 Dec 2004 17:47:20 -
@@ -151,6 +151,11 @@
protected PreparedStatement preparedKeysSql = null;
/**
+ * Variable to hold the codekeysThatMayBeExpired()/code prepared
statement.
+ */
+protected PreparedStatement preparedKeysThatMayBeExpiredSql = null;
+
+/**
* Variable to hold the codesave()/code prepared statement.
*/
protected PreparedStatement preparedSaveSql = null;
@@ -456,7 +461,7 @@
+ sessionTable + WHERE + sessionAppCol
+ = ?;
preparedKeysSql = _conn.prepareStatement(keysSql);
- }
+}
preparedKeysSql.setString(1, getName());
rst = preparedKeysSql.executeQuery();
@@ -491,6 +496,66 @@
return (keys);
}
+protected String[] keysThatMayBeExpired()
+throws IOException
+{
+int maxInactiveInterval = ((ManagerBase)manager).maxInactiveInterval;
+if ( maxInactiveInterval 0 )
+return new String[0];
+
+ResultSet rst = null;
+String keys[] = null;
+synchronized (this) {
+int numberOfTries = 2;
+while (numberOfTries 0) {
+
+Connection _conn = getConnection();
+if (_conn == null) {
+return (new
Re: JK throws java.lang.NumberFormatException when JSP is not found. (trace logging)
- 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 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), err=-1 Tomcat is *not* down though ;) The tomcat is down is IIS's response to Tomcat dropping the connection after the exception. It's strange that the 'bad' message and the 'good' retry message seem to be identical (and perfectly valid AJP/1.3 packets). Of course, JK1.2.8-RC1 will send different packets now that Mladen has fixed header parsing, but both forms are valid. In particular, the Content-Length is the string 0. I'd love to see the dump from the Tomcat side if you get a chance. This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PersistentManagerBase (etc) Patches
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. I've included them below: I don't like the foundation on which the patch stands, unfortunately. I did not get a warm fuzzy this is rock solid stuff feeling about this myself... That said, if there are problems with the foundation, then let's rework it. In the end, I did not see too much glaringly awful about the approach. I unfortunately need session passivation, so if necessary I'll have just keep this in my own distribution if that's what it takes. I am guessing I'm not the *only* one in this boat, so it would be good to work this out... I also don't quite see the real-world usefulness of some of the new features, for example the date usage sorting. If you have a limit on the maximum active sessions and many more sessions than this (when non-expired, passivated sessions are included) then it makes sense to have a fairly aggressive minimum idle time prior to passivation but to ensure that the oldest non-passivated session will be passivated first so as to avoid thrashing between active and passive states where it is not necessary. In particular, all the proposed changes to the base classes (std session, manager base, request), which seem to be designed to add fake robustness to the mix, and add more complexity. I don't think any of these changes bring anything useful, but they do decrease performance and maintainability. 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. I will admit that I added complexity to base classes to support more robust operation of special purpose classes for session passivation. I loathed doing this, but did not see a good way to avoid this. As I recall if there was a single factory method for creating Session objects, then I could have just subclasses StandardSession and done everything in more derived classes -- leaving ManagerBase alone. I'd like that much better. Unfortunately, a static analyzer showed other usages of StandardSession's constructors. If I am in error on this, I'd be more than happy to rectify this! All the same the changes to the base classes are fairly minimally obtrusive. If they cannot be avoided, then they seem worth living with for some of us to have session passivation... [The change to Request is necessary in any case I can see, however -- unless a much higher level, and thus more expensive, synchronization is done between normal session access and passivation.] -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PersistentManagerBase (etc) Patches
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 when trying to expire passivated sessions. o All passivated sessions were fully deserialized back into memory to check if they were stale upon each and every processExpires() execution. For large numbers of large sessions (the whole reason you'd bother with passivation!), this will be a large drain on performance. o My changes make the modification time more accessible in FileStore and make more efficient staleness checks in both FileStore and JDBCStore. This seems useful. Additionally there was a discrepancy between lastAccessedTime and thisAccessedTime usage in normal isValid(), etc, and the behavior of PersistentManagerBase, etc In all of these cases I may have misunderstood something or overlooked more optimal solutions. I would like to see all of these issues addressed in the best fashion possible -- and if possible in the standard distribution of Tomcat rather than just in ours. I am thus more than open to suggestions for improvement. The issue is that right now there are clear, unaddressed issues which I believe I have at least improved upon though certainly not perfected. As I said: I don't like the foundation on which the patch stands, unfortunately. I also don't quite see the real-world usefulness of some of the new features, for example the date usage sorting. In particular, all the proposed changes to the base classes (std session, manager base, request), which seem to be designed to add fake robustness to the mix, and add more complexity. I don't think any of these changes bring anything useful, but they do decrease performance and maintainability. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PersistentManagerBase (etc) Patches
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 inefficient behavior when trying to expire passivated sessions. o All passivated sessions were fully deserialized back into memory to check if they were stale upon each and every processExpires() execution. For large numbers of large sessions (the whole reason you'd bother with passivation!), this will be a large drain on performance. o My changes make the modification time more accessible in FileStore and make more efficient staleness checks in both FileStore and JDBCStore. This seems useful. It is not useful without the rest of the changes as without the rest of the changes there are intolerable race conditions. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PersistentManagerBase (etc) Patches
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 (if you think it is, add volatile which will solve the problem). We don't care about the exactitude of lastAccessedTime in this case (or you need to tell me why we care). I will admit that I added complexity to base classes to support more robust operation of special purpose classes for session passivation. I loathed doing this, but did not see a good way to avoid this. As I recall if there was a single factory method for creating Session objects, then I could have just subclasses StandardSession and done everything in more derived classes -- leaving ManagerBase alone. I'd like that much better. Unfortunately, a static analyzer showed other usages of StandardSession's constructors. If I am in error on this, I'd be more than happy to rectify this! Right, and next time there's an issue, we'll add postAccess, I suppose. This is not workable. [The change to Request is necessary in any case I can see, however -- unless a much higher level, and thus more expensive, synchronization is done between normal session access and passivation.] You need to relax a little about this kind of issues. The rest of your patch seems like a good start overall :) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
