Re: Need an option to severe socket connections between mod_jk and ajp connector after request/response cycle.
Please witch over to tomcat-user for discussion. This is not really a developer issue. === My previous comments (bugzilla) === First hints from my side: reduce to equal number of apache and tomcat instances, configure F5 with rule that sends URLs with session cookie or jsessionid in URL to the correct apache. Furthermore configure mod_jk, such that each apache sends requests without sessions to it's preferred tomcat partner. That way almost all apache processes will connect to only one tomcat. If you still need 16K apache processes per instance you are in trouble (maybe upgrade to apache 2), if you manage to handle the workload with 1K apache processes, 1K Threads in Tomcat should be OK. === Additional comments === If you don't want to reuse the connections between apache and tomcat (last ressort solution) switch over to connectors of type ajp12 (they will close the connection after each request-response cycle) or set cachesize to 0 which will use ajp13 protocol, but I think it will close connections after each request too. I hope you don't use HTTP keep alive? Also: I vaguely remember there was an experimental connector/thread pool implementation with asynchroneous features. It might be, that this implementation does not need one fixed thread for each apache connection and I think it is beeing shipped with 5.5.x, but not enabled on default. Concerning this topic tomcat-dev might be the right place to ask. Rainer Remy Gendron wrote: Hi all, Here's the situation as it stands today and what can be done to solve it. I'll try to keep this short. Running configuration: * Running on Linux Red-Hat Ent 3 * 1 X F5 load balancer and hardware SSL box. * 5 X Apache 1.3.33/mod_jk 1.2.14 * 6 X JBoss 4.0.0/Tomcat 5.0.28 using the AJP13 connector. * Oracle 9i Our production environment hosts a number of applications, each with different load and usage patterns. Our problem comes from the fact that it is difficult to find a web farm configuration that will satisfy every application. For reasons I will not explain here, we cannot have a dedicated web farm for each application. This is what we think is happening in our production environment based on tests ran in UAT (User Acceptance Tests) and literature from the Apache and Tomcat products. This is all pretty new to us so if someone can provide hard facts, you are more than welcome. 1. The 1.3 generation of Apache web servers will spawn a child process to handle an HTTP request. Only one HTTP request at a time can be processed by that child. 2. As the load increases on the web server, additional child processes will be spawned to concurrently serve the requests. There is a default limit to how many child processes can be forked. That limit defaults to 256 but has been changed in production to 16384. This is the MaxClients directive. It seems that production really needs the 16384 value instead of the 256 default. With 256, our web servers were rejecting connections and could not support the load generated by all of our clients. 3. To prevent latency, Apache will maintain a maximum of 100 spare child processes alive. Spare means that they are not serving requests. Once reached, that number of spare servers does not seem to decrease. This is the number we see in our tests in UAT where 201 threads remain active in Tomcat. This is the 100 spare children connections * 2 web server plus accept() thread. 4. If a request needs to be forwarded to Tomcat/JBoss (dynamic pages), the child process mod_jk module will instantiate a socket connection to the ajp13 connector in Tomcat. 5. Tomcat will accept the connection and create a thread to serve it. Connections will be accepted up to a concurrent maximum of 1200. This upper value has been set by us. 6. Tomcat will reject connections when the maximum is reached. JBoss 4.0.0 has a known issue where the server will die when the maximum is reached. This has been fixed in 4.0.2. 7. A connection could potentially be recycled in mod_jk (recycle_timeout) if no activity occurs thru the connection. However, any requests to Tomcat from any user session-bound to that Tomcat instance could go thru the connection, thus keeping it active. Recycling does not seem to occur. We use a recycle_timeout value of 300. 8. The fact that the production web servers can potentially serve up to 16384 concurrent requests make it possible for a web server to instantiate an almost infinite number of connections to Tomcat and nuke it. 9. Tomcat can then become overloaded with connections. If a valid HTTP request comes thru Apache and is routed to a child process that has not yet made a connection to Tomcat, the connection could be impossible if Tomcat has already accepted its 1200 limit. 10. In that case, mod_jk could potentially fail over to another Tomcat. The user would however loose his session. 11. The recycle_timeout and cache_size options are of no use to us because too
Re: JK 1.2.15 Release plan?
I encourage you for voting 1.2.15 as stable. Mladen Turk wrote: Anyhow, I would like that we vote this (1.2.15) version as stable, because it's a bug-fix release over the 1.2.14 stable. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Releasing JK 1.2.15
Hi Peter, Mladen and all others, I would like to follow Mladens suggestion from earlier this month to create a list of precise use cases for the load balancing, failover and administrative downtime scenarios. I think from that we might end up by a better understandable overal lb design. I expect, that we will find the need for bigger changes to lb. Maybe after we know what we need to do, we can decide if we start 1.3, or if the changes with respect to functionality are still small enough to call them 1.2.16. I unfortunately didn't go deeply into Peter's bug report, because I wanted to go into it when writing up use cases. So I'm not sure, if the proposed changes are a bug fix (then it's OK for last minute 1.2.15) or maybe should better be decided together with a complete view of lb use cases (then 1.3 or 1.2.16). Rainer Hey Mladen, can we also integrate the better domain loadbalancer support at jk_lb_worker.c? I think that we don't change the lb_value inside sticky mode at every request. Can we comment out or remove lines L413-431? Thanks, Peter Mladen Turk schrieb: There has been couple of major bug fixes against 1.2.14, see: http://jakarta.apache.org/tomcat/connectors-doc/changelog.html They have been fixed in the CVS, and since couple of them actually makes 1.2.14 unusable on some platforms like Solaris 2.8 and Irix we need a release. I plan to tag the 1.2.15 by the end of this week, and pursue for a vote next week for this bug-fixing release. Any objections? Since there were no objections I plan to tag the 1.2.15 later this evening at 19:00 GMT. This will eventually be the last release from CVS, cause IIUC the transition will be made this weekend. 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Releasing JK 1.2.15
Both users tried with CVS head and the patch works for IRIX and Solaris. No objections to releasing. Hi, There has been couple of major bug fixes against 1.2.14, see: http://jakarta.apache.org/tomcat/connectors-doc/changelog.html They have been fixed in the CVS, and since couple of them actually makes 1.2.14 unusable on some platforms like Solaris 2.8 and Irix we need a release. I plan to tag the 1.2.15 by the end of this week, and pursue for a vote next week for this bug-fixing release. Any objections? 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]
Questions about MemoryUserDatabase
Hi, for the patch 36020 I had a look at MemoryUserDatabase and although the patch is already committed (Thanks!) I wanted to discuss a few things: 1) The close() for the MemoryUserDatabase is never called, especially not during shutdown of tomcat. Anyone with a good hint, where to look for adding a hook to close MemoryUserDatabase during tomcat shutdown? Where should I look for supplying a nice integration into the LifeCycle? The creation comes from org.apache.catalina.users.MemoryUserDatabaseFactory.getObjectInstance(MemoryUserDatabaseFactory.java:113) org.apache.naming.factory.ResourceFactory.getObjectInstance(ResourceFactory.java:129) javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:304) org.apache.naming.NamingContext.lookup(NamingContext.java:792) org.apache.naming.NamingContext.lookup(NamingContext.java:152) org.apache.catalina.mbeans.GlobalResourcesLifecycleListener.createMBeans(GlobalResourcesLifecycleListener.java:138) org.apache.catalina.mbeans.GlobalResourcesLifecycleListener.createMBeans(GlobalResourcesLifecycleListener.java:108) org.apache.catalina.mbeans.GlobalResourcesLifecycleListener.lifecycleEvent(GlobalResourcesLifecycleListener.java:80) org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) org.apache.catalina.core.StandardServer.start(StandardServer.java:673) 2) The new warn message is only contained in the english LocalString.properties. Anyone who could do es/fr/ja ? Original message: User database is not persistable - no write permissions on directory 3) I think, at the moment there is no documentation for UserDatabase at all. I only find docs about MemoryRealm. Where would there be a good place/page to contribute something? I would like to add information about the new property readonly? Thanks for any advice. Regards, Rainer [EMAIL PROTECTED] wrote: 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=36020. 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=36020 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-08-04 15:14 --- I applied the patch, but I changed persistable - writeable. Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Writing MemoryUserDatabase on Startup
Hi,
I wonder, why
/org/apache/catalina/users/MemoryUserDatabaseFactory.java
saves the MemoryUserDatabase directly after opening it:
public Object getObjectInstance(Object obj, Name name, Context
nameCtx, Hashtable environment) throws Exception {
...
// Return the configured database instance
database.open();
database.save();
return (database);
}
That means, the runtime user of tomcat needs write permissions on the
directory, the file is in (see the implementation of
MemoryUserDatabase.save()).
Ogf course in case one likes to administer the user database the save
function is necessary. But there are two cases where one would prefer to
have tomcat not trying to save the database during startup:
1) Running tomcat from CD
2) Having a very secure setup of tomcat, where all the configs are write
disabled.
The call to database.save() is in the code since the very first version
in TC 4, but I can't really see, why it is necessary.
Another possibility would be to catch the Exception thrown when there is
no write permission and to simply log a warning.
Also: there is a save() done in close(). I don't know, where the close
is called from, but it looks like nowhere in catalina code (eventually
in admin).
Any comments? Thanks!
Rainer
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Writing MemoryUserDatabase on Startup
Hi Remy,
so would it be OK, if I produce a patch, that cares about the Exception
and logs a message instead? I could make that configurable if you think
there is too much danger for a user to loose changes because he was able
to start tomcat and didn't notice the database was not writable.
I will propose a patch later that week and you can have a look at it.
By the way: I think Mladen also wanted such a behaviour and just now
there is a user on the users list who ran into trouble because of the
needed write permissions (not easy to understand/believe, that the file
is needed to be written during startup).
Rainer
Remy Maucherat wrote:
Rainer Jung wrote:
Hi,
I wonder, why
/org/apache/catalina/users/MemoryUserDatabaseFactory.java
saves the MemoryUserDatabase directly after opening it:
public Object getObjectInstance(Object obj, Name name, Context
nameCtx, Hashtable environment) throws Exception {
...
// Return the configured database instance
database.open();
database.save();
return (database);
}
That means, the runtime user of tomcat needs write permissions on the
directory, the file is in (see the implementation of
MemoryUserDatabase.save()).
Ogf course in case one likes to administer the user database the save
function is necessary. But there are two cases where one would prefer to
have tomcat not trying to save the database during startup:
1) Running tomcat from CD
2) Having a very secure setup of tomcat, where all the configs are write
disabled.
The call to database.save() is in the code since the very first version
in TC 4, but I can't really see, why it is necessary.
Another possibility would be to catch the Exception thrown when there is
no write permission and to simply log a warning.
Also: there is a save() done in close(). I don't know, where the close
is called from, but it looks like nowhere in catalina code (eventually
in admin).
Any comments? Thanks!
The problem is (mostly) the save in close: the database can't know for
sure if its stuff was updated so it always saves.
I understand the need for 1), which can be achieved with the other
equivalent-but-not-management-friendly memory realm. 2) seems unlikely IMO.
Rémy
-
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]
Wrong index.html on Tomcat Documentation Website
The page http://jakarta.apache.org/tomcat/tomcat-5.5-doc/index.html is missing position 23) APR in the listed User Guide menu. Any subpage includes number 23 on it's own submenu. It is also included in the 5.5.10 download, only missing on the internet top level doc page. Please add lia href=apr.html23) APR/a/li after lia href=logging.html22) Logging/a/li - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Unclear 5.0 release status
Hi, the release status of TC 5.0 is a little unclear: http://jakarta.apache.org/tomcat/tomcat-5.0-doc/status.html states: Tomcat 5.0.29 was released on October 6th, 2004. Work on the 5.0 branch is primarily for maintenance and bug fixes. It is still considered the best branch for production use, but Tomcat 5.5 is rapidly nearing a stable release. I remember, that 5.0.29 was not finally released, instead 5.0.30-beta was put on the server 6 months ago and never changed from beta to final, so http://jakarta.apache.org/site/downloads/downloads_tomcat-5.cgi still only shows 5.0.30-beta and the last non-beta version is 5.0.28. Any reasons to not formally change 5.0.30 from beta to final (apart from everyone is using his/her time for 5.5.x)? Rainer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tagging JK 1.2.9 on 3/17/2005
Hi, socket_timeout on Solaris: does very well during connect. Also no more erors/warning during build. I tested by adding microsecond timestamps to jk_log, adding some trace log messages to nb_connect and changing socket_timeout in nb_connect to millisecond resolution. Then I stressed to tomcat system and could see that: - the connect call comes back immediately (non blocking) with EINPROGRESS - the select call comes back immediately after connect or very close to the timeout given. - if I put the timeout very small (e.g. 5 milliseconds) connect fails and indeed a packet sniff shows, that the handshake was not fast enough. - with 15 milliseconds one of the three attempts succeed (motly the second one) - with a higher timeout the first attempt succeeds and the timestamp of the return of the select call nicely fits with the end of the three way tcp handshake (syn/sysn_ack/ack) from the packet sniff. - without any stress on the target system the connect alredy comes back with rc/errno=0 (success) and no select is done. Regards, Rainer Rainer Jung wrote: I could help with Solaris info. If you tell me, what you are interested in, I can do some tests. Build, socket_timeout and JkShmFile. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tagging JK 1.2.9 on 3/17/2005
Hi, I could help with Solaris info. If you tell me, what you are interested in, I can do some tests. Regards, Rainer Mladen Turk wrote: Mark Thomas wrote: I suspect that most of them are invalid/already fixed bug would be grateful if you could take a look. Hi, Yes, most are fixed. Other I simply do not understand. I'll clean up fixed and invalid, and instruct the reporters to check beta version. Some problem like Solaris one are really hard to track down without a box :) 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: Tagging JK 1.2.9 on 3/17/2005
Hi Mladen,
- Build for apache 1.3 OK (but see detailed comments).
- Running with apache 1.3 and JkShmFile: Looks OK
- jkstatus: Looks OK
- socket_timeout: Still needs to be tested (will try later)
- Logging shows mod_jk initialization two times! Once for a process A,
which does no longer exist after apache startup has finished, and a
second time the same lines for the usual parent process B. System call
trace shows, that A forks B and exits during startup. In my case, apache
is not run from the root account.
Anything else (apart from socket_timeout) I should test (test cases?)
Details:
Code from CVS HEAD today 17:00 CET.
Environment Solaris 8 UltraSparc, autoconf 2.59, automake 1.9, libtool
1.5, GNU m4 1.4.2, GNU make 3.80, gcc 3.2, Solaris ld 1.279.
CFLAGS set to -O2, CC set to gcc -specs=MY_SPECS_PATH/specs and the
specs file differs from the standard one by:
51c51
%{static|static-libgcc:-lgcc
-lgcc_eh}%{!static:%{!static-libgcc:%{!shared:%{!shared-libgcc:-lgcc
-lgcc_eh}%{shared-libgcc:-lgcc_s%M -lgcc}}%{shared:-lgcc_s%M}}}
---
%{static|static-libgcc:-lgcc
-lgcc_eh}%{!static:%{!static-libgcc:%{!shared-libgcc:-lgcc
-lgcc_eh}%{shared-libgcc:-lgcc_s%M -lgcc}}}
This is to link statically against libgcc. Otherwise the runtime system
must have libgcc_s.so, which usually is not the case for Solaris systems.
buildconf.sh warns:
configure.in:59: warning: underquoted definition of JK_CHECK_SETSOCKOPT
run info '(automake)Extending aclocal'
or see
http://sources.redhat.com/automake/automake.html#Extending%20aclocal
configure.in: installing `scripts/build/unix/install-sh'
configure.in: installing `scripts/build/unix/missing'
The underquoted warning means, that future versions of automake might
require line 59 to include additional brackets:
AC_DEFUN([JK_CHECK_SETSOCKOPT], [
./configure --with-apxs=MY_APXS_PATH/apxs
Nothing special.
make: Warning:
libtool: install: warning: remember to run `libtool --finish SOME_PATH'
libtool: install: warning: remember to run `libtool --finish SOME_PATH'
but inspection of libtools show, that --finish would not do anything in
our case.
Copied apache-1.3/mod_jk.so.0.0.0 to libexec/mod_jk.so.
Configured apache:
LoadModule jk_module libexec/mod_jk.so
AddModule mod_jk.c
JkWorkersFile /SOME_PATH/conf/workers.properties
JkShmFile /SOME_PATH/logs/mod_jk.shm
JkLogFile /SOME_PATH/logs/mod_jk.log
JkLogLevel trace
...
# Inside virtual host
# Where to put jk logs
JkLogFile /SOME_PATH/logs/mod_jk_21000.log
JkLogLevel trace
JkMount /status status
JkMount /*.jsp balancer
Test:
lynx -cfg=/home/jung/lib/lynx.cfg http://localhost:21000/status
shows version 1.2.9 and detail info for load balancing worker and single
worker.
Regards,
Rainer
Mladen Turk wrote:
Rainer Jung wrote:
Hi,
I could help with Solaris info. If you tell me, what you are
interested in, I can do some tests.
Build, socket_timeout and JkShmFile.
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: Tagging JK 1.2.9 on 3/17/2005
Concerning socket_timeout: 1) In common/jk_connect.c there is a typo: 374 setsockopt(sock, SOL_SOCKET, SO_RCVTIMEO, 375 (const void *) tv, sizeof(tv)); 376 setsockopt(sock, SOL_SOCKET, SO_RCVTIMEO, 377 (const void *) tv, sizeof(tv)); so both setsockopts use the same option. It should be SO_SNDTIMEO in line 376. Maybe that's easy enough to change for 1.2.9. 2) The test in configure about functionality of the timeouts is broken. The test program does not compile under Solaris, because it needs -lsocket. Undefined first referenced symbol in file socket /var/tmp//ccKuhLE0.o setsockopt /var/tmp//ccKuhLE0.o ld: fatal: Symbol referencing errors. No output written to conftest collect2: ld returned 1 exit status configure:19481: $? = 1 configure: program exited with status 1 When I compile the test program with -lsocket it compiles but it exits as expected with 1. So under Solaris the two timeouts are defined in the include files, but they do not work with setsockopt. Since this doesn't change the result in the end, it might also be corrected after 1.2.9. 3) in common/jk_connect.c in method jk_is_socket_connected the second argument timeout is never used. 4) Still need to test functionality of socket_timeout under Solaris. Regards, Rainer Rainer Jung wrote: Hi, I could help with Solaris info. If you tell me, what you are interested in, I can do some tests. Build, socket_timeout and JkShmFile. 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: Tagging JK 1.2.9 on 3/17/2005
2) The test in configure about functionality of the timeouts is broken. The test program does not compile under Solaris, because it needs -lsocket. Can you provide a patch for that? How about: *** configure.in.orig Thu Mar 17 17:00:36 2005 --- configure.inThu Mar 17 21:28:29 2005 *** *** 56,63 dnl check for flock function. AC_CHECK_FUNC(flock, AC_DEFINE(HAVE_FLOCK,1,[Have flock()])) ! AC_DEFUN(JK_CHECK_SETSOCKOPT, [ AC_MSG_CHECKING(whether to use $1 with setsockopt()) AC_TRY_RUN([ #include sys/types.h #include sys/socket.h --- 56,65 dnl check for flock function. AC_CHECK_FUNC(flock, AC_DEFINE(HAVE_FLOCK,1,[Have flock()])) ! AC_DEFUN([JK_CHECK_SETSOCKOPT], [ AC_MSG_CHECKING(whether to use $1 with setsockopt()) + saved_LIBS=$LIBS + LIBS=$saved_LIBS -lsocket AC_TRY_RUN([ #include sys/types.h #include sys/socket.h *** *** 88,93 --- 90,96 , [ AC_MSG_RESULT([yes]) AC_DEFINE(USE_$1, 1, [Define to use $1 with setsockopt()]) ] , [ AC_MSG_RESULT([no]) ] ) + LIBS=$saved_LIBS ])dnl dnl check for SO_RCVTIMEO and SO_SNDTIMEO Since it's only changed line and three added I did not use local CVS to make diff -u and I hope this context diff suffices. That way the test runs smoothly, of course with the same negative but clean result: configure:19433: checking whether to use SO_RCVTIMEO with setsockopt() configure:19480: gcc -specs=/usr/local/apautobuild/specs -o conftest -O2 conftest.c -lsocket 5 configure:19483: $? = 0 configure:19485: ./conftest configure:19488: $? = 1 configure: program exited with status 1 Regards, Rainer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk release policy - was: JK 1.2.9-dev test results
So I don't see the point of forking 1.3. Both config and core features are the same. Of course some advanced configuration properties where changes, lot new added, but from the outside its still old mod_jk. OK, understood from below. I agree concerning JNI deprecation. But read comments about local_worker. Regarding locality, you mean local_worker and local_worker_only flags? IMHO that was one of the fuzziest things about jk that no one ever understood, not to mention that this never worked actually. You are totally right about the bad documentation (at least concerning the status before you gave it a refresh). But I have the feeling that more people where using it like me, by studying the code (at least it's open source) and learning the functionality from there. So local_worker is a feature, that I assume is being useful and used. So locality is not deprecated. Quite opposite, now it works, just the local_worker_only is changed to sticky_session_force. IMHO this is more clearer and descriptive directive then previous one. My understanding of the use case: the term local_worker historically most likely comes from the idea, that if you use multiple systems each with apache and tomcat on them, then a call from an apache to the tomcat on the same system would be faster then going to a remote tomcat. local_worker should have indicated to prefer this (until 1.2.6 only one worker would work as a local_worker) worker unless a request carries a session id and stickyness is on or the local_worker is in error state. A more general better term would have been preferred_worker or just preferred and that's the way it is used today. At the moment there seems to be no more possibility to map a preference (I don't mean load balancing weights). Still I know cases, where it makes sense to have a distinction for requests without session id/stickyness between: - preferred (one or more) - failover for the preferred (your redirect) - maybe allowed (although the first two cases should be enough not to need more) - the rest The rest is there, because some worker may only be used, in case stickyness comes in. With stickyness and session id one would have: - sticky worker (the correct one) - failover for the preferred (your redirect) - any other in the same replication cluster (domain) - the rest (loose session but can start the app again from the beginning) Your redirect concept and my older domain patch share some use cases. On the other hand local_worker_only only makes a difference if you configure local and non-local workers in a load balancer and all local workers go into error state. With local_worker_only, all further requests will fail. Without local_worker_only the non-local workers will be used. I always had the impression that only very few - if any - people will need this kind of feature. You indicated i a separate answer, that one could use the disabled attribute instead. But I assume there is no failover to a disabled worker, whereas there should be to a non-preferred worker. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
mod_jk release policy - was: JK 1.2.9-dev test results
Hi, first: thanks a lot to Mladen for adding all the beautiful features [and removing CRLF :) ]. Big leap forward! I think that until Monday we were still in the progress of adding features, and fixing bugs. 1.2.8 changed a lot internally, but most was functionally compatible to 1.2.6. Release 1.2.9 still supported all features of 1.2.6. Now we are in the discussion of dropping features (and we even did drop some like locality support) and I have the impresssion there should be a separate discussion thread about the future of mod_jk: Do we need to reflect the incompatible changes by shifting to 1.3? By this I mean: will we still need to maintain bugs in the parallel 1.2 tree? Stated differently: Which features can be dropped without further maintenance for older releases? Usually one would deprecate by first announcing deprecation but still supporting for some time to allow migration. Then after e.g. 6 months one could drop the functionality totally. People have just been told few months ago, that mod_jk2 is no longer supported and that they should move to mod_jk. Mladen helps them by reimplementing valuable mod_jk2 features inside mod_jk, but we should not kick out long-time mod_jk users by dropping features without having a visible discussion on that item. Regards, Rainer Mladen Turk wrote: Henri Gomez wrote: Good works Mladen. I found jk a bit faster and it's good to see that we could speed it up a little. The next step could be to use larger AJP packets (4k too small) Sure ;). For 100K file the speed is the same, as expected. On large files we are measuring the network throughput not the speed of the jk itself. Anyhow what is more important then speed is the fact that endpoint cache is working as expected on threaded servers. BTW, what do you think of deprecating the JNI connector. Since it can be (theoretically) used only on windows and netware, I wonder if it make sense to continue the support. 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: [VOTE] Proposed API change to the Manager interface
I have the impression you fixed the jvmRoute in the new Session(-Id) in ManagerBase, but not in DeltaManager? Even when the context is distributable one might prefer to stick the session to the node where it now originates. Furthermore: I did not really understand the use case of emptySessionPath, but want to indicate 2 problematic areas: 1) If the cookie contains an expired session(-id) then you would allow a new session to be started with the old id. That is not a naive security problem, because the session is empty, so authentication has to be done again etc. But there is a more complex threat: Security of webapps relies on the fact, that session ids are not easily guessable. Once you move into a situation where a user might use the same session id for a very long time (in fact different sessions) the id will loose it's security. Normally it's hard to find out the id of a user session while the session is still active. And the user can at every time end his session. If he is going to use the same Id for many sessions you have a much better chance to get knowledge about the id between sessions and then to just wait for a new session to begin. 2) There might be problems by putting an arbitrary string coming from an uncontrolled Cookie and using it as a session id inside tomcat. I don't know, if there is a way related to cross site scrpting or injection of malicious code for cookies (of course I know, that there is no scripting inside Cookies, but atackers are very ingenious nowadays). At least one should check the string for formal correctness (e.g. containing only letters and numbers or something similar). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Proposed API change to the Manager interface
I'm afraid that change will have negative implications: The jvmRoute is
used to enable routing decisions by balancing components. All these
components usually support routing either COOKIE-based or URI-based.
In the URI-based case it is more or less the only clean way to include
the jvmRoute in the jsessionid, since the jsessionid is standardized, so
all common balancing products know how to handle it.
But then it is pretty common to assume the jsessionid and the cookie to
have the same value. They are sort of two different ways to transport
the same session information. So most balancer providers implement the
routing decision features the same way, independant of the source of the
session string.
Splitting the jvmRoute from the session id in the cookie case will most
likely make the situation for all implementers of balancers more complex
and instable (e.g.: mod_jk).
Of course we would all profit, if some JSR would standardize the way,
distributed applications exchange routing information with the
clients/balancers. As long as that's not the case it is very likely,
that jvmRoute as a suffix of the session id has much better support from
balancer providers.
Rainer
Filip Hanik - Dev wrote:
Remy Wrote:
BTW, wouldn't it be better to set the route as a separate cookie, which
would be a lot cleaner ? Was this ever considered ?
That would have been the obvious solution, the jvmRoute must have come from a
dark basement somewhere :)
Whatever the change you decide on, I'll be happy to implement it and test it
for the cluster stuff
Filip
- Original Message -
From: Remy Maucherat [EMAIL PROTECTED]
To: Tomcat Developers List tomcat-dev@jakarta.apache.org
Sent: Monday, February 07, 2005 11:34 AM
Subject: Re: [VOTE] Proposed API change to the Manager interface
@@ -744,15 +747,17 @@
session.setValid(true);
session.setCreationTime(System.currentTimeMillis());
session.setMaxInactiveInterval(this.maxInactiveInterval);
-String sessionId = generateSessionId();
+if (sessionId == null) {
+sessionId = generateSessionId();
+}
I just noticed my patch needs something for jvmRoute handling
(basically, the session id which is recieved must be edited for the
right route). I'll fix that.
BTW, wouldn't it be better to set the route as a separate cookie, which
would be a lot cleaner ? Was this ever considered ?
Rémy
-
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: [VOTE] Proposed API change to the Manager interface
I don't fully agree: we use F5 too, but:
1) I know many commercial sites (in germany), which do not use Cookies
(privacy reasons).
2) IP based stickyness does not work very well. In many scenarios you
will only be able to correctly route most of your clients. If you rely
on exact routing, IP-based will not suffice.
3) These are the reasons why I assume, that all balancers will support
routing decisions based on the jsessionid in the URI. So they already
have to support extracting routing information from the session id string.
So using the same jessionid string in the standard cookie will work in
most (all ?) situations / for most products.
Example: mod_jk does it like that:
/* Retrieve session id from the cookie or the parameter
*/
static char *get_sessionid(jk_ws_service_t *s)
{
char *val;
val = get_path_param(s, JK_PATH_SESSION_IDENTIFIER);
if (!val) {
val = get_cookie(s, JK_SESSION_IDENTIFIER);
}
return val;
}
and after that it does no longer matter, where the info comes from.
On the other hand: what's wrong about embedding the jmvRoute as a suffix
in the session id?
Rainer
Filip Hanik - Dev wrote:
its not at all that complicated.
This is how a big5 load balancer does it.
A) it sets a cookie, and based on the cookie it load balances.
B) if a cookie is not supported, it does a calculation based on the IP address,
and stays sticky that way.
No need to exchange any info in this scenario and very straight forward, and
never goes wrong. The only time it goes wrong is for
AOL users who can change gateway between HTTP and HTTPS
Filip
- Original Message -
From: Rainer Jung [EMAIL PROTECTED]
To: Tomcat Developers List tomcat-dev@jakarta.apache.org
Sent: Tuesday, February 08, 2005 10:39 AM
Subject: Re: [VOTE] Proposed API change to the Manager interface
I'm afraid that change will have negative implications: The jvmRoute is
used to enable routing decisions by balancing components. All these
components usually support routing either COOKIE-based or URI-based.
In the URI-based case it is more or less the only clean way to include
the jvmRoute in the jsessionid, since the jsessionid is standardized, so
all common balancing products know how to handle it.
But then it is pretty common to assume the jsessionid and the cookie to
have the same value. They are sort of two different ways to transport
the same session information. So most balancer providers implement the
routing decision features the same way, independant of the source of the
session string.
Splitting the jvmRoute from the session id in the cookie case will most
likely make the situation for all implementers of balancers more complex
and instable (e.g.: mod_jk).
Of course we would all profit, if some JSR would standardize the way,
distributed applications exchange routing information with the
clients/balancers. As long as that's not the case it is very likely,
that jvmRoute as a suffix of the session id has much better support from
balancer providers.
Rainer
Filip Hanik - Dev wrote:
Remy Wrote:
BTW, wouldn't it be better to set the route as a separate cookie, which
would be a lot cleaner ? Was this ever considered ?
That would have been the obvious solution, the jvmRoute must have come from a
dark basement somewhere :)
Whatever the change you decide on, I'll be happy to implement it and test it
for the cluster stuff
Filip
- Original Message -
From: Remy Maucherat [EMAIL PROTECTED]
To: Tomcat Developers List tomcat-dev@jakarta.apache.org
Sent: Monday, February 07, 2005 11:34 AM
Subject: Re: [VOTE] Proposed API change to the Manager interface
@@ -744,15 +747,17 @@
session.setValid(true);
session.setCreationTime(System.currentTimeMillis());
session.setMaxInactiveInterval(this.maxInactiveInterval);
-String sessionId = generateSessionId();
+if (sessionId == null) {
+sessionId = generateSessionId();
+}
I just noticed my patch needs something for jvmRoute handling
(basically, the session id which is recieved must be edited for the
right route). I'll fix that.
BTW, wouldn't it be better to set the route as a separate cookie, which
would be a lot cleaner ? Was this ever considered ?
Rémy
-
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED
Re: [VOTE] Proposed API change to the Manager interface
Upgrading mod_jk would be possible (not too complicated), but I'm afraid we are going to break other products we don't control the way we do with mod_jk. mod_jk is a good example to see, why it's not unlikely that changes would be needed for other balancers. Rainer Remy Maucherat wrote: Filip Hanik - Dev wrote: its not at all that complicated. This is how a big5 load balancer does it. A) it sets a cookie, and based on the cookie it load balances. B) if a cookie is not supported, it does a calculation based on the IP address, and stays sticky that way. No need to exchange any info in this scenario and very straight forward, and never goes wrong. The only time it goes wrong is for AOL users who can change gateway between HTTP and HTTPS I don't think it's that complicated either, but it would still require an upgrade of mod_jk to work, so it's probably not an option :( Rémy - 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: [VOTE] Proposed API change to the Manager interface
Both Cluster Managers (Delta and SimpleTcpReplication) extend ManagerBase but override createSession(). Maybe Filip or Peter can check how to make them long-time compatible with your proposal? Managers extending ManagerBase should work and compile as before with no changes unless they override the createSession method. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Improving jk_uri_worker_map in mod_jk
Hi, while trying to improve parts of the mod_jk documentation I made some observations concerning mod_jk's jk/native/common/jk_uri_worker_map.c I wanted to discuss. I'm willing to provide patches but wanted to get some opinions first. I find the JkMount worker map decision code very difficult to understand and I think there is some clean up needed: 1) JkUnMount There seems to be no general rule, which JkUnMount wins the decision process vs. conflicting JkMounts. One policy could be, to let JkUnMount win in any conflicting case, except an exact match from JkMount. Using longest context match might not be the best idea, since then there is no way to just say JkUnMount /*.gif At the moment most of the time JkUnMount wins, but e.g. not if there is a longer JkMount match with multiple '*' in it. 2) Map sort For implementation it could be very helpful to sort the map not only depending on context length (as it is done now), but to sort it e.g. like: - First: positive exact Matches (Match returns immediately positive) - Second: negative Matches (maybe these sorted in ascending context length order) (Match returns immediately negative) - Third: all other positive matches sorted in descending context length order (Match returns immediatly) 3) Further there is a decision needed, which matches should be done case sensitive on Win32. At the moment matches are only done case insensitive in the case, when a suffix match is needed and the suffix starts with a '.'. Anything special about that case? 4) Repairing JkMount /Context/*/Dir: from looking at the code I have the impression that that case is buggy, but I did not yet test to prove it. 5) It's strange, that the general suffix case is handled very different from the case, where the sufix starts with a dot. Also, implementation of both suffix cases seems to be a little clumsy. It steps throught the uri to find the character, which with the suffix starts and after that compares the rest of the uri with the suffix for equality. Why not just jumping to the correct position, since we already know the length of the suffix. 6) There is some code for prevention of a security fraud coming from URLs .../secret.jsp/ or .../secret.jsp. or with a ' ' after the suffix. The code is called after no match is found. Then the uri is made more secret and a shortened decision loop is called to make another mapping decision. This fraud prevention e.g. is never called when JkUnMount matches. It also seems to be used only in case a suffix pattern is used. What's the idea behind it? Wouldn't it be more stable to beautify the URI before looping through the mapping? What about non-matches /Context//secret.jsp or /Context/./secret.jsp? Are these URIs already simplified by Apache itself? 7) Concerning the new wildcard matches using multiple * or ?: They are very useful, but they break the idea of longest context wins, because they take the whole pattern as the context, whereas the former possible patterns only used anything up to the first * as the context. It makes understanding the decisions (and correctly documenting the feature) difficult. Also we should mention, that using more than just one * has a performance penalty (since then the pattern is not split into context and suffix with relatively easy matching algorithm, but instead the URI is passed to a more general recursive wildcard matching method). Any comments? Rainer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Releasing JK1.2.7
+1 Although not being a commiter I want to support your work with an informal +1. I appreciate calling it 1.2.7-beta due to the amount of code being changed. Rainer Mladen Turk wrote: Hi, There has been lots of changes in the JK, and I'd like to tag and release 1.2.7-beta tomorrow. Any objections? Also, This release will be marked as beta, and thus not production ready. If it passes user's testing, in a week or two I plan to release 1.2.8 stable. The reason for that are couple of new things added like extensive logging, socket timeouts, new load balancer algorithm, etc... that needs 'real-world' testing. Any comments? 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: Question about new mod_jk jk_lb_worker.c
I would be pleased to use rotatelogs, but it doesn't work with mod_jk.log (at least not last time I checked). David Rees wrote: Rainer Jung wrote, On 11/14/2004 7:31 AM: 0) Any ideas on rotating the mod_jk log file? Use cronolog http://cronolog.org/ or the rotatelogs program included with Apache. -Dave - 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: Question about new mod_jk jk_lb_worker.c
Unfortunately I don't understand. Trying to combine rotatelogs with mod_jk.log in the following way (apache 1.3): JkLogFile |/home/jung/mkb/apache/bin/rotatelogs /home/jung/mkb/apache/logs/mod_jk.log 600 doesn't work. It does neither log, nor spawn a rotatelogs process. Inside apaches CustomLog rotatelogs works, but there is no obvious way to combine CustomLog with JkLogFile. Mladen Turk wrote: David Rees wrote: Rainer Jung wrote, On 11/14/2004 7:31 AM: 0) Any ideas on rotating the mod_jk log file? Use cronolog http://cronolog.org/ or the rotatelogs program included with Apache. For that (or any kind of rotatelogs) we would need to spawn the separate process that'll do the logging. The only reasonable solution is to use the 'native' logging and then use rotatelogs program. MT. - 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: Question about new mod_jk jk_lb_worker.c
Hi Mladen, 0) Any ideas on rotating the mod_jk log file? 4) Open Problem This should work now with the latest patches. Excellent! Actually I tried to understand the new principles. Using an old style paper computer I can see that the values for lb_value are periodic. But I must confirm, that I did not mathematically understand the algorithm, maybe due to being a little ill. Are the mathematically foundations behind that simple algorithm described anywhere? 1) Limiting new application sessions if load is to high. There is a problem with that. I made a implementation counting the number of busy childs/threads from scoreboard (took me entire day), but again we should count the number of connections to tomcat, cause the apache might be serving static content. Anyhow the idea is great and I'll implement it in the new mod_proxy for Apache 2.2 where we have extra slots in the scoreboard. Sad but we can not do that inside mod_jk unless we implement our own shared memory, that was prover to be bogus in jk2. Apache serving static content is not a problem according to our experience. Static content usually serves in very well under a second (depending mostly on internet speed). The idea here is to detect a problem with the application getting slow, e.g. because of backend systems not responding fast enough. In this situation we want to limit creation of new sessions. Counting the static requests doesn't really matter for us. Example: During normal operation there are 5 static requests in work and 10 dynamic ones (that take much longer to complete). When there is a problem with backend systems we will have 15 static ones, but more than 100 dynamic ones. So either counting or ommiting the static ones seems to make no big difference. You might want to take a look at the attached patch patch_overload.txt for jk/native/apache1.3/mod_jk.c version 1.52. I don't have a patch for Apache 2. The Patch places every change inside #ifdef OVERLOAD. Also there are some DEBUG-Log-Statements put inside #ifdef DEBUG which I assume can now be done more consistently with your TRACE features. Of course the best observable value would be the number of requests belonging to the same webapp. So some possible enhancement would be to count only requests with a fix URL prefix (that's not contained in the patch). 2) Multi-Cluster-Routing Can you write some use case for that and perhaps some simple algo too. What about sticky-sessions and forcing failower if we do not have session replication? Use case: Enterprise application with redundant internet connections A and B. A consists of two Apache instances A.a1 und A.a2, B of B.a1 and B.a2. Behind are 4 Tomcat A.t1, A.t2, B.t1, B.t2. A.t1 and A.t2 are clustered, B.t1 and B.t2 are clustered. mod_jk uses load balancing with sticky sessions. All Apaches can connect to any Tomcat, but A.t1 is local for A.a1, A.t2 for A.a2, B.t1 for B.a1 and B.t2 for B.a2: A.a1 A.a2 B.a1 B.a2 || X || X || X || A.t1---A.t2 B.t1---B.t2 A.t1 and A.t2 are put into the same domain A in workers.properties, B.t1 and B.t2 are put into the same domain B in workers.properties. Now if you shutdown e.g. tomcat B.t1 for service/update (or if it breaks) All apaches will know from the domain configuration, that sticky requests for B.t1 have to go to B.t2. This is important, since only on that tomcat the replicated sessions from B.t1 will exist. Without domains you have to put all the Tomcats in one cluster. But then all sessions are replicated to all tomcats. We have a production side using 3x3=9 tomcats and a cluster with 9 nodes would mean too much overhead. The implementation uses and additional worker attribute domain, and if a session has a jvmRoute, is sticky and the correct worker is in error state another worker with the same domain attribute is chosen. I have an implementation, but I have to adapt to your code changes. The patch will only concern common/jk_util.c for configuration and common/jk_lb_worker.c. I could provide the code, if you are interested. For applications using sessions but without session replication I don't see a way how to successfully fail over. Maybe I don't understand that part of your question? 3) Idle connection disconnect Use worker mpm. We just can not make maintainer thread for non-treaded mpm's like apache1.2 or prefork. I don't use a seperate thread. I implemented this feature for Apache 1.3. The principles are the following (and I can sent complete code if you are interested): a) In common/service.h in jk_worker define an additional JK_METHOD check to be implemented by the workers: /* * Check all workers on a regular basis, * even if they do not process requests. */ int (JK_METHOD *check)(jk_worker_t *w, int force, jk_logger_t *l); b) In common/jk_worker.c provide an entry point wc_check, that will call the check method for all workers in the worker_map:
Re: Question about new mod_jk jk_lb_worker.c
Forgot to attach the patch for the overload feature. It is attached now.*** mod_jk.c.1.52 Sun Nov 14 15:00:20 2004
--- mod_jk.c.1.52.overload Sun Nov 14 15:18:59 2004
***
*** 38,43
--- 38,46
#include util_script.h
#include util_date.h
#include http_conf_globals.h
+ #ifdef OVERLOAD
+ #include scoreboard.h
+ #endif /* OVERLOAD */
/*
* Jakarta (jk_) include files
***
*** 63,68
--- 66,75
#define JK_DURATION (jakarta.worker.duration)
#define JK_MAGIC_TYPE (application/x-jakarta-servlet)
#define NULL_FOR_EMPTY(x) ((x !strlen(x)) ? NULL : x)
+ #ifdef OVERLOAD
+ #define EMPTY_FOR_NULL(x) ((x) ? x : )
+ #define NEITHER_NULL_NOR_EMPTY(x) (x x[0] != '\0')
+ #endif /* OVERLOAD */
/*
* If you are not using SSL, comment out the following line. It will make
***
*** 134,139
--- 141,170
int envvars_in_use;
table *envvars;
+ #ifdef OVERLOAD
+ /*
+ * Configuration object for the mod_overload module. Parameters are
+ *
+ * overload_uri URI that triggers load check, e.g. starting
+ * URI for a new application session
+ * overload_uri_regexp URI RegExp that triggers load check, e.g.
starting
+ * URI pattern for a new application
session
+ * overload_uri_match String representation of overload_uri_match
+ * overload_max_busy_slots maximum number of busy children allowed
+ * when doing load check
+ * overload_error_page URI of the error page shown (or redirected
to),
+ * if there are too many children busy
during load check
+ * overload_is_external Flag to indicate, that overload redirect
should
+ * be done externally insted of an
internal redirect
+ */
+ char *overload_uri;
+ char *overload_uri_match;
+ regex_t *overload_uri_regexp;
+ int overload_max_busy_slots;
+ char *overload_error_page;
+ int overload_is_external;
+ #endif /* OVERLOAD */
+
server_rec *s;
} jk_server_conf_t;
***
*** 1404,1409
--- 1435,1556
return NULL;
}
+ #ifdef OVERLOAD
+ /*
+ * JkOverloadURI directive Handling
+ *
+ * Take this config parameter only, if the string is not null and not empty
+ */
+ static const char *set_overload_uri(cmd_parms *cmd,
+ void *dummy,
+ char *uri)
+ {
+ jk_server_conf_t *conf =
+ (jk_server_conf_t *)ap_get_module_config(cmd-server-module_config,
+ jk_module);
+
+ if ( NEITHER_NULL_NOR_EMPTY(uri) ) {
+ conf-overload_uri = uri;
+ }
+
+ return NULL;
+ }
+
+ /*
+ * JkOverloadURIMatch directive Handling
+ *
+ * Take this config parameter only, if the string is not null and not empty
+ */
+ static const char *set_overload_uri_match(cmd_parms *cmd,
+ void *dummy,
+ char *uri_match)
+ {
+ jk_server_conf_t *conf =
+ (jk_server_conf_t *)ap_get_module_config(cmd-server-module_config,
+ jk_module);
+
+ if ( NEITHER_NULL_NOR_EMPTY(uri_match) ) {
+ conf-overload_uri_regexp = ap_pregcomp(cmd-pool, uri_match,
REG_EXTENDED);
+ if (conf-overload_uri_regexp == NULL) {
+ ap_log_error(APLOG_MARK, APLOG_NOERRNO|APLOG_DEBUG, cmd-server,
+ Overload configure:
+ could not compile regexp %s,
+ uri_match);
+ conf-overload_uri_match = NULL;
+ conf-overload_uri_regexp = NULL;
+ } else {
+ conf-overload_uri_match = uri_match;
+ }
+ }
+
+ return NULL;
+ }
+
+ /*
+ * JkOverloadMaxBusySlots Directive Handling
+ *
+ * Take this config parameter only, if the string is not null and not empty.
+ * We just take atoi of the string, so the integer value is the initial
integer
+ * in the string
+ */
+ static const char *set_overload_max_busy_slots(cmd_parms *cmd,
+ void *dummy,
+ char *max_busy_slots)
+ {
+ jk_server_conf_t *conf =
+ (jk_server_conf_t *)ap_get_module_config(cmd-server-module_config,
+ jk_module);
+
+ if ( NEITHER_NULL_NOR_EMPTY(max_busy_slots) ) {
+ conf-overload_max_busy_slots = atoi(max_busy_slots);
+ }
+
+ return NULL;
+ }
+
+ /*
+ * JkOverloadErrorPage Directive Handling
+ *
+ * Take this config parameter only, if the string is not null and not empty.
+ */
+ static
Re: Question about new mod_jk jk_lb_worker.c
Hi Mladen, I include my original posting. Hi Mladen, great! I don't know how hard the following is to achieve, but it is the most prominent problem around mod_jk-Logging I know of: mod_jk does neither support Apaches rotatelogs nor does it have a log rotation capability on its own. If you or any other committer has an idea how to introduce rotating logfiles, that would be a major achievement. I have 3 more features I would be willing to provide. Maybe you or the other committers can comment, if they think that would be useful. All of them are already implemented for mod_jk/apache 1.3 and in production under high load. 1) Limiting new application sessions if load is to high. You can configure a start URL for your application (regexp based). If a request X matches this URL, then mod_jk checks the scoreboard how many apache requests are being processed simultaneously at that moment. There is a configurable limti, and if that limit is reached, the request X will not be sent to tomcat, but instead be answered by some configurable local static response (containing the info, that the load is to high and the user should try again later). Alternatively one can configure X to be answered by some external redirect. 2) Multi-Cluster-Routing Tomcat-Cluster does only allow session replication to all nodes in the cluster. Once you work with more than 3-4 nodes there is too much overhead and risk in replicating sessions to all nodes. We split all nodes into clustered groups. I introduced a new worker attribute domain to let get_most_suitable_worker know, to which other nodes the session gets replicated (the workers in the same domain). This enhancement has another benefit: Once mod_jk connects an apache process to a tomcat instance, the tomcat jk connector will need one thread for this connection as long as the apache process is alive. Now assume you have multiple Apaches and Tomcats. The Tomcats are clustered and mod_jk uses sticky sessions. Now you are going to shut down (maintenance) one tomcat. All Apache will start connections to all tomcats. You end up with all tomcats getting connections from all apache processes, so the number of threads needed inside the tomcats will explode. If you group the tomcats the connections normally will stay inside the groups (combine 2) with a routing load balancer to the apaches). 3) Idle connection disconnect This one also comes from the fact, that a mod_jk connection consumes one tomcat connector thread, even if its idle for a long time. The idle connection check in mod_jk only works, if the connection is going to be used. Then it is checked if it was idle for too long and probably is beeing closed and reconnected. I implemented a feature, where in configurable intervals all workers of an lb worker are checked for idle connections, even the ones which are not returned by get_most_suitable_worker. The rationale behind it is the same as in the second part of 2). 4) Open Problem I didn't check your new code, but at least before there was the problem, that a recovered worker that was offline a long time (in means of load) got all the work after recovery. Of course there was a fixed conatsnt of load added to it after recovery to compensate, but working with a constant was not really solving the problem. It looks like one should virtually add load to a worker, even during it's error time, so that it will get normal load after recovering. Thanks for any comments! Rainer Mladen Turk wrote: Rainer Jung wrote: Hi Mladen, hi everyone, i have a proposal for a slight enhancement concerning the log format of mod_jk. Maybe you could consider including it in your recently revised code. It contains only changes to jk_util.c and I attach a patch relativ to version 1.32 of the file. Hi Rainer. You are definitely on my track :) . I'm planning to add one additional log level, and clear all the log messages. 1. ERROR - fatal operations 2. WARN - problems but not fatal 3. INFO - production logging 4. DEBUG - protocol tracing 5. TRACE - function call logging 1) Include the log level of a message in the log line. 2) Include the PID of the logging process in the log file. I'd like to make a customizable log line, in the JkRequestLogFormat fashion to be able to add PID/ThreadId, level, etc... MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Mladen Turk wrote: Peter Rossbach wrote: Hello Mladen, I have see your checkin's and Rainer Jung very fine mod_jk extension concept mail. I have two questions about lb changes: a) Why you not change the lb_value value after successful recovery at service() function ? After a longer fail the recovered worker get for a long time all new sessions... OK. Will check. Seems very reasonable. See also Rainers Jung mail Can you forward that. Seems I can
mod_jk enhancement discussion
Hi Mladen, great! I don't know how hard the following is to achieve, but it is the most prominent problem around mod_jk-Logging I know of: mod_jk does neither support Apaches rotatelogs nor does it have a log rotation capability on its own. If you or any other committer has an idea how to introduce rotating logfiles, that would be a major achievement. I have 3 more features I would be willing to provide. Maybe you or the other committers can comment, if they think that would be useful. All of them are already implemented for mod_jk/apache 1.3 and in production under high load. 1) Limiting new application sessions if load is to high. You can configure a start URL for your application (regexp based). If a request X matches this URL, then mod_jk checks the scoreboard how many apache requests are being processed simultaneously at that moment. There is a configurable limti, and if that limit is reached, the request X will not be sent to tomcat, but instead be answered by some configurable local static response (containing the info, that the load is to high and the user should try again later). Alternatively one can configure X to be answered by some external redirect. 2) Multi-Cluster-Routing Tomcat-Cluster does only allow session replication to all nodes in the cluster. Once you work with more than 3-4 nodes there is too much overhead and risk in replicating sessions to all nodes. We split all nodes into clustered groups. I introduced a new worker attribute domain to let get_most_suitable_worker know, to which other nodes the session gets replicated (the workers in the same domain). This enhancement has another benefit: Once mod_jk connects an apache process to a tomcat instance, the tomcat jk connector will need one thread for this connection as long as the apache process is alive. Now assume you have multiple Apaches and Tomcats. The Tomcats are clustered and mod_jk uses sticky sessions. Now you are going to shut down (maintenance) one tomcat. All Apache will start connections to all tomcats. You end up with all tomcats getting connections from all apache processes, so the number of threads needed inside the tomcats will explode. If you group the tomcats the connections normally will stay inside the groups (combine 2) with a routing load balancer to the apaches). 3) Idle connection disconnect This one also comes from the fact, that a mod_jk connection consumes one tomcat connector thread, even if its idle for a long time. The idle connection check in mod_jk only works, if the connection is going to be used. Then it is checked if it was idle for too long and probably is beeing closed and reconnected. I implemented a feature, where in configurable intervals all workers of an lb worker are checked for idle connections, even the ones which are not returned by get_most_suitable_worker. The rationale behind it is the same as in the second part of 2). 4) Open Problem I didn't check your new code, but at least before there was the problem, that a recovered worker that was offline a long time (in means of load) got all the work after recovery. Of course there was a fixed conatsnt of load added to it after recovery to compensate, but working with a constant was not really solving the problem. It looks like one should virtually add load to a worker, even during it's error time, so that it will get normal load after recovering. Thanks for any comments! Rainer Mladen Turk wrote: Rainer Jung wrote: Hi Mladen, hi everyone, i have a proposal for a slight enhancement concerning the log format of mod_jk. Maybe you could consider including it in your recently revised code. It contains only changes to jk_util.c and I attach a patch relativ to version 1.32 of the file. Hi Rainer. You are definitely on my track :). I'm planning to add one additional log level, and clear all the log messages. 1. ERROR - fatal operations 2. WARN - problems but not fatal 3. INFO - production logging 4. DEBUG - protocol tracing 5. TRACE - function call logging 1) Include the log level of a message in the log line. 2) Include the PID of the logging process in the log file. I'd like to make a customizable log line, in the JkRequestLogFormat fashion to be able to add PID/ThreadId, level, etc... MT. - 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]
Enhancement: mod_jk-Logging
Hi Mladen, hi everyone,
i have a proposal for a slight enhancement concerning the log format of
mod_jk. Maybe you could consider including it in your recently revised
code. It contains only changes to jk_util.c and I attach a patch relativ
to version 1.32 of the file.
1) Include the log level of a message in the log line. That should be
easy and is very helpful to find relevant messages. It is pretty
standard and much more safe than relying on the fact, that most error
messages actually contain the word error in the message text.
2) Include the PID of the logging process in the log file. That helps a
lot at least for Apache 1.3, because one can also log the PID in Apaches
access log. So it is easier to relate request info from access log lines
and errors from mod_jk log lines to each other. Also it helps to
unmangle, if log lines from several parallel requests are mixed inside
mod_jk-log.
The patch is small, but since I'm not a very experienced C developer
please check. I borrowed a define for Netware for getpid() from Apache's
code. Not sure if it will work for Netware, or if configure needs to be
enhanced, if we use getpid(). It builds well on Solaris.
Thank's for considering.
*** jk_util.c Tue Jul 13 15:58:10 2004
--- jk_util.c.new Thu Aug 12 18:11:50 2004
***
*** 85,90
--- 85,98
const char * jk_log_fmt = JK_TIME_FORMAT;
+ int log_level_max = 3;
+ static const char *log_levels[] = {
+ JK_LOG_DEBUG_VERB,
+ JK_LOG_INFO_VERB,
+ JK_LOG_ERROR_VERB,
+ JK_LOG_EMERG_VERB
+ };
+
static void set_time_str(char * str, int len)
{
time_t t = time(NULL);
***
*** 250,255
--- 258,274
f++;
}
+ const char *log_level;
+ if ( level =0 level = log_level_max ) {
+ log_level=log_levels[level];
+ } else {
+ log_level=unknown;
+ }
+
+ #ifdef NETWARE
+ #define getpid() ((pid_t)GetThreadGroupID())
+ #endif
+
#ifdef USE_SPRINTF /* until we get a snprintf function */
#ifdef NETWARE
buf = (char *) malloc(HUGE_BUFFER_SIZE);
***
*** 256,268
if (NULL == buf)
return -1;
#endif
! set_time_str(buf, HUGE_BUFFER_SIZE);
! used = strlen(buf);
if(line)
used += sprintf(buf[used], [%s (%d)]: , f, line);
#else
! set_time_str(buf, HUGE_BUFFER_SIZE);
! used = strlen(buf);
if(line)
used += snprintf(buf[used], HUGE_BUFFER_SIZE, [%s (%d)]: , f,
line);
#endif
--- 275,289
if (NULL == buf)
return -1;
#endif
! set_time_str(buf, HUGE_BUFFER_SIZE);
! used = strlen(buf);
! used += sprintf(buf[used], [%s] [%ld], log_level, (long)getpid());
if(line)
used += sprintf(buf[used], [%s (%d)]: , f, line);
#else
! set_time_str(buf, HUGE_BUFFER_SIZE);
! used = strlen(buf);
! used += snprintf(buf[used], HUGE_BUFFER_SIZE, [%s] [%ld],
log_level, (long)getpid());
if(line)
used += snprintf(buf[used], HUGE_BUFFER_SIZE, [%s (%d)]: , f,
line);
#endif
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/common JkMX.java
Hi, thanks for accepting the authentication patch for the mx4j JMX adapter. Are you going to apply it to the 5.0 branch too? That would be nice. Have a nice weekend Rainer Jung - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Enhancement: mod_jk-Logging
I have a proposal for a slight enhancement concerning the log format of
mod_jk. As suggested by Henri Gomez, I sent the proposal to the
tomcat-dev list.
1) Include the log level of a message in the log line. That should be
easy and is very helpful to find relevant messages. It is a pretty
standard feature.
2) Include the PID of the logging process in the log file. That helps a
lot, because one can also log the PID in Apaches access log. So it is
easier to relate access log lines and mod_jk log lines to each other.
Also it helps to unmangle, if log lines from several parallel requests
are mixed. Of course this argumentation mainly is for apache 1.3, but
most people use mod_jk for it.
Both enhancements can be done in jk/native/common/jk_util.c.
I attach a small patch, which I also include at the end of the message.
Since I'm not an experienced C developer please
check. I borrowed a define for Netware for getpid() from Apache's code.
Not sure If it will work for Netware, or if configure needs to be
enhanced, if we use getpid(). It build well on Solaris and it is
done in the same way inside core apache.
The patch is in diff -Nru-format and is based on
jk/native/common/jk_util.c revision 1.28. I hope this is still up to date.
Thank's for considering.
Rainer Jung
--- jk_util.c Tue Jul 13 15:58:10 2004
+++ jk_util.c.new Thu Aug 12 18:11:50 2004
@@ -85,6 +85,14 @@
const char * jk_log_fmt = JK_TIME_FORMAT;
+int log_level_max = 3;
+static const char *log_levels[] = {
+JK_LOG_DEBUG_VERB,
+JK_LOG_INFO_VERB,
+JK_LOG_ERROR_VERB,
+JK_LOG_EMERG_VERB
+};
+
static void set_time_str(char * str, int len)
{
time_t t = time(NULL);
@@ -250,19 +258,32 @@
f++;
}
+const char *log_level;
+if ( level =0 level = log_level_max ) {
+log_level=log_levels[level];
+} else {
+log_level=unknown;
+}
+
+#ifdef NETWARE
+#define getpid() ((pid_t)GetThreadGroupID())
+#endif
+
#ifdef USE_SPRINTF /* until we get a snprintf function */
#ifdef NETWARE
buf = (char *) malloc(HUGE_BUFFER_SIZE);
if (NULL == buf)
return -1;
#endif
-set_time_str(buf, HUGE_BUFFER_SIZE);
-used = strlen(buf);
+set_time_str(buf, HUGE_BUFFER_SIZE);
+used = strlen(buf);
+used += sprintf(buf[used], [%s] [%ld], log_level,
(long)getpid());
if(line)
used += sprintf(buf[used], [%s (%d)]: , f, line);
#else
-set_time_str(buf, HUGE_BUFFER_SIZE);
-used = strlen(buf);
+set_time_str(buf, HUGE_BUFFER_SIZE);
+used = strlen(buf);
+used += snprintf(buf[used], HUGE_BUFFER_SIZE, [%s] [%ld],
log_level, (long)getpid());
if(line)
used += snprintf(buf[used], HUGE_BUFFER_SIZE, [%s
(%d)]: , f, line);
#endif
--- jk_util.c Tue Jul 13 15:58:10 2004
+++ jk_util.c.new Thu Aug 12 18:11:50 2004
@@ -85,6 +85,14 @@
const char * jk_log_fmt = JK_TIME_FORMAT;
+int log_level_max = 3;
+static const char *log_levels[] = {
+JK_LOG_DEBUG_VERB,
+JK_LOG_INFO_VERB,
+JK_LOG_ERROR_VERB,
+JK_LOG_EMERG_VERB
+};
+
static void set_time_str(char * str, int len)
{
time_t t = time(NULL);
@@ -250,19 +258,32 @@
f++;
}
+const char *log_level;
+if ( level =0 level = log_level_max ) {
+log_level=log_levels[level];
+} else {
+log_level=unknown;
+}
+
+#ifdef NETWARE
+#define getpid() ((pid_t)GetThreadGroupID())
+#endif
+
#ifdef USE_SPRINTF /* until we get a snprintf function */
#ifdef NETWARE
buf = (char *) malloc(HUGE_BUFFER_SIZE);
if (NULL == buf)
return -1;
#endif
-set_time_str(buf, HUGE_BUFFER_SIZE);
-used = strlen(buf);
+set_time_str(buf, HUGE_BUFFER_SIZE);
+used = strlen(buf);
+used += sprintf(buf[used], [%s] [%ld], log_level, (long)getpid());
if(line)
used += sprintf(buf[used], [%s (%d)]: , f, line);
#else
-set_time_str(buf, HUGE_BUFFER_SIZE);
-used = strlen(buf);
+set_time_str(buf, HUGE_BUFFER_SIZE);
+used = strlen(buf);
+used += snprintf(buf[used], HUGE_BUFFER_SIZE, [%s] [%ld], log_level,
(long)getpid());
if(line)
used += snprintf(buf[used], HUGE_BUFFER_SIZE, [%s (%d)]: , f, line);
#endif
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Documentation hint: getting rid of JMX HTTP adaptor errors
Hi, using TC 5.0.27 together with the jmx http adaptor coming with mx4j 2.0.1 there are still error messages and missing data in the resulting html pages. The errors disappear when using xalan 2.6.0. The release Notes for J2SDK 1.4.2_05 say, that Sun still bundles 2.4.1+. Maybe that's worth a hint either in the release notes, or in the doc, where the parameter mx.enabled in jk2.properties is explained. The error messages are: SystemId Unknown; Line #12; Column #81; Cannot add attribute name after child nodes or before an element is produced. Attribute will be ignored. produced when accessing the default page /serverbydomain (and the domain name is missing in the result page) and SystemId Unknown; Line #14; Column #80; Cannot add attribute objectname after child nodes or before an element is produced. Attribute will be ignored. SystemId Unknown; Line #14; Column #80; Cannot add attribute description after child nodes or before an element is produced. Attribute will be ignored. when accessing /mbean.xml (and objectnme and description of the mbean is mising). All error messages disappear when using xanlan 2.6.0. I checked by putting xalan.jar from the 2.6.0 distribution to the endorsed directory of tomcat. Furthermore the previously missing data now is included in the result pages. Thanks for considerung Rainer Jung - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RFE: Basic auth jmx http adapter
Hi,
I append a small patch, including the necessary features to support basic
and digest authentication for the mx4j JMX http connector.
The way the http adaptor is initialized in JkMX.java today gives no
possibility to restrict access to it. Since the JMX console is very
powerful
I included code n JkMx.java to parse 3 additional configuration options
from jk2.properties to the connector:
mx.authMode
mx.authUser
mx.authPassword
The patch is very local and simple. It is based on the newest version of
JkMX.java. Thank for considering.
Rainer Jung
% diff -w -c JkMX.java.orig JkMX.java
*** JkMX.java.orig Thu Jun 17 21:03:20 2004
--- JkMX.java Sun Aug 29 14:16:35 2004
***
*** 39,44
--- 39,47
private boolean enabled=false;
private int httpport=-1;
private String httphost=localhost;
+ private String authmode=none;
+ private String authuser=null;
+ private String authpassword=null;
private int jrmpport=-1;
private String jrmphost=localhost;
private boolean useXSLTProcessor = true;
***
*** 86,91
--- 89,118
return httphost;
}
+ public void setAuthMode(String mode) {
+ authmode=mode;
+ }
+
+ public String getAuthMode() {
+ return authmode;
+ }
+
+ public void setAuthUser(String user) {
+ authuser=user;
+ }
+
+ public String getAuthUser() {
+ return authuser;
+ }
+
+ public void setAuthPassword(String password) {
+ authpassword=password;
+ }
+
+ public String getAuthPassword() {
+ return authpassword;
+ }
+
/** Enable the MX4J JRMP internal adapter
*/
public void setJrmpPort( int i ) {
***
*** 162,167
--- 189,205
mserver.setAttribute(httpServerName, new Attribute(Host,
httphost));
mserver.setAttribute(httpServerName, new Attribute(Port, new
Integer(httpport)));
+ if( authmode!=null ( none.equals(authmode) ||
basic.equals(authmode) || digest.equals(authmode) ) )
+ mserver.setAttribute(httpServerName, new
Attribute(AuthenticationMethod, authmode));
+
+ if( authuser!=null authpassword!=null )
+ mserver.invoke(httpServerName, addAuthorization,
+ new Object[] {
+ authuser,
+ authpassword},
+ new String[] { java.lang.String, java.lang.String });
+
+
if(useXSLTProcessor) {
ObjectName processorName =
registerObject(mx4j.tools.adaptor.http.XSLTProcessor,
Http:name=XSLTProcessor);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 4.1.31 maintenance release
I think there is no clear explanation of the TC4 support situation on the tomcat web site. Maybe to be fair to users you should start by adding statements, that TC 5 is the preferred version and TC 4 is soon to be supported only for major bugs and security patches. Furthermore you could expliciteley recommend an update to TC5 for all active TC4 users. Rainer Shapira, Yoav wrote: Hola, I think we long ago agreed not to vote -1 just because you want somebody to work on a different codebase :-) It must have been long enough ago that I wasn't here ;) I don't remember it. Anyways, since is a (non-lazy) majority vote so my -1 is not a veto, just an opinion. We already had two -1's on the lazy majority vote, which is why this vote is needed. Since there are more than two more +1 than -1's, this vote will pass and 4.1.31 will happen.. I like to think that when we say something is maintained it doesn't just mean doing a release. It also means we support it on the mailing list and by checking Bugzilla periodically and addressing issues. But I guess I'm fairly alone in this opinion, so too bad ;) I respect the voting system nonetheless, I have no issues with it. The vote passes, the release will happen, no problem. I will still suggest users having problems with 4.x upgrade to 5.x, but the people who want this release so much are of course welcome to support it actively on the mailing list as well ;) Yoav This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - 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: Tomcat 5.0.28 release
We are using it also and it is very helpful. It is one of the standard product features of a container to be able to seperate container product installation from runtime instance specific files. It works very nicely with tomcat. We can even allow instance admins to extend TC by changing to an alternate catalina.properties file (classloader definitions). It's not just a question of users sharing the base installation. I have a small enhancement request: we regularly change catalina.sh to include a file setenvInstance.sh from CATALINA_BASE/bin if it exists. We do this immediately after CATALINA_TEMPDIR is set. This way all instances share the same catalina.sh and instance specific commandline flags (memory sizing, catalina.properties, ...) can be done in the instance local setenvInstance.sh without changing the product installation. Please keep the separation of product installation and runtime instance. Rainer Jung kippdata informationstechnologie George Sexton wrote: How about stopping support for that scenario? I mean drop the CATALINA_BASE versus CATALINA_HOME feature, (or set them to always equal each other, if we want to leave them in the code base), and don't allow users to share installations except by the user home directory valve. I am really against this. I use CATALINA_HOME and CATALINA_BASE. The reason that I use them is that they provide a clean way of upgrading frequently. It lets me maintain a stock Tomcat Directory, with all of my customization (conf files, etc) in a separate directory. Please don't drop this functinality. George Sexton MH Software, Inc. - Home of Connect Daily Web Calendar 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]
Enhancement: mod_jk-Logging
I have a proposal for a slight enhancement concerning the log format of
mod_jk.
1) Include the log level of a message in the log line. That should be
easy and is very helpful to find relevant messages. It is pretty standard.
2) Include the PID of the logging process in the log file. That helps a
lot, because one can also log the PID in Apaches access log. So it is
easier to relate access log lines and mod_jk log lines to each other.
Also it helps to unmangle, if log lines from several parallel requests
are mixed. Of course this argumentation mainly is for apache 1.3, but
most people use mod_jk for it.
Both enhancements can be done in jk_util.c.
I attach a small patch. Since I'm not an experienced C developer please
check. I borrowed a define for Netware for getpid() from Apache's code.
Not sure If it will work for Netware, or if configure needs to be
enhanced, if we use getpid(). It build well on Solaris.
Thank's for considering.
*** jk_util.c Tue Jul 13 15:58:10 2004
--- jk_util.c.new Thu Aug 12 18:11:50 2004
***
*** 85,90
--- 85,98
const char * jk_log_fmt = JK_TIME_FORMAT;
+ int log_level_max = 3;
+ static const char *log_levels[] = {
+ JK_LOG_DEBUG_VERB,
+ JK_LOG_INFO_VERB,
+ JK_LOG_ERROR_VERB,
+ JK_LOG_EMERG_VERB
+ };
+
static void set_time_str(char * str, int len)
{
time_t t = time(NULL);
***
*** 250,255
--- 258,274
f++;
}
+ const char *log_level;
+ if ( level =0 level = log_level_max ) {
+ log_level=log_levels[level];
+ } else {
+ log_level=unknown;
+ }
+
+ #ifdef NETWARE
+ #define getpid() ((pid_t)GetThreadGroupID())
+ #endif
+
#ifdef USE_SPRINTF /* until we get a snprintf function */
#ifdef NETWARE
buf = (char *) malloc(HUGE_BUFFER_SIZE);
***
*** 256,268
if (NULL == buf)
return -1;
#endif
! set_time_str(buf, HUGE_BUFFER_SIZE);
! used = strlen(buf);
if(line)
used += sprintf(buf[used], [%s (%d)]: , f, line);
#else
! set_time_str(buf, HUGE_BUFFER_SIZE);
! used = strlen(buf);
if(line)
used += snprintf(buf[used], HUGE_BUFFER_SIZE, [%s (%d)]: , f, line);
#endif
--- 275,289
if (NULL == buf)
return -1;
#endif
! set_time_str(buf, HUGE_BUFFER_SIZE);
! used = strlen(buf);
! used += sprintf(buf[used], [%s] [%ld], log_level, (long)getpid());
if(line)
used += sprintf(buf[used], [%s (%d)]: , f, line);
#else
! set_time_str(buf, HUGE_BUFFER_SIZE);
! used = strlen(buf);
! used += snprintf(buf[used], HUGE_BUFFER_SIZE, [%s] [%ld], log_level,
(long)getpid());
if(line)
used += snprintf(buf[used], HUGE_BUFFER_SIZE, [%s (%d)]: , f, line);
#endif
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proxy] New implementation ready for testing
Concerning session stickyness: is the following scenario possible with your mod_proxy, at least in the future? We support a critical high load application which is running in a two cell environment. We replicate via TC cluster locally inside each cell (2 TCs) but not over the boundaries of the cells (cluster would be to big and for a cell outage it would be acceptable to loose sessions). So a cell is equal to a replication domain resp. to a TC cluster. Let's say TCs with jvmRoute A1, A2, B1, B2, where A and B are the cells. Also we use session stickyness on multiple Apache/mod_jk to keep hopping of requests from primary to secondary TCs low. Any apache needs to send requests sticky to the correct TC instance. Both TC clusters provide the same webapps. Now, if TC A1 is going down for maintenance (or breaks), and apache receives a request with jvmRoute A1, it should send the request to another member of the same cluster, in this case A2 and not to B1 or B2. Could this be done with mod_proxy? I did some project patches for mod_jk to make this happen (adding an attribute domain to the balanced_workers and enhancing get_most_suitable_worker in the lb worker. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dynamic updates and Apache v2.0
Graham Leggett wrote: Ideally tomcat should be able to pass to httpd info like hey, there is a new server in the pool, and it's called foo or do me a favour, I'm being taken out of the pool, so don't send me any new requests. Config of httpd would be as simple as ProxyPass /myWebapp ajp://seedserver/myWebapp The server seedserver could then tell httpd about all the other servers in the cluster dynamically. seedserver could resolve to one machine, or more than one machine. From what I experienced I can give an analogy with BEA WebLogic: The cluster client uses a URL to contact the WLS cluster. The URL has the form protocol://server1,server2,...:port The URL supports a list of servers to avoid bootstrapping problems in case of a single server breakdown. Usually two independent nodes of the cluster are statically configured in this URL. While the client starts, it tries to contact all servers configured in the URL. The first server that answers the request replies with a list of all cluster members. Then the client connects to all cluster members. The communication of the client with the cluster members includes several obvious ways of dynamically adding or removing cluster nodes: - a heartbeat protocol, so that the client detects a defect server by missing heartbeat packets - a configurable time interval after which the client updates its cluster server list by asking one of the already known cluster servers - a clean way of noticing the client by a cluster server that is in the process of being shut down To ensure consistency, all cluster members exchange membership data, so that they have the same view of the cluster topology. Furthermore the client loads communication code from the server. The code contains important information about load balancing. So the client learns from the cluster servers, if they should be used in a round-robin, or in a weight based way, and what their weights are. Again the cluster servers share this information via replication. This setup is working well in many real world scenarios. Maybe it indicates, that it is a good idea to learn at least cluster topology and load balancing configuration from statically configured bootstrap cluster nodes. Of course some information still needs to be managed dynamically inside the cluster. But with all the JMX support in Tomcat, that seems to be a place, where that should be feasible. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
TC 5: Support for multiple Coyote JK-Pools
Am I right, that by design TC 5 only fully supports one Coyote JK pool at the moment? I enabled JMX HTTP adaptor via mx.enabled=true. Obviously org.apache.jk.common.JkMX tries to initialize the JMX HTTP adaptor not only once, but for every Coyote JK pool configured in server.xml. For the second pool I get an exception when starting tomcat (see below). When trying to stop TC, the Coyote HTTP pool is shut down correctly, and one of the two JK pools doesn't listen any more, but the second JK pool still listens and TC does not shut down. Retrying shutdown does not help, the process is still alive. Any plans (or work already done) to refactor JkMain/JkMX for 5.next? Rainer Jung Exception during start: 2004-07-26 12:37:58,929 (main) org.apache.jk.common.JkMX/ERROR: Can't load the MX4J http adapter javax.management.InstanceAlreadyExistsException: Http:name=HttpAdaptor at mx4j.server.MBeanServerImpl.register(MBeanServerImpl.java:1123) at mx4j.server.MBeanServerImpl.registerImpl(MBeanServerImpl.java:1054) at mx4j.server.MBeanServerImpl.registerMBeanImpl(MBeanServerImpl.java:1002) at mx4j.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:978) at org.apache.jk.common.JkMX.registerObject(JkMX.java:314) at org.apache.jk.common.JkMX.loadAdapter(JkMX.java:157) at org.apache.jk.common.JkMX.init(JkMX.java:268) at org.apache.jk.server.JkMain.start(JkMain.java:339) at org.apache.jk.server.JkCoyoteHandler.start(JkCoyoteHandler.java:193) at org.apache.coyote.tomcat5.CoyoteConnector.start(CoyoteConnector.java:1527) at org.apache.catalina.core.StandardService.start(StandardService.java:489) at org.apache.catalina.core.StandardServer.start(StandardServer.java:2313) at org.apache.catalina.startup.Catalina.start(Catalina.java:556) 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:324) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:284) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:422) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] JK and load-balanced POSTs
Henri Gomez wrote: Thanks to check if it works for you with the latest jk in CVS... ... and I think we expect the new 1.2.6 release soon. So either wait for the new release - or even better: send feedback on the CVS as soon as possible. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Time for JkMountExclude in jk 1.2.x ?
As I started the discussion thread on releasing mod_jk 1.2.6 a few days ago, I would also prefer to have the stable code released and not adding new features. Releasing 1.2.6 as-is would already be benefitial to many people. Henri: thank you very much for preparing the release. For post-1.2.6 releases: JkMount only gives the ability to seperate between Apache and Tomcat on the basis of: default handled by Apache and special things handled by Tomcat. Now often the situation is reversed: complete contexts (detected by URL-prefixes) should be handled by default by the web container, and only special static objects (subdirectorie or, file name suffixes) by apache. So JkMountExclude would make a lot of sense. Henri Gomez wrote: David Rees wrote: I would suggest leaving it for the next release of mod_jk, unless it is simple and there is little chance of it adding any regressions. -Dave I'm puzzled with JkMount when I have to exclude some URL. I won't do anything before release, if everybody agreed on a quick 1.2.6 release. But works should be conducted to add exclusions, may be also via Notes - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Ready for mod_jk 1.2.6 release?
Hi, the last release of mod_jk 1.2.x (1.2.5) is more than 9 months old. Since then there have been important improvements (CPing/CPong and recovery_options). Especially recovery_options is very useful in transparent administration (start/stop) of cluster nodes. The 1.2 branch is still the preferred branch for combination with apache 1.3. Is there any volunteer to make an official 1.2.6 release? I do hope so ;-) Another good argument: The documentation of the new features is already there (http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jk2/jk/workershowto.html), so no additional work and furthermore, the documentation up to now does not mention, that all these features are still not available, because 1.2.6 has never been released. Many thanks to whoever wrote that document. I worked with a cvs build under solaris for some weeks without problems, but for production purposes people need an official release. The last changes in the native jk code is more then 6 weeks old and there is no code change activity at the moment. So this might be a good point in time to release mod_jk 1.2.6. Looking forward for positive feedback Rainer Jung - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Any synchronization issues with SMP?
TC clustering uses GZIP(In|Out)putStream in replication. I don't know, if there is buffering on top. Filip? Rainer Martin Schulz wrote: OT: The following is advice to servlet developers rather than container developers. For what it's worth, just be careful when you use GZIP(In|Out)putStream, since the native code uses a mutex (for no good reason, imho), to prevent garbage collection from interfering with the array being used. Bottleneck where I didn't expect one. In particular, never place a Object(In|Out)putStream directly on top of the GZIP streams, always use a buffer stream between the two. Reason is that the object stream reads/writes in very small chunks, causing four system calls per chunk. Or else interesting things are going to happen on larger SMP systems. Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Any synchronization issues with SMP?
Hi, we know one application running on 9 systems with 4 US II CPUs each under Solaris 9. Peak request rates at 20 requests/second per system. Tomcat is 4.1.29, Java is 1.3.1_09. No symptoms like yours! You should send a signal QUIT to the jvm process during the unresponsiveness time. This is a general JVM mechanism (at least for sun JVMs). The signal writes a stack trace for each thread on STDOUT (so you should also start tomcat with redirection of STDOUT the output to some file). Beware: older JVM in rare cases stopped working after getting this signal (not expected with 1.3.1_09). In this stack dump you should be able to figure out, in which methods most of your threads stay and what the status is. Is there native code included (via JNI)? Any synchronization done in the application itself? Are you using Tomcat clustering? Which JVM? Sincerely Rainer Jung Martin Schulz wrote: Can someone confirm that Tomcat works well on busy SMP systems (e.g. Sun V1280), or whether there are problems in Tomcat. Here's what we have at our end: We are currently performance testing our application (Tomcat 4.1.30) on Solaris 9, on a V1280 system w. 8 CPUs. (SDK 1.4.2_04). Transaction rates are moderate, around 30/s. The application, after about 30-40 minutes, gets unresponsive for a little while (1-10 minutes), gets back to work (for a varying period of time, but definitely under 30 min), and then the cycle repeats. At half the transaction rate, the smptoms are no longer easily observed,. The above symptoms disappear when we use a single CPU, or a single board of 4 CPUs. That scenario seems to imply synchronization problems soemwhere in the Java code. The problem could not be observed in development configurations either (Wintel, 1-CPU Sun boxes.) The behavior is such that connections get accepted, but no response is sent (established connections remain at a fixed level). The number of connections in this state varies (20-70). From the timers we keep we learn that the service gets stuck when reading the input. Once unblocked the responses get sent out rapidly again. We have tuned the system for efficient, high-volume TCP-IP traffic. We tried the coyote connector and the HttpConnector, both with the same effect. Please respond if you can confirm or dismiss threading issues in Tomcat. We would also be ineterested in testing approaches for such a scenario. .I have kept system statistics for both scenarios and can provide these on request. Thanks! Martin Schulz - 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]
TC Cluster: does SmartQueue fit into DeltaManager
Hi, I opened Bug 28161 last week. I found out yesterday, that the problem comes from using the SmartQueue together with DeltaManager and asynchronous replication (see Bug-Report for details). What are the plans now? If I knew, that a fix will take several days I might substitute the SmartQueue by an improvised FIFO to proceed with further tests on our application. Any comments are welcome, especially your opinion on the problem and on what to expect technically and with respect to time frame from a fix. Thank you for the important and very good work you all do on Tomcat. Sincerely Rainer Jung kippdata informationstechnologie - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Ever increasing heap size with Tomcat 3.2.3 !!!
Hi, I know Tomcat 3.2.3 in a banking production doing heavy work with huge uptimes - no memory leaks have been found (but: OS is Solaris). The only time I thought there were memory leaks was also during stress test in two cases: 1) Having a lot of debug log output (but really a lot) 2) Using JSPs (or Servlets) creating a lot of web container sessions in tomcat Here point 2) perhaps needs further explanation: By default a JSP is embedded in a web container session. This session can be used by the developper to put data in the session, that the same user should be able to use later. Even if the developer does not use a session the pure existence of a session consumes memory. In a JSP you can set the session attribute of the page directive to false, if you don't use web container sessions. In case your stress test calls only small JSPs or servlets, which (implicitely) create sessions, you might end up creating 10s of sessions per second. Such an implicit session has a default timeout of 15 minutes, before it is freed. So it would be interesting how the memory bahaves with respect to time. A general debug strategy: simplify your setup, e.g. throw away all the backend logic in your JSPs/Servlets/helper classes. Reduce to a very simple JSP/Servlet to check, if you can really reproduce the leak in tomcat. Maybe it's in the code of some helper classes? Also if you have a possibility to try under a different platform (like Solaris) this might give an indication. You only need to put tomcat there, you can still leave IIS on Windows as the webserver. Rainer Jung At 17:31 19.12.01 , you wrote: Make sure you don't have lots of logging turned on. Tomcat logs message don't get written to the log files immediately. They go into a queue in memory and a low priority thread later flushes message from this queue to disk. If the server is really busy the log writer thread won't get to execute and messages will back up in the in-memory queue. When the load decreases the queue will be flushed and memory will be released. I've spent a fair amount of time running stress tests on Tomcat 3.2.x using JProbe and I have not seen any memory leaks. Marc Saegesser -Original Message- From: Hawkins, Keith (Keith) [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 18, 2001 11:34 AM To: [EMAIL PROTECTED]; tomcat-user Subject: Ever increasing heap size with Tomcat 3.2.3 !!! Hello, Before my manager insists that we switch to JRun, can any of the Tomcat developers help with a problem of an ever increasing heap size of the Tomcat java.exe. ?? (We are running Tomcat 3.2.3 and JRE1.3.1. and the IIS redirector) We are running a load test using LoadRunner scripts on some JSP and servlets that are running under Tomcat. The load is not all that heavy but the heap size of the Tomcat java.exe process keeps growing and growing. We modified the java command line to start with -Xmx128m to allow 128 MB of heap but we still max out after a day or so. We even modified one of our servlets to create a thread that runs Runtime.gc() every 30 seconds. The LoadRunner scripts just keep logging in the same 5 people via our authentication servlet so you would think memory use would level out at some point. Nothing we do seems to keep the heap size from growing. Are there known issues with Tomcat and heap size?? Doing a web search revealed numerous posts with people having similar problems so I believe there is a problem. The standard response these people receive is to increase the heap size via -Xmx But that seems like a band-aid rather than a real solution. That just delays the inevitable. Any insight as to how to keep the Tomcat process from grabbing more and more memory would be appreciated. Thanks, Keith -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Session problems in Apache.
Hi, which Tomcat-Version do you use? Everything before 3.2.3 has a serious bug in a pool-Utility which leads to several problem, one of them is breaking the relation between requests and responses. That one is fixed in 3.2.3, but maybe its related to your problem. You should give more technical details about your setup. Rainer Jung At 12:01 27.08.01 , you wrote: Hi. We are developing a crucial site with payment options. We need to do server side session handling a lot. We have implemented the same using JSP/Bean and default sessionobjects of the webserver. We assume that the implementation is correct. The Webserver is Apache/tomcat. But when the load increases, say beyond 100 simultaneous users, we find that part of the variables between sessions swap. We want to know what can be done. Are there any parameters to be set in the webserver??? M.S. Anand.
Some Tomcat JSP Performance Numbers
I thought it might be interesting to contribute some quickly taken JSP performance figures for tomcat. The numbers were not taken especially for the list, so the setting might look a little strange. All Measurements were short-time, typically running app. 2 minutes. I used a very simple JSP, with a page directive setting session to false, then a configurable sleep and then just writing out a stupid HTML-Page of varying length. I varied the number of simulated client threads (concurrent requests), size of JSP output, number of server CPUs an finally I put apache and tomcat on seperate servers. Configuration Apache 1.3.14, Tomcat 3.2.2-beta2, AJP13, Solaris 2.6, JDK 1.2.1_03 HTTP-client simulation on another system, simulating 100 clients (differing numbers are mentioned), 100Mbit switched Ethernet between the systems, Plattform webserver and client simulator seperate Sun E420R 4CPU/4GB, 400MHz Apache andTomcat running on the same system, last two szenarios I put them on different servers, Tuning Apache uses max 256 Processes, AJP13-Pool max 256 Threads TCP/IP close_wait_interval 30 Sec Tests variable Output Size, no Sleep Size Used BandwidthPerformance 25Bytes - 430 JSP/sec 1KB -400 JSP/sec 4KB 2MBit/16MBit 415 JSP/sec 16KB 2MBit/44MBit 310 JSP/sec variable Sleeps, 1KB Size of Output Sleep Performance 0ms 400 JSP/sec 100ms360 JSP/sec 400ms185 JSP/sec 1600ms 60 JSP/sec variable Number of Client-Threads, no Sleep, 25 Bytes Size of Output Clients Performance 200 330 JSP/sec 175 360 JSP/sec 150 380 JSP/sec 125 405 JSP/sec 100 415 JSP/sec 75 435 JSP/sec 50 380 JSP/sec 25 225 JSP/sec variable Number of CPUs, no Sleep, 25 Bytes Size of Output CPUs Performance 4 430 JSP/sec 3 395 JSP/sec 2 320 JSP/sec 1 195 JSP/sec And now two measurements with apache, tomcat and the client simulation running on three different systems of the above type: no Sleep, 25 Bytes Size of Output Clients Performance 100 530 JSP/sec 200 370 JSP/sec Again seperated, but variable Number of CPUs, no Sleep, 25 Bytes Size of Output CPUs Performance 4 500 JSP/sec 2 510 JSP/sec 1 415 JSP/sec Rainer Jung kippdata informationstechnologie GmbH Bornheimer Straße 33a D-53111 Bonn Germany Tel.: +49/0228/98549-0 Fax: +49/0228/98549-50 email: [EMAIL PROTECTED]
AJP14 Suggestion
I want to know how the developers think about adding a request id to ajp14 requests, which is then presented back in the response phase. Background: We had serious trouble in diagnosing problems with tomcat 3.2 related to bug 728 (SimplePool synchronization issue). The problem caused customers in an ecommerce application to receive responses which belonged to other requests, i.e. were meant to be seen by some other customer. This bug is fixed now, but I wonder if one could make the whole request-response handling more robust by adding an id to the request. This id should then be given back by te response, preferably during a very late phase. The requesting component could then check, if the request and response ids are the same. If furthermore the id would be part of the servlet infrastructure, then application developers could take the id and pass it on the application server etc. I know, that at the moment this is not contained in a standard or existing product, but in a situation where money is involved on the customer side, people implementing solutions with tomcat would poosibly like very much such checking possibilities. Once again: we had a hard time and were missing such a possibility a lot. In Tomcat 3.2 you can easily produce stress test situations where a request gets as response body two valied bodies concatenated, one of them belonging to another request, or some other body, or no body at all, or a corrupted one. An id would at least make sure the response belongs to the right request. In the apache 1.3 szenario, the id would have to be generated by mod_jk! Any comments? Rainer Jung kippdata informationstechnologie GmbH Bornheimer Straße 33a 53111 Bonn Tel.: 0228/98549-0 Fax: 0228/98549-50 email: [EMAIL PROTECTED]
Re: URI Rewritng using Apache/mod_ssl..the old story
As far as I understand the fix does not mean, that you get rid of jsse.jar and jnet.jar. Core Java does not include an https protocol handler, but such a thing is implicitely used in http-URL-creation inside tomcat (although that could be done easier). Java is open to add new protocol handlers. The way it works is exactly by using own or third party protocol handlers and by defining java.protocol.handler.pkgs=com.sun.net.ssl.internal.www.protocol (or to something else which knows about your own or third party protocol handlers). At that point your java application will be https enabled. The problem does not occur with http, since standard java contains an http protocol handler and the standard java.protocol.handler.pkgs knows about that one. Of course as long as you don't really want tomcat itself to talk https (e.g. the browser talks https to apache and you enable JkExtractSSL On for mod_jk, so that redirects and forwards go to a correct https-URL) you could think of supplying tomcat with basic https-URL-understanding not using the fully featured protocol handlers. On the other side, since one would like to have the ability to use https directly from tomcat you would have to prepare to use the protocol handlers any way. Rainer Jung At 08:49 30.05.01 , you wrote: I have just installed TC3.2.2 final, and URI Rewiting won't work over mod_ssl and apache. without ssl it works fine, also. I have set the TOMCAT_HOME and the JAVA_HOME... but it won't work Or isn't it fixed on TC3.2.2 ?? When I install the two external classes from jdk jsse.jar and jnet.jar in tomcat/lib and start it with an environment variable like bleow (old bug #578 walkaround) it will work. The only thing that's gone is that I don't have to patch the HttpServletResponseFacade.java file out of tomcat/lib/webserver.jar... I've indeed tested this behavior with the standard class to test the sessiontracking whoch comes with tomcat. Greetings and thanks for inconvenience, Michael plz wrote back Marc Saegesser wrote: A change very similar to what you propose for HttpServletResponseFacade.java was already made for Tomcat 3.2.2b4. There are two conditions that I know of where URL rewritting won't work. If you using AJP12 and an SSL port other than 443 then Tomcat won't be told that the connection is secure and will think that that the URL scheme is HTTP not HTTPS. HttpServletResponseFacade checks that the scheme of the URL to be encoded and the scheme of the current request are the same. To encode an HTTPS url you must be on an HTTPS request. [Note: I'm sure I really understand this requirement, but its been this way for a long time.] So the two ways I know of for URL rewriting to fail are if you using AJP12 and SSL on something other than 443 or if your encoding an HTTPS URL during an HTTP request. Are either of these true for your case? To help diagnose this, could you access the SnoopServlet that comes with Tomcat via your SSL connection and post the results. This page will indicate whether Tomcat thinks the request is secure or not, and if it thinks the URL scheme is HTTPS. Thanks, we'll get this worked out. -Original Message- From: Wolle [mailto:[EMAIL PROTECTED]] Sent: Friday, May 04, 2001 5:19 AM To: [EMAIL PROTECTED]; GOMEZ Henri Subject: Re: TC 3.2.2b4 URI Rewriting with mod_ssl Hello, sorry I just wake up ;-) Wolle wrote: GOMEZ Henri wrote: That is a known Bug ,see http://nagoya.apache.org/bugzilla/show_bug.cgi?id=578 Marc has said, that he has fixed in the current release TC3.2.2b4, but it won't work. What should I describe now ? The workaround was Fixed by costin in TC 3.3 since 01/04/22 11:56:03 so I have all these things in TC3.2.2b4, fill it be insert in TC3.2.2 final ? not fill - new sentence so I have to do all these things in TC3.2.2b4, will it be completly insert in TC3.2.2 final ? 1. install the jnet.jar and jsse.jar in the ROMCAT/lib dir. 2.set the TOMCAT_OPTS =-Djava.protocol.handler.pkgs=com.sun.net.ssl.internal.www.protocol 3. Modify the HttpServletResponseFacade.java: retrieving revision 1.6.2.3 diff -u -r1.6.2.3 HttpServletResponseFacade.java --- src/share/org/apache/tomcat/facade/HttpServletResponseFacade.java 2001/03/06 17:38:13 1.6.2.3 +++ src/share/org/apache/tomcat/facade/HttpServletResponseFacade.java 2001/03/20 13:29:41 @@ -353,10 +353,14 @@ return (false); if (!request.getServerName().equalsIgnoreCase(url.getHost())) return (false); -// Set the URL port to HTTP default if not available before comparing +// Set the URL port to protocol default if not available before comparing int urlPort = url.getPort(); if (urlPort == -1
Re: missing content-length from the header, Apache/Tomcat/AJP12 Connector spins out of control
Hi,
did you get any answers?
I would be very interested if anybody investigated your problem. If not
consider logging a bug tu bugzilla.
Rainer Jung
At 18:33 20.05.01 , you wrote:
Hi!
it will be best if I describe our configuration at first:
We are running Solaris 7, Tomcat 3.2.2 b4 (beta 4) + AJP12 Connector (Tomcat
configured with max of 500 threads), JVM: Sun 1.3.0_02 Hot Spot Native
Threads, Apache 1.3.19 (max of 1024 child processes)
We have had substantial traffic on our server (we have 7 servers load
balanced with the configuration specified above)
We found that if the incoming HTTP request has content-length missing from
the header, and the request gets channeled
via the AJP12 connector to the Tomcat and the servlet, it appears that all
subsequent request are causing AJP12 connections
to raise (All in ESTABLISHED mode) and Tomcat refuses to process any more
request , eventually eating up great deal of CPU time, we needed to do
restart and both Apache and the Tomcat to recover from this condition.
We have then decided to bypass all requests with the content-length missing
in the Ajp12ConnectionHandler.java
int contentLength =
reqA.getMimeHeaders().getIntHeader(content-length);
if (contentLength != -1) {
BufferedServletInputStream sis =
(BufferedServletInputStream)reqA.getInputStream();
sis.setLimit(contentLength);
}
+ else {
+ resA.finish();
+ socket.close();
+ return;
+ }
contextM.service( reqA, resA );
//resA.finish(); // is part of contextM !
socket.close();
} catch (Exception e) {
// XXX
// this isn't what we want, we want to log the problem somehow
System.out.println(HANDLER THREAD PROBLEM: + e);
e.printStackTrace();
}
Note that in the above socket.close() is not executed when an exception is
thrown in the service method
we are considering adding a finally clause to handle such a case: i.e
contextM.service( reqA, resA );
//resA.finish(); // is part of contextM !
- socket.close();
} catch (Exception e) {
// XXX
// this isn't what we want, we want to log the problem somehow
System.out.println(HANDLER THREAD PROBLEM: + e);
e.printStackTrace();
}
+ } finally() {
+ if (socket != null)
+ socket.close();
+ }
-
I believe that potential offending code could in the servlet application
that tries to read input stream request.getInputStream() without the
content-length
following is what the servlet code looks like:
private int readInputStream(HttpServletRequest request) {
int clientDayOfYear = 0;
try {
InputStreamReader isr=new
InputStreamReader(request.getInputStream());
BufferedReader br=new BufferedReader(isr);
clientDayOfYear = new
Integer(br.readLine().toString()).intValue();
isr.close();
isr=null;
br.close();
br=null;
} catch (IOException e) {
clientDayOfYear=0;
}
return clientDayOfYear;
}
We know that our change to the Tomcat code is temporary at best (it allows
us to go on!) I am looking for the feedback
on the quality of our code change as well as maybe to a deeper reasons why
content-length missing from the header
together with request.getInputStream() would cause Apache/AJP12 to have
connections open (All in ESTABLISHED mode) and
eventually eat up all available CPU resources
Thanks for any feedback/help!
RE: 3.2.2b3 mod_jk gets stuck in readFully
If 100 is a constraint for the pool size, it should be stated in the Tomcat User's manual, since there it is explained how to increase the pool, but no max is given. I observed Exceptions when using more than 100 threads in the pool, coming from one or two arrays which have fixed size 100 in the tomcat code. I could not reproduce these errors after I updated from 3.2 to 3.2.2 and to 3.3. Is there a reason, why I could stably use a bigger pool with these version? I put 240 concurrent requests on apache. Which was the apache version you used, when the hang problem occured? At 16:47 22.04.01 , you wrote: Two things. First, the other problem that I was seeing turned out to be an Apache problem. I switched to Apache 1.3.19 and my thread hang problems went away. That problem seemed to be a synchronization thing that occurred if requests showed up too close together. As for the thread pool stuff. By default, Tomcat 3.2.x thread pools create 10 threads. This can be changed using the min_spare_threads parameter. The pools will grow as needed up to the maximum number of threads allowed (100, by default). You can increase the maximum number of allowed threads using the max_threads parameter. See if this fixes your problem better than using SimpleTcpConnector. -Original Message- From: Pogo Com [mailto:[EMAIL PROTECTED]] Sent: Saturday, April 21, 2001 5:39 PM To: Marc Saegesser; [EMAIL PROTECTED] Subject: RE: 3.2.2b3 mod_jk gets stuck in readFully After quite a bit of struggle, I think I found out what is going on. The problem is that the default configuration of Tomcat does not have enough threads in its thread pool for the default configuration of Apache. This issue would only be apparent if many Apache children were in use. The result was that any Apache children over the number of Tomcat threads would hang waiting for Tomcat to respond to requests. Tomcat would not respond until threads became available, which could be quite a long time if Apache children were not dying off (ie, because load was increasing during the day). I was wrong about the threads being stuck in readFully. The real problem is that not enough threads existed at all (ie, the thread handling socket accept would be blocked). The simplest workaround is to change the AJP13 connector to SimpleTcpConnector rather than PoolTcpConnector in server.xml. I strongly suggest that thread pool exhaustion emit a log message, since this was quite difficult to track down. Additionally, it would be better for the default configuration to be more robust. Bill --- Marc Saegesser [EMAIL PROTECTED] wrote: I finally got some time to look at this and I think I can duplicate the problem your seeing. Hopefully, its the problem your seeing, or else we have two serious problems. __ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/
Logging Memory Leak 3.2.2-beta2
Hi! I use tomcat 3.2.2-beta2 on Solaris 2.6 with JDK 1.2.2_06 and apache 1.3.14 on a Sun E420R with 4 CPUs and 4GB Memory. If I turn on verbosityLevel INFORMATION for JASPER_LOG in server.xml I can see a big memory leak. The leak does neither show up in version 3.2 nor does it appear when I use level WARNING: Also the leak only appears when I stress test tomcat with more than 32 threads. Up to 30 Client Threads are handled without a leak, somewhere between the 32nd and 34th client thread the leak starts. After the leak appears I rapidly loose memory. If I give java as heap size 513MB and use verbose:gc I can see the heap growing in minutes and finally the Garbage collection locks up: GC[0] in 99 ms: (512Mb, 0% free) - (512Mb, 0% free) GC[0] in 106 ms: (512Mb, 0% free) - (512Mb, 0% free) GC[0] in 25 ms: (512Mb, 0% free) - (512Mb, 0% free) GC[0] in 26 ms: (512Mb, 0% free) - (512Mb, 0% free) GC[0] in 25 ms: (512Mb, 0% free) - (512Mb, 0% free) GC[0] in 27 ms: (512Mb, 0% free) - (512Mb, 0% free) GC[0] in 28 ms: (512Mb, 0% free) - (512Mb, 0% free) GC[0] in 29 ms: (512Mb, 0% free) - (512Mb, 0% free) GC[1] in 11622 ms: (512Mb, 0% free) - (512Mb, 0% free) GC[0] in 129 ms: (512Mb, 0% free) - (512Mb, 0% free) GC[0] in 99 ms: (512Mb, 0% free) - (512Mb, 0% free) GC[0] in 24 ms: (512Mb, 0% free) - (512Mb, 0% free) GC[0] in 25 ms: (512Mb, 0% free) - (512Mb, 0% free) GC[0] in 25 ms: (512Mb, 0% free) - (512Mb, 0% free) GC[0] in 22 ms: (512Mb, 0% free) - (512Mb, 0% free) GC[1] in 12220 ms: (512Mb, 0% free) - (512Mb, 0% free) GC[1] in 5479 ms: (512Mb, 0% free) - (512Mb, 0% free) GC[1] in 9866 ms: (512Mb, 0% free) - (512Mb, 0% free) GC[1] in 11792 ms: (512Mb, 0% free) - (512Mb, 0% free) GC[1] in 11695 ms: (512Mb, 0% free) - (512Mb, 0% free) GC[1] in 11869 ms: (512Mb, 0% free) - (512Mb, 0% free) GC[1] in 11572 ms: (512Mb, 0% free) - (512Mb, 0% free) Then essentially tomcat does no longer answer to requests. In my simple test-JSP I set the session attribute to false in the page directive: %@ page session="false" % html body X /body /html Any comments? Sincerely Rainer Jung kippdata informationstechnologie GmbH Bornheimer Strae 33a 53111 Bonn Tel.: 0228/98549-0 Fax: 0228/98549-50 email: [EMAIL PROTECTED]
