Re: SVN migration?
On Feb 4, 2005, at 10:29 AM, Remy Maucherat wrote: Whatever productivity is gained are over CVS will probably get eaten up by less efficient tool integration for me. Right, Ant doesn't have a svn task yet. Isn't that reason enough not to jump ship yet? -- Sandy McArthur He who dares not offend cannot be honest. - Thomas Paine smime.p7s Description: S/MIME cryptographic signature
Re: JSP changes cause web app reload in 5.5?
On Dec 14, 2004, at 11:17 AM, Allistair Crossley wrote: changes to JSPs now cause Tomcat to reload our web applications. Could be deploying the webapp from the same working directory that your IDE uses? Maybe when you think you are only saving the changed jsp you are also modifying the last mod time stamps on other files too. -- Sandy McArthur Our lives begin to end the day we become silent about things that matter. - Martin Luther King, Jr. smime.p7s Description: S/MIME cryptographic signature
Re: Questions on mod_jk, session affinity, etc
On Nov 9, 2004, at 10:00 PM, Jess Holle wrote: is there any hope/possibility/interest of trying to balance the number of active sessions per Tomcat instance (i.e. sending new requests to the instance with the fewest active sessions)? We (UF, I cannot claim to represent the tomcat devs) are happy with a simple round robin distribution for new requests. We have 8 tomcat clones for simple load balancing and given enough users it all evens out. We've gutted the existing balancing code in mod_jk because it was broken and put in our own more simple algorithm that doesn't do load factors. Hopefully the balancing code back ported from the mod_proxy efforts will do the trick and we can ditch our own stuff. Anyway, trying to be too smart in sending new requests to clones with the fewest number of sessions would probably create this weird flow where new users gravitate to the same clone as a batch of users sessions expire. Even if that isn't the case, it's in our interests to separate new sessions between clones. Typically for us the first request a user makes after login is the most cpu/time intensive because we need lookup extended info about the user and generally setup their session. -- Sandy McArthur He who dares not offend cannot be honest. - Thomas Paine smime.p7s Description: S/MIME cryptographic signature
Re: Tomcat Benchmarking / Load Testing
We, University of Florida, use Tomcat 5 for our webapps when we can. (We also use WebSphere and WebLogic when needed.) Our largest use of Tomcat is with our webmail cluster. You can find some stats for that at: http://webstats.ufl.edu/webmail.ufl.edu/ (Note: that the monthly reports are behind because of problems with analog on AIX.) Yesterday during peak usage we were handling 55 request per second: http://webstats.ufl.edu/webmail.ufl.edu/daily-2004-08-30.html#hoursum Our setup is 3 machines running Apache HTTPD with mod_jk load balancing to 4 machines running Tomcat 5. While all of those machines are beefy quad CPU boxes with between 2 to 8 gig of ram none of them are single purpose machines. Our Apache HTTPD machines serve over a hundred virtual hosts, so there are a lot of other factors which makes it hard for me to assert any performance numbers of our tomcat setup. I can say our last problems with our webmail setup stemmed from running out of simultaneous connections in apache httpd when all the students returned this past fall. The 4 boxes running tomcat is overpowered to handle any surge in usage and I haven't seen their CPU load cross 33%. On Aug 31, 2004, at 9:39 AM, Gaurav Vaish wrote: Can you please name a few? On Tue, 31 Aug 2004 08:11:50 -0500, Peter Lin [EMAIL PROTECTED] wrote: there's plenty of big sites using tomcat. They just don't say it. I know several sites getting millions of page views a day using tomcat just fine. -- Sandy McArthur Government big enough to supply everything you need is big enough to take everything you have ... The course of history shows that as a government grows, liberty decreases. -- Thomas Jefferson smime.p7s Description: S/MIME cryptographic signature
Re: [VOTE] [5.5] Release plan votes
On Aug 26, 2004, at 1:13 PM, Remy Maucherat wrote: ballot Tomcat 5.5 should use the following API set for the coding: [ ] J2SE 1.3 [X] J2SE 1.4 [ ] J2SE 5.0 /ballot As a Tomcat user I'd appreciate it if Tomcat would support the second newest JVM release at the time a new minor version number series is started. -- Sandy McArthur He who dares not offend cannot be honest. - Thomas Paine smime.p7s Description: S/MIME cryptographic signature
Re: PATCH: mod_jk get_cookie jvmroute fix
On Jul 27, 2004, at 5:26 AM, Henri Gomez wrote: Could you send a diff -Nru patch please ;) cvs didn't like the -r switch. I ran `cvs diff -Nu` from the jakarta-tomcat-connectors base directory. Sandy jk_lb_worker.c-check-jvmroute.patch Description: Binary data smime.p7s Description: S/MIME cryptographic signature
PATCH: mod_jk get_cookie jvmroute fix
Attached is a patch that fixes the get_cookie in jk_lb_worker.c taken from the CVS today. The current implementation will fail if there are two JSESSIONID cookies at different domain levels. My patch below checks a JSESSIONID value for a known jvmroute before it returns a session cookie. The logic isn't perfect but it better than the current implementation IMO. It could be made more correct if it verified the found jvmroute was at the end of the cookie's value instead of simply doing a strstr() for it. One could also argue that this changes the behavior enough that the function should be renamed as it's no longer a generic get_cookie function. That said, the current patch, altered for mod_jk 1.2.5, is currently in production for webmail.ufl.edu where it's getting 15+ requests a second. Sandy McArthur jk_lb_worker.c-check-jvmroute.patch Description: Binary data smime.p7s Description: S/MIME cryptographic signature
RFE mod_jk: cookie session tracking for load balancing with sub-domains
I'm happy with the latest change to get_cookie but there is one more problem I've found. We, UF, have a convention of putting production services at http://service.ufl.edu/ and testing beta services at http://test.service.ufl.edu/ . This causes a problem with cookie based session tracking which I partly blame on the cookie spec. The problem is the http://service.ufl.edu/ JSESSIONID cookie is made available to the http://test.service.ufl.edu/ webapp. What happens is mod_jk takes the first JSESSIONID cookie and uses that for picking the jvmroute. Since the lb clusters in our test.service setups are smaller it's not possible for all the jvmroutes from the production to map to the test jvmroutes. In this case it's random where mod_jk sends the request and users can't get past the login page since their requests aren't being sent to the right clone. What mod_jk should do is check all JSESSIONID cookies for a known jvmroute and use one that matches instead of just using the first one. (I believe I checked the source to Tomcat 5.something and it did the right thing in the case of many JSESSIONID cookies, so that part is fine.) The problem comes from the cookie spec http://wp.netscape.com/newsref/std/cookie_spec.html stating that When sending cookies to a server, all cookies with a more specific path mapping should be sent before cookies with less specific path mappings. but it's silent on the order of cookies when it comes to more specific domains. It seems Mozilla orders cookies based on the domain but IE doesn't. Sadly, most users use IE. Sandy McArthur smime.p7s Description: S/MIME cryptographic signature
Re: mod_jk 1.2.6 release ? - session tracking cookie
On Jul 20, 2004, at 5:27 AM, Henri Gomez wrote: Could you send us you workers.properties ? attached. workers.properties Description: Binary data If you feel like putting more work into this, adding 'fprintf(stderr,...)' statements should go to the Apache error_log. Where did you want me put fprint ? Let us know where you want them and we'll test that code too. Sandy McArthur smime.p7s Description: S/MIME cryptographic signature
Re: mod_jk 1.2.6 release ? - session tracking cookie
Bill, Much thanks! We've tested the fixed get_cookie back-ported to mod_jk 1.2.5 and it works well. We'll deploy that version into production tonight but I don't expect any problems. I'll let y'all know if there is. Sandy On Jul 20, 2004, at 3:17 PM, Bill Barker wrote: I see that attachments are still getting stripped from the list :). The problem is yet-another-typo. The check for a comma cookie-delimiter ends up re-setting the returned cookie value to NULL, so the lb thinks that no cookie was sent. If this attachment comes through, it's the patch for it. I'll commit it later (PST), if nobody else wants it. smime.p7s Description: S/MIME cryptographic signature
Re: mod_jk 1.2.6 release ? - session tracking cookie
On Jul 19, 2004, at 4:06 AM, Henri Gomez wrote: Sandy McArthur wrote: Thinking on it more, I think I'm full of it and I was confusing the symptoms of two problems that were happening at the same time. Disregard my comments below until I can double check myself. Sandy On Jul 15, 2004, at 6:01 PM, Sandy McArthur wrote: On Jul 15, 2004, at 3:05 AM, Henri Gomez wrote: Could you take the latest code in CVS and check to see if it solve your problem ? We took the new get_cookie() implementation from CVS and replaced the one in our mod_jk 1.2.5 package and all hell broke loose. The jvmroute of the JSESSIONID cookie weren't being respected and users coudn't do anything in our load balanced setup because they were getting new JSESSIONID cookies on each request. We reverted very quickly so I didn't get a good chance to debug it. Tomorrow we'll test mod_jk from CVS to make sure it wasn't a problem with the new get_cookie() in the 1.2.5 version. I've manually followed the new get_cookie() code and it looks right to me but I'm nervous about it for now. I'd like to know if anyone else has had success with the new get_cookie() in a load balanced setup. I'm waiting for your reply to tag and make jk 1.2.6 release. I double checked our setup and our attempt to patch mod_jk 1.2.5 with the new get_cookie implementation and found that request were *not* being forward to the right clone based on the jvmroute part of the JSESSIONID cookie. I have not had time to test a current CVS checkout of mod_jk in a load balanced setup. Sandy McArthur smime.p7s Description: S/MIME cryptographic signature
Re: mod_jk 1.2.6 release ? - session tracking cookie
On Jul 19, 2004, at 8:43 AM, Henri Gomez wrote: And since I couldn't delay the release to long, we need a quick reply, so thanks to take a look at it. We've setup a current CVS checkout of mod_jk at http://sp27en1.nerdc.ufl.edu/login.do which is load balancing to our webmail cluster. If you constantly reload the page you'll see it's setting a new JSESSIONID cookie on every request. For comparison https://webmail.ufl.edu/login.do is using mod_jk 1.2.5 load balancing to the same webmail cluster. Sandy McArthur smime.p7s Description: S/MIME cryptographic signature
Re: mod_jk 1.2.6 release ? - session tracking cookie
On Jul 15, 2004, at 3:05 AM, Henri Gomez wrote: Could you take the latest code in CVS and check to see if it solve your problem ? We took the new get_cookie() implementation from CVS and replaced the one in our mod_jk 1.2.5 package and all hell broke loose. The jvmroute of the JSESSIONID cookie weren't being respected and users coudn't do anything in our load balanced setup because they were getting new JSESSIONID cookies on each request. We reverted very quickly so I didn't get a good chance to debug it. Tomorrow we'll test mod_jk from CVS to make sure it wasn't a problem with the new get_cookie() in the 1.2.5 version. I've manually followed the new get_cookie() code and it looks right to me but I'm nervous about it for now. I'd like to know if anyone else has had success with the new get_cookie() in a load balanced setup. Sandy smime.p7s Description: S/MIME cryptographic signature
Re: mod_jk 1.2.6 release ? - session tracking cookie
Thinking on it more, I think I'm full of it and I was confusing the symptoms of two problems that were happening at the same time. Disregard my comments below until I can double check myself. Sandy On Jul 15, 2004, at 6:01 PM, Sandy McArthur wrote: On Jul 15, 2004, at 3:05 AM, Henri Gomez wrote: Could you take the latest code in CVS and check to see if it solve your problem ? We took the new get_cookie() implementation from CVS and replaced the one in our mod_jk 1.2.5 package and all hell broke loose. The jvmroute of the JSESSIONID cookie weren't being respected and users coudn't do anything in our load balanced setup because they were getting new JSESSIONID cookies on each request. We reverted very quickly so I didn't get a good chance to debug it. Tomorrow we'll test mod_jk from CVS to make sure it wasn't a problem with the new get_cookie() in the 1.2.5 version. I've manually followed the new get_cookie() code and it looks right to me but I'm nervous about it for now. I'd like to know if anyone else has had success with the new get_cookie() in a load balanced setup. Sandy smime.p7s Description: S/MIME cryptographic signature
Re: mod_jk 1.0.26 release ? - session tracking cookie
On Jul 14, 2004, at 11:17 AM, Henri Gomez wrote: jk 1.2.6 seems to be in a good shape and a release should be welcome for many users. I'd like to release jk 1.2.6 next week. Any objections ? I have one gripe with the way mod_jk chooses the session tracking cookie. I'm not a dev but I just tracked down a bug that has been causing us, University of Florida, some pain for a few weeks. I'm currently verifying that I'm not full of it before I filed a bug report but the short version is: mod_jk seems to pick the first cookie ending in JSESSIONID such as PSJSESSIONID as opposed to what the servlet spec says in section 7.1.1: The name of the session tracking cookie must be JSESSIONID. Take a look at the get_cookie function in jk_lb_worker.c and walk though it with input similar to: Cookie: PSJSESSIONID=FOOBAR; JSESSIONID=BAZZORK.jvm# Sandy smime.p7s Description: S/MIME cryptographic signature
Re: Which class stores the JNDI resources?
Been there. This has been fixed already. Use a newer release of tomcat. On Apr 30, 2004, at 1:34 PM, David wrote: Hi I've run into some problems with Tomcats JNDI storing.. Here is the situation: Running Struts 1.1, with a Spring plugin that loads a JNDI Datasource object. Resource specified itself in the default context, OR specified in GlobalResources with a resourceLink to it in the default context. What happens as I have traced is: -Tomcat loads -Resource gets loaded into the namespace WITHOUT its resource params -Tomcat loads the Struts Action Servlet from my webapp -Plugin executes and gets an empty DataSource object from the DBCP Factory -Struts Action servlet finishes executing its init -Tomcat loads the Resource into the namespace AGAIN WITH its resource params From that point forward I can get a fully populated functioning datasource. Now this will work if I specify a resource link inside a specific Context element for my webapp within server.xml, however we want to deploy our webapp via a war file so it needs to be in the default context. Can anyone point me to the class handling the saves to JNDI so I can see exactly what is happening? Or a good workaround for this? Thanks, David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Sandy McArthur PGP.sig Description: This is a digitally signed message part
Re: Many thanks to the dev team
On Apr 29, 2004, at 10:58 AM, Remy Maucherat wrote: Woohoo, cool, a happy user :D Yes, much thanks. The University of Florida is happy too. We've been migrating webapps that don't need a full J2EE stack to Tomcat 5 over the last months and have been very pleased. While we don't have the admin tools for managing a cluster like we have for WebSphere, it still requires less time and effort to keep things running smoothly. Sandy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves RequestFilterValve.java
Does this mean J2SE 1.3 support is no more? On Apr 14, 2004, at 1:45 PM, [EMAIL PROTECTED] wrote: Log: Added support for exception chaining. +iae.initCause(e); - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves RequestFilterValve.java
On Apr 14, 2004, at 4:04 PM, Jess Holle wrote: Jan Luehe wrote: Sandy McArthur wrote: Does this mean J2SE 1.3 support is no more? On Apr 14, 2004, at 1:45 PM, [EMAIL PROTECTED] wrote: \ Log: Added support for exception chaining. +iae.initCause(e); If there is a strong desire to maintain BC with J2SE 1.3, I'll resort to the JdkCompat mechanism, but both Remy and Jess voiced (strongly in the case of Jess) opinions that there was no need for it. Though I strongly feel Java 2 v1.3.1 is too old to bother with it (and that those who are still stuck back on it for some strange reason can stick with older versions of Tomcat as well), I do believe a statement that this and future versions of Tomcat shall require Java 2 v1.4 or higher should accompany the first public release after any change requiring Java 2 v1.4 for basic functionality. Personally I'd prefer to drop J2SE 1.3 support. It gives me another argument to management for See, those AIX 4.3 boxes are so old we cannot use the latest Tomcat on them because a 1.4 JVM isn't available. As a programmer/site admin/all around nice guy :) I think it would be nice if there was one more stable release that supported J2SE 1.3 that included an announcement like This is the last version that will run on J2SE 1.3. All future versions of Tomcat will require a 1.4 JVM. You have been warned. Sandy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Filter.init and JNDI resources
I just wrote a Filter that uses a JNDI provided datasource. When I try to access that datasource from the Filter.init(...) I get a exception: Caused by: javax.naming.NamingException: Cannot create resource instance at org.apache.naming.factory.ResourceEnvFactory.getObjectInstance(ResourceE nvFactory.java:146) at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java: 301) at org.apache.naming.NamingContext.lookup(NamingContext.java:838) at org.apache.naming.NamingContext.lookup(NamingContext.java:185) at org.apache.naming.NamingContext.lookup(NamingContext.java:826) at org.apache.naming.NamingContext.lookup(NamingContext.java:185) at org.apache.naming.NamingContext.lookup(NamingContext.java:826) at org.apache.naming.NamingContext.lookup(NamingContext.java:185) at org.apache.naming.NamingContext.lookup(NamingContext.java:826) at org.apache.naming.NamingContext.lookup(NamingContext.java:198) at org.apache.naming.SelectorContext.lookup(SelectorContext.java:183) at javax.naming.InitialContext.lookup(InitialContext.java:347) at net.sf.hibernate.connection.DatasourceConnectionProvider.configure(Datas ourceConnectionProvider.java:44) ... 23 more But when I put the same init code in the Filter.doFilter(...) method such that it only executes once, but delayed until the webapp has been made available I have no problems. I skimmed the servlet 2.4 spec and found nothing stating the availability of JNDI resources at the time a filter is instantiated. I tried reordering my web.xml so that the resource-env-ref came before the problematic filter to no avail. Does this sound like a bug, an ambiguous part of the Servlet spec, or am I missing something? Sandy McArthur - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Filter.init and JNDI resources
Opps, this belongs on tomcat-users, I'll take this there. Sorry. Sandy McArthur - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Custom session tracking method?
Hi all,
Is there a way to implement custom session tracking at the container
level?
I'm trying to figure out how to implement a custom session tracking
method. I have a legacy client that interacts with a set of cgi scripts
and I'd like to port those scripts to servlets. I'm running into a
problem because the client passes session ids as a query parameter
named 'session-num' (e.g.: /update?session-num=TOKEN). The client does
not support cookies and there is no way to tell it use a JSESSIONID
encoded in the path.
I've followed the code as best as I can starting at
org.apache.coyote.tomcat5.CoyoteAdapter parses the JSESSIONID from the
request/cookies to where the org.apache.catalina.Manager fetches the
org.apache.catalina.Session and I don't see anyway to directly override
the session tracking behavior.
The best idea I currently have is to use a Valve and a custom Manager
and hope none of the Manager.{create,find}Session() methods are called
before my Valve can parse the request and stuff the session-num in a
ThreadLocal that Manager can use when returning a Session.
That feels ugly and fragile to me. Does anyone have a better solution?
Sandy McArthur
PGP.sig
Description: This is a digitally signed message part
