Re: [ANN/VOTE] JK 1.2.11 Released
Good evening All, In trying the latest Mod_Jk (with Mladen's recent 'NetWare' patch), I noticed the jkstatus page provides two configurable parameters for an LB worker: 'retries' and 'recover_wait_time', neither of which are (as yet) documented for the LB worker. I also note the 'retries' can be set via the workers.properties file, (worker.lb1.retries), but, AFAICT, 'recover_wait_time' can not be set. Lastly I note that what ever routine parses workers.properties, it has the view that any property setting it doesn't know about it simply ignores, and gives not even a mention of it in the logs (debug mode). Regards, Norm Mladen Turk wrote: Jean-Jacques Clar wrote: Thank you Mladen, the patch is working for me. Cool :). I cannot put 1.2.11 in our NetWare build because of that problem. Sure. I will run stress test over the week-end and will have functionality testing done in our lab on Monday, both on HEAD. Let's keep the jk 1.2.11 around for a week or so. I will not advertise it as stable because of that bug, but I think we can go to 1.2.12 if nothing else critical found. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] . - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN/VOTE] JK 1.2.11 Released
NormW wrote: Good evening All, In trying the latest Mod_Jk (with Mladen's recent 'NetWare' patch), I noticed the jkstatus page provides two configurable parameters for an LB worker: 'retries' and 'recover_wait_time', neither of which are (as yet) documented for the LB worker. If 'retries' set to the lb it will be used instead each worker retries option. It is documented in the workers section. I also note the 'retries' can be set via the workers.properties file, (worker.lb1.retries), but, AFAICT, 'recover_wait_time' can not be set. It can, by using worker.lb1.recover_time=NN (seconds) Minimum value is 60 seconds, and it is used to retry the worker in case the worker is in error state. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN/VOTE] JK 1.2.11 Released
Hello and Good Evening from Au. Thanks for the _very fast_ feedback and clarifies points I had not discovered. :-) Hopefully the pieces of information you provided will eventually make it into the docs? Even the 'global' nature of the retries parameter when used on the lb worker would be of potential use to some users and is not mentioned in the ajp13 section either. :-) I'm not sure if it's a NetWare bug only, but for interest I have two JkEnvVar entries in my .conf and noticed they were not displayed when using the /admin tool with 5.0.30 Tomcat (Resources/MemVars). Or does this only show values set at the Tomcat end? The Jk docs show a sample for the JkEnvVar directive as: JkEnvVar SSL_CLIENT_V_START but Apache expects a two part answer: AP_INIT_TAKE2(JkEnvVar, jk_add_env_var, NULL, RSRC_CONF, Adds a name of environment variable that should be sent to servlet-engine) Most directives are global AFAIK, but it might be of use (to those that need it) if JkEnvVar settings could be limited to directory or location requests if desired, rather than passed to Tomcat for _every_ request. Regards, Norm Mladen Turk wrote: NormW wrote: Good evening All, In trying the latest Mod_Jk (with Mladen's recent 'NetWare' patch), I noticed the jkstatus page provides two configurable parameters for an LB worker: 'retries' and 'recover_wait_time', neither of which are (as yet) documented for the LB worker. If 'retries' set to the lb it will be used instead each worker retries option. It is documented in the workers section. I also note the 'retries' can be set via the workers.properties file, (worker.lb1.retries), but, AFAICT, 'recover_wait_time' can not be set. It can, by using worker.lb1.recover_time=NN (seconds) Minimum value is 60 seconds, and it is used to retry the worker in case the worker is in error state. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] . - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project jakarta-tomcat-jk-native (in module jakarta-tomcat-connectors) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project jakarta-tomcat-jk-native has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 129 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - jakarta-tomcat-jk-native : Connectors to various web servers Full details are available at: http://brutus.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -INFO- Failed with reason build failed The following work was performed: http://brutus.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native/gump_work/build_jakarta-tomcat-connectors_jakarta-tomcat-jk-native.html Work Name: build_jakarta-tomcat-connectors_jakarta-tomcat-jk-native (Type: Build) Work ended in a state of : Failed Elapsed: Command Line: make [Working Directory: /usr/local/gump/public/workspace/jakarta-tomcat-connectors/jk/native] - Making all in common make[1]: Entering directory `/home/gump/workspaces2/public/workspace/jakarta-tomcat-connectors/jk/native/common' /bin/sh /usr/local/gump/public/workspace/apache-httpd/dest-02052005/build/libtool --silent --mode=compile gcc -I/usr/local/gump/public/workspace/apache-httpd/dest-02052005/include -g -O2 -g -O2 -pthread -DHAVE_APR -I/usr/local/gump/public/workspace/apr/dest-02052005/include/apr-1 -g -O2 -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -I/home/gump/workspaces2/public/workspace/apache-httpd/srclib/pcre -I /opt/jdk1.4/include -I /opt/jdk1.4/include/ -c jk_ajp12_worker.c /usr/local/gump/public/workspace/apache-httpd/dest-02052005/build/libtool: /usr/local/gump/public/workspace/apache-httpd/dest-02052005/build/libtool: No such file or directory make[1]: *** [jk_ajp12_worker.lo] Error 127 make[1]: Leaving directory `/home/gump/workspaces2/public/workspace/jakarta-tomcat-connectors/jk/native/common' make: *** [all-recursive] Error 1 - To subscribe to this information via syndicated feeds: - RSS: http://brutus.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native/rss.xml - Atom: http://brutus.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 2902052005, brutus:brutus-public:2902052005 Gump E-mail Identifier (unique within run) #21. -- Apache Gump http://gump.apache.org/ [Instance: brutus] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 7831] - [PATCH] JNDIRealm does not work with CLIENT-CERT auth method
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=7831. 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=7831 [EMAIL PROTECTED] changed: What|Removed |Added Attachment #6735 is|0 |1 obsolete|| -- 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]
DO NOT REPLY [Bug 7831] - [PATCH] JNDIRealm does not work with CLIENT-CERT auth method
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=7831. 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=7831 --- Additional Comments From [EMAIL PROTECTED] 2005-05-02 11:40 --- Created an attachment (id=14901) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=14901action=view) Updated version for the two Realms Updated just to put my latest version here -- 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]
DO NOT REPLY [Bug 33777] - tomcat not supporting jrockit jdk
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=33777. 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=33777 --- Additional Comments From [EMAIL PROTECTED] 2005-05-02 12:11 --- This is no longer a case. Tomcat runs like a charm on the latest'n'greatest JRockit 5.0 (R25.1). Thanks you BEA guys for listening. -- 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]
Unique Session ID's - are they really generated?
Hi, On some application servers I have used in the past when you shut them down and restarted the server it was possible that duplicate session ID's were generated matching those in a previously running instance of the server. Does anyone know if tomcat really has Unique Session ID creation. That is I leave tomcat running for a week. Stop it. Start it. Is it possible that a duplication session ID will be created in my new running instance that matches a session ID created in my previous running instance. I just want to know does tomcat really guarantee unique Session ID's even over shutdown and start ups?? Thanks, Steve. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Unique Session ID's - are they really generated?
It sounds like you are talking about IIS, where the session ID was the memory handle to the session object George Sexton MH Software, Inc. http://www.mhsoftware.com/ Voice: 303 438 9585 -Original Message- From: Steven Pannell [mailto:[EMAIL PROTECTED] Sent: Monday, May 02, 2005 8:05 AM To: 'tomcat-dev@jakarta.apache.org' Subject: Unique Session ID's - are they really generated? Hi, On some application servers I have used in the past when you shut them down and restarted the server it was possible that duplicate session ID's were generated matching those in a previously running instance of the server. Does anyone know if tomcat really has Unique Session ID creation. That is I leave tomcat running for a week. Stop it. Start it. Is it possible that a duplication session ID will be created in my new running instance that matches a session ID created in my previous running instance. I just want to know does tomcat really guarantee unique Session ID's even over shutdown and start ups?? Thanks, Steve. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Unique Session ID's - are they really generated?
Hi, Does anyone know if tomcat really has Unique Session ID creation. That is I leave tomcat running for a week. Stop it. Start it. Is it possible that a duplication session ID will be created in my new running instance that matches a session ID created in my previous running instance. It's possible, but exceedingly unlikely. You can go over the implementation yourself (the beauty of open-source ;)). But even if you don't want to do that, make sure to read http://jakarta.apache.org/tomcat/tomcat-5.5-doc/config/manager.html. Note that by configuring some of the Manager parameters discussed on this page, such as entropy, every time you restart the server, you can further reduce duplicate session ID probability. Alternatively, if you're really paranoid about this, simply extend the existing manager with one that keeps track of past session IDs, and does not issue them ever again ;) Yoav Shapira System Design and Management Fellow MIT Sloan School of Management / School of Engineering Cambridge, MA USA [EMAIL PROTECTED] / [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34710] New: - Tomcat 4.1.27. uses almost 100% CPU Memory when run as service
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=34710. 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=34710 Summary: Tomcat 4.1.27. uses almost 100% CPU Memory when run as service Product: Tomcat 4 Version: 4.1.27 Platform: PC OS/Version: Windows 2000 Status: NEW Severity: major Priority: P2 Component: Webapps:Administration AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] We have Tomcat 4.1.27 installed on Windows 2000 server running as service mode with MS IIS. When Tomcat service is enabled, Tomcat is using almost 100% CPU and memory usage in ideal condition. I tried to run Tomcat as application mode (from command prompt) then it runs fine with very minimum usage of CPU and Memory. Could you please shate what could be the reason and if there is any solution? Is there any bug with this version? Thanks in advance, -- 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]
mod_jk configure failover
Now that local worker is gone from mod_jk how can you configure two app servers where you want one to be the primary and the second one to be used for automatic failover only if the primary is in an error state? I tried setting lbfactor=1 on the primary and lbfactor=0 on the failover worker but mod_jk sets lbfactor=1 if you configure a value 1. Thanks, Glenn -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk configure failover
Glenn Nielsen wrote: Now that local worker is gone from mod_jk how can you configure two app servers where you want one to be the primary and the second one to be used for automatic failover only if the primary is in an error state? Use 'disabled' flag for standby worker with 'redirect' to that worker. worker.w1.disabled=False worker.w1.redirect=w2 worker.w2.disabled=True You can even redirect to the 'domain' or group of workers. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk configure failover
Hey Glenn, a hot standby is very easy. You confgure your nodes inside a loadbalancer and then disabled some nodes. Very best is, you can configure this with the new lb status worker. Example: IfModule !mod_jk.c LoadModule jk_module modules/mod_jk.so /IfModule JkWorkerProperty worker.list=loadbalancer,jkstatus JkWorkerProperty worker.node01.type=ajp13 JkWorkerProperty worker.node01.port=7201 JkWorkerProperty worker.node01.host=localhost JkWorkerProperty worker.node01.cachesize=150 JkWorkerProperty worker.node01.cache_timeout=600 JkWorkerProperty worker.node02.type=ajp13 JkWorkerProperty worker.node02.port=7202 JkWorkerProperty worker.node02.host=localhost JkWorkerProperty worker.node02.cachesize=150 JkWorkerProperty worker.node02.cache_timeout=600 JkWorkerProperty worker.node02.disabled=false JkWorkerProperty worker.loadbalancer.type=lb JkWorkerProperty worker.loadbalancer.balance_workers=node01,node02 JkWorkerProperty worker.jkstatus.type=status JkLogFile logs/mod_jk.log JkLogLevel info # unix only JkShmMem logs/mod_jk.shm JkMountFile conf/uriworkermap.properties JkMount /jkstatus jkstatus At mod_jk 1.2.11 exists also a stopped flag to setup a cold standby. s. http://jakarta.apache.org/tomcat/connectors-doc/config/workers.html regards Peter Glenn Nielsen schrieb: Now that local worker is gone from mod_jk how can you configure two app servers where you want one to be the primary and the second one to be used for automatic failover only if the primary is in an error state? I tried setting lbfactor=1 on the primary and lbfactor=0 on the failover worker but mod_jk sets lbfactor=1 if you configure a value 1. Thanks, Glenn -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/servlets DefaultServlet.java
luehe 2005/05/02 09:52:10
Modified:catalina/src/share/org/apache/catalina/servlets
DefaultServlet.java
Log:
- Avoid cache lookup if
trimmed.equalsIgnoreCase(WEB-INF) ||
trimmed.equalsIgnoreCase(META-INF) ||
trimmed.equalsIgnoreCase(localXsltFile)
- Avoid NPE (by adding check for childCacheEntry.exists)
in the case where ProxyDirContext.lookupCache()
swallows NamingException, in which case the attributes field of
the returned childCacheEntry will be null, causing
childCacheEntry.attributes.getContentLength()
in DefaultServlet.renderXml() to throw NPE.
Revision ChangesPath
1.36 +7 -5
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java
Index: DefaultServlet.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java,v
retrieving revision 1.35
retrieving revision 1.36
diff -u -r1.35 -r1.36
--- DefaultServlet.java 29 Apr 2005 20:04:03 - 1.35
+++ DefaultServlet.java 2 May 2005 16:52:10 - 1.36
@@ -1164,7 +1164,6 @@
CacheEntry childCacheEntry =
resources.lookupCache(cacheEntry.name + resourceName);
-
if (!childCacheEntry.exists) {
continue;
}
@@ -1330,14 +1329,17 @@
NameClassPair ncPair = (NameClassPair)
enumeration.nextElement();
String resourceName = ncPair.getName();
-CacheEntry childCacheEntry =
-resources.lookupCache(cacheEntry.name + resourceName);
-
String trimmed = resourceName/*.substring(trim)*/;
if (trimmed.equalsIgnoreCase(WEB-INF) ||
trimmed.equalsIgnoreCase(META-INF))
continue;
+CacheEntry childCacheEntry =
+resources.lookupCache(cacheEntry.name + resourceName);
+if (!childCacheEntry.exists) {
+continue;
+}
+
sb.append(tr);
if (shade)
sb.append( bgcolor=\#ee\);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk configure failover
On Mon, May 02, 2005 at 06:17:50PM +0200, Mladen Turk wrote:
Glenn Nielsen wrote:
Now that local worker is gone from mod_jk how can you configure
two app servers where you want one to be the primary and the
second one to be used for automatic failover only if the primary
is in an error state?
Use 'disabled' flag for standby worker with 'redirect' to that worker.
worker.w1.disabled=False
worker.w1.redirect=w2
worker.w2.disabled=True
You can even redirect to the 'domain' or group of workers.
Thanks.
This seems to be a roundabout way to setup failover on error
and confuses what disabled=true means.
So let me get this straight, please correct me if I am wrong.
As of 1.2.11:
If disabled=true for a worker that worker can still receive
requests if:
a) Another real worker has redirect={disabled worker}
b) A request has a JSESSIONID with the disabled worker jvmroute
If you really want to disable a worker completely you need to use
the new stopped=True property?
Regards,
Glenn
--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
--
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk configure failover
Hey Glenn,
yes, disabled means, only that no new sessions send to a worker, but
request with
JSESSIONID send to the worker and
stopped means, no more requests send to a worker.
Peter
Glenn Nielsen schrieb:
On Mon, May 02, 2005 at 06:17:50PM +0200, Mladen Turk wrote:
Glenn Nielsen wrote:
Now that local worker is gone from mod_jk how can you configure
two app servers where you want one to be the primary and the
second one to be used for automatic failover only if the primary
is in an error state?
Use 'disabled' flag for standby worker with 'redirect' to that worker.
worker.w1.disabled=False
worker.w1.redirect=w2
worker.w2.disabled=True
You can even redirect to the 'domain' or group of workers.
Thanks.
This seems to be a roundabout way to setup failover on error
and confuses what disabled=true means.
So let me get this straight, please correct me if I am wrong.
As of 1.2.11:
If disabled=true for a worker that worker can still receive
requests if:
a) Another real worker has redirect={disabled worker}
b) A request has a JSESSIONID with the disabled worker jvmroute
If you really want to disable a worker completely you need to use
the new stopped=True property?
Regards,
Glenn
--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
--
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/webdav index.html
keith 2005/05/02 15:13:36 Modified:webapps/webdav index.html Log: Update dav client compat list Revision ChangesPath 1.4 +1 -1 jakarta-tomcat-catalina/webapps/webdav/index.html Index: index.html === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/webdav/index.html,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- index.html23 Mar 2005 02:43:17 - 1.3 +++ index.html2 May 2005 22:13:36 - 1.4 @@ -50,7 +50,7 @@ liJakarta Slide 1.0 WebDAV client library/li liOffice 2000 (Windows 2000)/li liSkunkDAV 1.0/li -liXythos WebFile Client/li +liXythos Drive/li /ul pWebDAV links:/p - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/webdav index.html
keith 2005/05/02 15:13:50 Modified:webapps/webdav Tag: TOMCAT_5_0 index.html Log: Update dav client compat list Revision ChangesPath No revision No revision 1.1.2.2 +1 -1 jakarta-tomcat-catalina/webapps/webdav/index.html Index: index.html === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/webdav/index.html,v retrieving revision 1.1.2.1 retrieving revision 1.1.2.2 diff -u -r1.1.2.1 -r1.1.2.2 --- index.html23 Mar 2005 02:43:05 - 1.1.2.1 +++ index.html2 May 2005 22:13:50 - 1.1.2.2 @@ -37,7 +37,7 @@ liJakarta Slide 1.0 WebDAV client library/li liOffice 2000 (Windows 2000)/li liSkunkDAV 1.0/li -liXythos WebFile Client/li +liXythos Drive/li /ul pWebDAV links:/p - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Initial test of APR on Solaris
Bill Barker wrote: I was surprised that it worked at 150. I guess my crappy XP box was too slow to give real throughput :). The OOM message came from ThreadPool, which doesn't log stack traces. I'll need to hack ThreadPool to see where it's getting thrown from. The box is pretty old and small (which is why it's mostly a test-bed these days :), but the memory usage reported by 'top' wasn't that high. It's probably some other resource, since Sun throws OOM for everything. I'll see if I can find out Monday. Right, I see the error now. The issue seems to be that the APRized HTTP connector is apparently using a little more memory than the regular connector (something like 10% more). Increasing mx fixes it without further issues (on Windows). The regular HTTP produces the same stackless OOM with only a few more concurrent requests (350 starts causing some trouble for me) if using the standard JVM memory settings. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Jean-claude MAILHOT/FR/NEXANS is not at the office .
Je serai absent(e) du 12/24/2004 au 07/12/2005. From the 24 th of December to January 6, I shall be in France. I shall be back in Shanghai's office friday 7. During this period,you can call me on my mobile.I wish you a happy new year. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Initial test of APR on Solaris
- Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List tomcat-dev@jakarta.apache.org Sent: Monday, May 02, 2005 3:59 PM Subject: Re: Initial test of APR on Solaris Bill Barker wrote: I was surprised that it worked at 150. I guess my crappy XP box was too slow to give real throughput :). The OOM message came from ThreadPool, which doesn't log stack traces. I'll need to hack ThreadPool to see where it's getting thrown from. The box is pretty old and small (which is why it's mostly a test-bed these days :), but the memory usage reported by 'top' wasn't that high. It's probably some other resource, since Sun throws OOM for everything. I'll see if I can find out Monday. Right, I see the error now. The issue seems to be that the APRized HTTP connector is apparently using a little more memory than the regular connector (something like 10% more). Increasing mx fixes it without further issues (on Windows). The regular HTTP produces the same stackless OOM with only a few more concurrent requests (350 starts causing some trouble for me) if using the standard JVM memory settings. Yeah, that works for me as well. My problem now is that the APRized HTTP Connector dies about 70% of the way through a test when I use the HTTPClient option in JMeter. A thread-dump shows all of the Workers waiting, and the Poller polling, but nothing is happening. It's a bit happier when I restrict maxThreads, but it still doesn't finish. The Java HTTP Connector finishes the test fine. Not using the HTTPClient option works Ok, but the actual concurrency level is much lower. Rémy 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]
APR distro
Hi, While I'm following the performance testing with interest, I want to start thinking about packaging for 5.5.11. I imagine HttpAprConnector will be compiled and jarred with the rest of the connector stuff, so that's easy. We also add HttpAprConnector to the configuration reference, with instructions to download APR from apr.apache.org and follow its installation instructions. Is there a minimum APR version? And then there's the wrapper package. Do we include that built or in source form, and if the latter as I imagine, do we include it in the binary downloads (similar to jsvc)? I'd think so, but I'd like to iron these things out as we get closer. Yoav Shapira System Design and Management Fellow MIT Sloan School of Management / School of Engineering Cambridge, MA USA [EMAIL PROTECTED] / [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Code Submission - Wild Card Aliases
I have completed the coding in o.a.t.u.http.mapper.Mapper to implement wild-card aliases. If a request for a host is made, and that host is not found, the code tests the host and aliases list and looks for wild-cards. So, a host name of www.mydomain.com would match an alias of *.mydomain.com. This additional level of testing is only done if the the presented host name is not found in the standard host list. Once a host is found via wild-card, it is added to the standard host list. Subsequent requests for that host name will find it via the standard search mechanism. As part of the conversion, I re-worked the test harness code and expanded it to be a lot more complete. The output of the new test harness with the unmodified Mapper code matches identically the output of the modified mapper. IOW, I'm 99% confident that the behavior of the Mapper matches the old Mapper. The time differential between the two runs is around 500ms over 1 million iterations. I.E. the original code runs in 8000 ms for 1 million iterations of the testing code, while the new code takes 8500ms. The new code adds approximately 0.05 % to the time for a lookup. I am running the modified mapper code with 5.5.9 on an installation that has 40 hosts configured and it seems to be working correctly. I'd really appreciate it if a committer would get this added to the source tree. The complete modified Mapper.java file can be downloaded from: http://www.mhsoftware.com/~gsexton/Mapper.java If a decision is made to reject this patch, I'd appreciate knowing why. If there's something wrong from a coding or style perspective, I'd be happy to fix things. George Sexton MH Software, Inc. http://www.mhsoftware.com/ Voice: 303 438 9585 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Code Submission - Wild Card Aliases
Hey Geroge,
I review the mapper patch. Cool!
I think getHosts is a little bit strange:
What you think about this:
public String[] getHosts() {
Host[] hosts ;
synchronized(this) {
hosts=new Host[hmHosts.size()];
hosts=(Host[])hmHosts.values().toArray(hosts);
}
String[] hostNames=new String[hmHosts.size()];
for ( int i = 0; i hosts.length; i++ ) {
hostNames[i] = hosts[i].name;
}
return hostNames ;
}
I thing sync is needed. I miss that also at orginal mapper. The host
values get array you also coded at getContextNames().
Can we change getHost to be protected.
Have you wrote junit testcases for the Mapper ?
Please, extract the testcode. I hate those test code inside
production code :-)
I find you patch very usefull!
Thanks
Peter
George Sexton schrieb:
I have completed the coding in o.a.t.u.http.mapper.Mapper to implement
wild-card aliases.
If a request for a host is made, and that host is not found, the code tests
the host and aliases list and looks for wild-cards.
So, a host name of www.mydomain.com would match an alias of *.mydomain.com.
This additional level of testing is only done if the the presented host name
is not found in the standard host list. Once a host is found via wild-card,
it is added to the standard host list. Subsequent requests for that host
name will find it via the standard search mechanism.
As part of the conversion, I re-worked the test harness code and expanded it
to be a lot more complete. The output of the new test harness with the
unmodified Mapper code matches identically the output of the modified
mapper. IOW, I'm 99% confident that the behavior of the Mapper matches the
old Mapper.
The time differential between the two runs is around 500ms over 1 million
iterations. I.E. the original code runs in 8000 ms for 1 million iterations
of the testing code, while the new code takes 8500ms. The new code adds
approximately 0.05 % to the time for a lookup.
I am running the modified mapper code with 5.5.9 on an installation that has
40 hosts configured and it seems to be working correctly.
I'd really appreciate it if a committer would get this added to the source
tree.
The complete modified Mapper.java file can be downloaded from:
http://www.mhsoftware.com/~gsexton/Mapper.java
If a decision is made to reject this patch, I'd appreciate knowing why. If
there's something wrong from a coding or style perspective, I'd be happy to
fix things.
George Sexton
MH Software, Inc.
http://www.mhsoftware.com/
Voice: 303 438 9585
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] - benchmark on APR stuff
Hey Peter, I have download and install Jmeter 2.0.3 and want load your testplans, but I got this error: 2005/05/03 06:45:43 INFO - jmeter.gui.action.Load: Loading file: D:\peterlintestplan\concurrent_1.jmx 2005/05/03 06:45:43 ERROR - jmeter.save.SaveService: Problem loading part of file org.apache.avalon.framework.configuration.ConfigurationException: No attribute named class is associated with the configuration element testelement at - at org.apache.avalon.framework.configuration.DefaultConfiguration.getAttribute(DefaultConfiguration.java:279) at org.apache.jmeter.save.SaveService.createTestElement(SaveService.java:960) at org.apache.jmeter.save.SaveService.generateNode(SaveService.java:1137) at org.apache.jmeter.save.SaveService.loadSubTree(SaveService.java:933) at org.apache.jmeter.gui.action.Load.doAction(Load.java:97) at org.apache.jmeter.gui.action.ActionRouter.performAction(ActionRouter.java:81) at org.apache.jmeter.gui.action.ActionRouter.access$000(ActionRouter.java:44) at org.apache.jmeter.gui.action.ActionRouter$1.run(ActionRouter.java:62) at java.awt.event.InvocationEvent.dispatch(Unknown Source) at java.awt.EventQueue.dispatchEvent(Unknown Source) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(Unknown Source) at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source) at java.awt.EventDispatchThread.pumpEvents(Unknown Source) at java.awt.EventDispatchThread.pumpEvents(Unknown Source) at java.awt.EventDispatchThread.run(Unknown Source) What I made wrong? Peter Peter Lin schrieb: I haven't been able to run the benchmarks so far due to BSOD on my laptop. I suspect SP2, since I just installed it friday and now I get IRQ errors related to the network interface. the test plan is in my apache directory, can someone else run the benchmarks until I figure out how to fix this stupid BSOD nightmare? http://cvs.apache.org/~woolfel/native_testplans.zip peter lin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Code Submission - Wild Card Aliases
Peter,
I have no feeling one way or the other on synchronizing the getHosts() call.
Since there was very little synchronization in the original code, I didn't
do any in the new code.
I have never used junit, so I'm not sure I'm a good candidate for putting
the test harness code into it. Sorry...
George Sexton
MH Software, Inc.
http://www.mhsoftware.com/
Voice: 303 438 9585
-Original Message-
From: Peter Rossbach [mailto:[EMAIL PROTECTED]
Sent: Monday, May 02, 2005 10:28 PM
To: Tomcat Developers List
Subject: Re: Code Submission - Wild Card Aliases
Hey Geroge,
I review the mapper patch. Cool!
I think getHosts is a little bit strange:
What you think about this:
public String[] getHosts() {
Host[] hosts ;
synchronized(this) {
hosts=new Host[hmHosts.size()];
hosts=(Host[])hmHosts.values().toArray(hosts);
}
String[] hostNames=new String[hmHosts.size()];
for ( int i = 0; i hosts.length; i++ ) {
hostNames[i] = hosts[i].name;
}
return hostNames ;
}
I thing sync is needed. I miss that also at orginal mapper. The host
values get array you also coded at getContextNames().
Can we change getHost to be protected.
Have you wrote junit testcases for the Mapper ?
Please, extract the testcode. I hate those test code inside
production code :-)
I find you patch very usefull!
Thanks
Peter
George Sexton schrieb:
I have completed the coding in o.a.t.u.http.mapper.Mapper to
implement
wild-card aliases.
If a request for a host is made, and that host is not found,
the code tests
the host and aliases list and looks for wild-cards.
So, a host name of www.mydomain.com would match an alias of
*.mydomain.com.
This additional level of testing is only done if the the
presented host name
is not found in the standard host list. Once a host is found
via wild-card,
it is added to the standard host list. Subsequent requests
for that host
name will find it via the standard search mechanism.
As part of the conversion, I re-worked the test harness code
and expanded it
to be a lot more complete. The output of the new test
harness with the
unmodified Mapper code matches identically the output of the modified
mapper. IOW, I'm 99% confident that the behavior of the
Mapper matches the
old Mapper.
The time differential between the two runs is around 500ms
over 1 million
iterations. I.E. the original code runs in 8000 ms for 1
million iterations
of the testing code, while the new code takes 8500ms. The
new code adds
approximately 0.05 % to the time for a lookup.
I am running the modified mapper code with 5.5.9 on an
installation that has
40 hosts configured and it seems to be working correctly.
I'd really appreciate it if a committer would get this added
to the source
tree.
The complete modified Mapper.java file can be downloaded from:
http://www.mhsoftware.com/~gsexton/Mapper.java
If a decision is made to reject this patch, I'd appreciate
knowing why. If
there's something wrong from a coding or style perspective,
I'd be happy to
fix things.
George Sexton
MH Software, Inc.
http://www.mhsoftware.com/
Voice: 303 438 9585
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] - benchmark on APR stuff
Peter Rossbach wrote: Hey Peter, I have download and install Jmeter 2.0.3 and want load your testplans, but I got this error: 2005/05/03 06:45:43 INFO - jmeter.gui.action.Load: Loading file: D:\peterlintestplan\concurrent_1.jmx 2005/05/03 06:45:43 ERROR - jmeter.save.SaveService: Problem loading part of file org.apache.avalon.framework.configuration.ConfigurationException: No attribute named class is associated with the configuration element testelement at - [snip] What I made wrong? Apparently JMeter 2.0.3 is too old. :) I downloaded and built JMeter from CVS head, and that allowed me to load and run his test plans. Cheers. -- Jason Brittain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
