Re: sendRedirect and absolute paths
Users questions should be posted on the users list. Please post all follow ups to the users list. See http://tomcat.apache.org/lists.html for what should be discussed on what list. You might find a configurative solution at http://tomcat.apache.org/tomcat-5.5-doc/config/http.html especially proxyName If this Connector is being used in a proxy configuration, configure this attribute to specify the server name to be returned for calls to request.getServerName(). See Proxy Support for more information. proxyPort If this Connector is being used in a proxy configuration, configure this attribute to specify the server port to be returned for calls to request.getServerPort(). See Proxy Support for more information. scheme Set this attribute to the name of the protocol you wish to have returned by calls to request.getScheme(). For example, you would set this attribute to https for an SSL Connector. The default value is http. See SSL Support for more information. Rainer Jung Tino Schwarze wrote: On Thu, Feb 16, 2006 at 03:24:52PM -0800, Casey Haakenson wrote: We have a customer who is hitting our web GUI through a fairly complicated SSH proxy scheme. For example, when they hit a page on our site such as /redirect.jsp we do a response.sendRedirect(/newpage.jsp). This results in a 302 status code and a Location header with the full URI (http://somesite.com/newpage.jsp) which is the incorrect URL since the proxy has been rewriting the URL's so far and this new one is the one that the proxy is hitting not the original one the browser thinks it's viewing. Anyway, I have tested a change to CoyoteResponse.sendRedirect:1114 (we are using 4.1.24) to send the relative absolute (/newpage.jsp) path back to the browser in the Location header. This appears to solve the problem and work in all browsers I've been able to test, but am worried that since you guys went to so much trouble making it include the protocol, hostname, port, etc that this may break some odd browser or case I'm not fully understanding at the moment. AFAIK it's against HTTP specs. Redirects have to be absolute. For example, lynx complains (redirect URL is not absolute or something alike). IMO there's only one practical solution: Tell your application which URLs will be used to access it and prepare the redirect URLs according to the request (you can evaluate X-Forwarded-Host and similar headers to get the original hostname). Bye, Tino. - 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: AW: Tomcat Connector 1.2.15 - JkOption FlushPackets-Bug
Hi Mladen, are you sure? I have the impression default is c-options = JK_OPT_FWDURIDEFAULT; and #define JK_OPT_FWDURIDEFAULTJK_OPT_FWDURICOMPAT #define JK_OPT_FWDURICOMPAT 0x0001 but needed is #define JK_OPT_FLUSHPACKETS 0x0020 It looks like JK_OPT_FLUSHPACKETS is only set when JkOption parsed. Anything I missed? Regards, Rainer Fenlason, Josh wrote: Are you sure that + is the default for the FlushPackets option? I had a similar issue where I was trying to stream data from a servlet. Once I added 'JkOptions +FlushPackets' to my mod_jk config, everything worked as expected. , Josh. -Original Message- From: Mladen Turk [mailto:[EMAIL PROTECTED] Sent: Monday, February 20, 2006 3:47 AM To: Tomcat Developers List Subject: Re: AW: Tomcat Connector 1.2.15 - JkOption FlushPackets-Bug Peter Rossbach wrote: I thing you mus set JkOptions +FlushPackets No need. Default is +. 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]
Cluster maintenance and improvement
Hi Filip, hi all developers, I think TC clustering from a users perspective got more robust in the last two years. Whe we started playing around with it in 2004 it was great, that we all basic functionality already worked, but you might remember, that I contributed a couple of fixes to make DeltaManager finally work in around 5.0.27. When we started to check robustness for mission-critical production I found some limitations, that made clustering (in our use case) a little fragile, and I'm thankful to Peter, that he included the fastasync replication mode. During early stages of 5.5 the amount of changes to cluster introduced some instability and finally broke it (the compression change), but the bugs were resolved very quickly after user feedback. At the end everyone was confident, that TC cluster was stable again starting from 5.5.15. At the moment TC 5.5 core is in maintenance mode. Commiters for core Tomcat usually only apply bug changes to 5.5, no major changes were applied to the core parts. So the release schedule for 5.5 is mainly correlated to bug fixes. Major Changes to TC cluster might result in a conflict between TC releases (bug driven) and Cluster releases (refactoring driven), at least as long as TC core and the cluster module are released together. So I would also very much appreciate a conservative refactoring and enhancement strategy for 5.5 cluster. Major changes (better: risk) should be directly done in TC 6 (which is not that far away). I agree, taht there is a lot of code refactoring necessary for the cluster as a basis for adding more and important functionality. But in the last two years the amount of people doing real production with TC cluster increased a lot. I think it would really help to have a conservatively maintained branch and one that is open for the very much needed restructuring of the code. What do you think? Regards, Rainer Filip Hanik - Dev Lists wrote: new features and new development has historically always been done against the head revision. If you want to put something into maintenance, then that becomes a branch for example VERSION | --- HEAD REV --- NEW DEVELOPMENT | | --- BRANCH --- MAINTENANCE MODULE in our case 5.5.15 | --- HEAD REV --- NEW CLUSTER DEVELOPMENT | | --- OLD CLUSTER COMPONENT BRANCH --- MAINTENANCE MODULE FOR THE WAY IT IS TODAY To calm your nerves a little bit, I don't plan to pull out the JMX, nor to make major server.xml conf changes for 5.5.x, but it is on the horizon for TC6. For 5.5.x the server.xml will remain similar to what it is today, ie, almost backwards compatible (minus the changes I already made). TC 6 will have a completely new conf. TC 5.5.x will have a TC6 style new conf enabled added for the users that want to take advantage of plugging in their own message interceptors and to do primary/secondary backup replication which I intend to have complete by 5.5.16/17 depending on when those releases get cut. The compression flag will get taken out of the protocol, replaced with a default compression interceptor is compress=true. so functionality will not change for the users either. Filip Peter Rossbach wrote: Hey Filip, what I see is you want make an innovative step. Great, I m very motivated to help that we implement a next generation. But, why do we this implementation not inside a sandbox, branch or separate module? Last year I learned that big changes are great, but it is easy to make failures at very little details, like the compress flag bug. To design a new implementation is risky. A lot of projects and people now use very succesfull the current tomcat 5.5.15 cluster. Some people are waiting that we release the cross context replication to support portal development. Please, I do not want to stop the innovation, but why do we not start the new cluster design at a separate module and set the current code base at maintaince mode? Peter Roßbach Am 23.02.2006 um 12:59 schrieb Filip Hanik - Dev Lists: Peter Rossbach wrote: I have add the compress flag inside the protocol. It is usefull to send message with an without compression. For short messages it is not usefull to compress, it is an overhead. There is no question whether compression is useful or not. The compression flag should have never been added in the protocol in the first place, Compression can and should be done on a higher level, and the algorithm should be pluggable. Adding it to the protocol is like adding a compression flag to a TCP frame, and its a hack, And it caused 4 stable releases of tomcat to be broken. The flag should have been a flag in the payload, configurable by the component requesting to send the data as that component is suitable for making that decision compression will still be configurable on a per message basis, but with a different design. Before 5.5.15 you made a vote that we carefull with protocol changes, I didn't make a
Re: Cluster maintenance and improvement
Hi Filip, thanks for taking it seriously! 1. If we don't primary/secondary will not be available until TC.6 3. Many people are opting out of clustering today because of lack of primary/sec. all-to-all is too inefficient for the general public I understand your primary motivation. It#s true, primary/secondary would be a major improvement. There is one feature that exists now and was not available in 2004, that relaxes some of the all-to-all problems. We donated enhancements to mod_jk which were taken up by Mladen Turk: the domain attribute for a worker. So what is already possible today, is a static grouping of cluster nodes into domains. From the tomcat perspective that means, you configure multiple disjoint clusters. From the mod_jk perspective this means, that you sessions will always be routed to a node inside the same tomcat cluster (domain in mod_jk notation), and only if all nodes in the domain are in error state, the requests are routed to some node who does not have the session. In some way it is a very basic static promary/secondary feature and it only works in conjunction with mod_jk. This is very bare bone, but I know several people who build their 4 to 9 cluster nodes on top of that construction. In fact, susually they had their nodes segmented in network terms in smaller groups anyhow, so breaking up the cluster into domains fitted their needs well. Of course, having a dynamic and more transparent primary/secondary construction is much more useful. I just want to indicate, why I know serveral users, who could work successfully with all-to-all, restricted to domains. 2. TC 6 doesn't have a skeleton nor a date yet. 5. The instability caused in 5.5.10-5.5.14 could have easily been detected and should have not lasted for four releases. I doubt we should see that again. 6. I'm ready and have the time and commitment to support any changes I make. I am happy to have a 5.5.15-cluster branch for bug fixes This way when 5.5.16 comes out, the users can choose which one to use. To delay this out of plain fear of breaking doesn't seem reasonable to me, if the code base is so messed up that we are too afraid to touch it, then it needs to be fixed sooner than later. I'm very happy about your commitment - really! We really need to push the clustering forward and it's fantastic to have you back! I like your idea of a 5.5.15 maintenance branch. But I'm not sure, if we share the same idea, how that will be maintained. For me it would be OK to freeze the actual cluster code in the 5.5.15 maintenance branch. The only changes to this branch would be - bug fixes for important bugs without work-arounds which will only need changes in small parts of the code (low complexity) - security fixes - bug fixes needed for compatibility with TC core 5.5, e.g. adoption of changes to Manager or Session. So I would like to keep that branch stable, but compatible with 5.5. Would that be OK for you? 4. Many of the needed features needed for a more complete clustering solution are not possible today due to the tight coupling between components. But I would be stretching myself thin trying to maintain two code bases. This maintenance branch is easy to create, just branch the entire cluster module plus ClusterRuleSet.java, and it is complete. I agree, so do we have the same idea of the amount of maintenance for the maintenance branch? I'm pretty sure, Peter will be happy keeping that branch in shape (I think he leaves for holidays now, but he will be back next week). I have no problem putting this up for a vote, but so far, the only justifications are concerns, when I believe I can offer more features and an easier codebase to maintain. Voting is good, exchange of arguments as well. I think some of our concerns are not just theoretically. Major changes are needed and major changes usually break things for some time. So we are just trying to find out how to combine the grown user base and the needed improvements. I think your idea of a maintenance branch is just right. Rainer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New clustering module proposal - WAS: Long rants
+1 (non-binding) Filip Hanik - Dev Lists wrote: +1 from myself Filip Hanik - Dev Lists wrote: Sounds like there is a consensus amongst folks. So to summarize everyones thoughts, let me know if this sounds like a solution agreeable to everyone. 1. Keep 5.5.x as a maintenance module as it was of 5.5.15 + cross context 2. Break out cluster config from catalina.jar to catalina-cluster.jar that way we can enable more than one config In Catalina.java have a ClusterRuleSetFactory.getClusterRuleSet() that will load the rule set run time. 3. Create two new modules (to use for TC6 and as an optional library for TC 5.5.x) a) Name:groupcom Lib : catalina-groups.jar Purpose: Group messaging component b) Name: ha Lib : catalina-cluster.jar Purpose: session replication logic, context attribute replication and other new features Lets gather one round of feedback and then vote so that I can move on with new dev. Filip - 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: svn commit: r380835 -/tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/catalina/cluster/session/DeltaManager.java
Hi Filip,
I did a little exercise with Java 6 and Solaris DTrace.
The change is in fact OK, although I first thought that the DeltaRequest
will no longer be initialized:
DeltaManager.createSession() calls
ManagerBase.createSession()
which in turns calls
DeltaManager.createEmptySession()
DeltaManager.getNewDeltaSession()
DeltaSession.init()
DeltaSession.resetDeltaRequest()
So the DeltaRequest still gets initialized correctly :)
Thanks
Rainer
[EMAIL PROTECTED] wrote:
Author: fhanik
Date: Fri Feb 24 14:19:22 2006
New Revision: 380835
URL: http://svn.apache.org/viewcvs?rev=380835view=rev
Log:
Fix for bug
http://issues.apache.org/bugzilla/show_bug.cgi?id=38740
looks like we got trigger happy with the resetDeltaRequest
Thanks to Nick Wesselman and Rainer Jung that pointed this out.
Modified:
tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/catalina/cluster/session/DeltaManager.java
Modified:
tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/catalina/cluster/session/DeltaManager.java
URL:
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/catalina/cluster/session/DeltaManager.java?rev=380835r1=380834r2=380835view=diff
==
---
tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/catalina/cluster/session/DeltaManager.java
(original)
+++
tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/catalina/cluster/session/DeltaManager.java
Fri Feb 24 14:19:22 2006
@@ -605,7 +605,6 @@
}
DeltaSession session = (DeltaSession) super.createSession(sessionId) ;
-session.resetDeltaRequest();
if (distribute) {
sendCreateSession(session.getId(), session);
}
@@ -633,7 +632,6 @@
counterSend_EVT_SESSION_CREATED++;
send(msg);
}
-session.resetDeltaRequest();
}
/**
-
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]
DTrace analysis of TC-Cluster Multicast
Hi, I started to trace TC cluster with DTrace. I did a first simple exam for the mcast subcomplex. CPU usage and especially elapsed times might be slightly larger than expected, because I used the more intrusive extended DTrace probes. All tests were done with JDK 1.6.0 build 72 on Solaris 10 SPARC, using a T2000 system (8 cores with 4 Threads each). Method allocationelapsed cpu mcast/McastServiceImpl.send()1328B 40ms6.7ms mcast/McastServiceImpl.receive() 744-760B 23-510ms3.5ms So this does not look very bad, but I inspected, where cpu time is used and objects get allocated: 1) send cpu time, elapsed time and allocation, per send cpu elapsed alloc 6.7ms 40.3ms 1328B McastServiceImpl.send() 6.3ms 37.6ms 1296BMcastMember.getData() 1.3ms 7.6ms 136B ... getName().getBytes(); 0.9ms 5.3ms 120B ... getDomain().getBytes(); 3.6ms 21.2ms 880B ... java.net.InetAddress.getByName(host)... It's interesting, that the last three statements are responsible for 85% of the allocation and 90% of the cpu usage. This seems unnecessary, because for sending multicast heartbeat, name, domain and host do not change, so they could be buffered easily. 2) receive cpu time, elapsed time and allocation, per receive cpu elapsedalloc 3.5ms 23-510ms 744-760B McastServiceImpl.receive() 0.1ms 3-485ms 0B socket.receive() 2.8ms 17.9ms 640B McastMember.getMember() 1.4ms8.1ms 160Bnew String(named), 1.0ms5.6ms 128Bnew String(domaind), 0.1ms0.6ms 112BaddressToString(addr), 0.3ms2.7ms 16B ... membership.memberAlive(m) [Only 50%] 0.2ms2.3ms 32B ... membership.expire(timeToExpiration); ... The calls to memberAlive are much faster in ~50% of the calls. Here most interesting is the fact, that the string construction takes 70% of total cpu time. I inspected, why this is so. For the next trace I had to increase the depth I traced, so elapsed times go a little up. The columns are: - or : means start of method, end of method - stack depth relative to the receive method - cpu time - elapsed time - allocated bytes - class and method 3 - -- java/lang/String.init 4 - -- java/lang/String.init 5 - -- java/lang/StringCoding.decode 6 - -- java/lang/StringCoding.decode 7 - -- java/lang/StringCoding.deref 7 0.1ms 0.7ms0 java/lang/StringCoding.deref 7 - -- java/lang/StringCoding$StringDecoder.decode 8 - -- java/nio/ByteBuffer.wrap 8 0.1ms 0.5ms 48 java/nio/ByteBuffer.wrap 8 - -- java/nio/CharBuffer.wrap 8 0.1ms 0.5ms 48 java/nio/CharBuffer.wrap 8 - -- java/nio/charset/CharsetDecoder.decode 8 0.7ms 4.4ms0 java/nio/charset/CharsetDecoder.decode 7 1.1ms 7.8ms 160 java/lang/StringCoding$StringDecoder.decode 6 1.2ms 9.1ms 160 java/lang/StringCoding.decode 5 1.2ms 9.5ms 160 java/lang/StringCoding.decode 4 1.3ms 10.1ms 160 java/lang/String.init 3 1.3ms 10.2ms 160 java/lang/String.init So we can see, that most of the cpu time is needed inside - java/nio/charset/CharsetDecoder.decode: 0.7ms - java/lang/StringCoding.deref: 0.1ms - java/nio/ByteBuffer.wrap: 0.1ms - java/nio/CharBuffer.wrap: 0.1ms Maybe it would help to use a more byte-oriented format in the heartbeat messages and to not convert from it. String conversions might be restrictable to the case when logging in debug mode. Cheers, Rainer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DTrace analysis of TC-Cluster Multicast
I agree, heartbeat is not that important w.r.t. performance. I used it as a simple test for how DTrace will be able to help. And at least in that nearly trivial test case the results are already interesting. Another thing that DTrace can check is lock contention. So there's more to come :) Do you have a working build of groupcom? I could trace some of the group communication. I hope you will not sacrifice synchronization correctness for performance ... Rainer Filip Hanik - Dev Lists wrote: Cool Rainer, interesting numbers. Can you run the same numbers on the new module groupcom. I have done some optimizations there, for example, the name isn't broadcasted. And I am about to remove the domain, instead of having a default one. also, I agree, lets not translate the 4byte IP and the 4byte port when receiving it. instead, member comparisons can be done on the byte array level, excellent suggestion. After that I won't be spending to much focus on this issue, as a heartbeat do not really have to be optimized. The heartbeat runs *very* infrequently and it not a critical piece. Instead I am gonna start reworking the data senders, there are way too many synchronized calls locking down the sockets, the code is somewhat cluttered then I am gonna move on to serialization. In the current cluster module, too much gets serialized, in the new module ha I have already removed a lot of serialization and will continue stripping it out. Filip Rainer Jung wrote: Hi, I started to trace TC cluster with DTrace. I did a first simple exam for the mcast subcomplex. CPU usage and especially elapsed times might be slightly larger than expected, because I used the more intrusive extended DTrace probes. All tests were done with JDK 1.6.0 build 72 on Solaris 10 SPARC, using a T2000 system (8 cores with 4 Threads each). Method allocationelapsed cpu mcast/McastServiceImpl.send()1328B 40ms6.7ms mcast/McastServiceImpl.receive() 744-760B 23-510ms3.5ms So this does not look very bad, but I inspected, where cpu time is used and objects get allocated: 1) send cpu time, elapsed time and allocation, per send cpu elapsed alloc 6.7ms 40.3ms 1328B McastServiceImpl.send() 6.3ms 37.6ms 1296BMcastMember.getData() 1.3ms 7.6ms 136B ... getName().getBytes(); 0.9ms 5.3ms 120B ... getDomain().getBytes(); 3.6ms 21.2ms 880B ... java.net.InetAddress.getByName(host)... It's interesting, that the last three statements are responsible for 85% of the allocation and 90% of the cpu usage. This seems unnecessary, because for sending multicast heartbeat, name, domain and host do not change, so they could be buffered easily. 2) receive cpu time, elapsed time and allocation, per receive cpu elapsedalloc 3.5ms 23-510ms 744-760B McastServiceImpl.receive() 0.1ms 3-485ms 0B socket.receive() 2.8ms 17.9ms 640B McastMember.getMember() 1.4ms8.1ms 160Bnew String(named), 1.0ms5.6ms 128Bnew String(domaind), 0.1ms0.6ms 112BaddressToString(addr), 0.3ms2.7ms 16B ... membership.memberAlive(m) [Only 50%] 0.2ms2.3ms 32B ... membership.expire(timeToExpiration); ... The calls to memberAlive are much faster in ~50% of the calls. Here most interesting is the fact, that the string construction takes 70% of total cpu time. I inspected, why this is so. For the next trace I had to increase the depth I traced, so elapsed times go a little up. The columns are: - or : means start of method, end of method - stack depth relative to the receive method - cpu time - elapsed time - allocated bytes - class and method 3 - -- java/lang/String.init 4 - -- java/lang/String.init 5 - -- java/lang/StringCoding.decode 6 - -- java/lang/StringCoding.decode 7 - -- java/lang/StringCoding.deref 7 0.1ms 0.7ms0 java/lang/StringCoding.deref 7 - -- java/lang/StringCoding$StringDecoder.decode 8 - -- java/nio/ByteBuffer.wrap 8 0.1ms 0.5ms 48 java/nio/ByteBuffer.wrap 8 - -- java/nio/CharBuffer.wrap 8 0.1ms 0.5ms 48 java/nio/CharBuffer.wrap 8 - -- java/nio/charset/CharsetDecoder.decode 8 0.7ms 4.4ms0 java/nio/charset/CharsetDecoder.decode 7 1.1ms 7.8ms 160 java/lang/StringCoding$StringDecoder.decode 6 1.2ms 9.1ms 160 java/lang/StringCoding.decode 5 1.2ms 9.5ms 160 java/lang/StringCoding.decode 4 1.3ms 10.1ms 160 java/lang/String.init 3 1.3ms 10.2ms 160 java/lang/String.init So we can see, that most of the cpu time is needed inside - java/nio/charset/CharsetDecoder.decode: 0.7ms - java/lang/StringCoding.deref: 0.1ms - java/nio/ByteBuffer.wrap: 0.1ms - java/nio/CharBuffer.wrap: 0.1ms Maybe it would help to use a more byte-oriented format in the heartbeat messages and to not convert from it. String conversions might be restrictable
[Proposal] Small manager improvement
I have a small patch that I think improves the session listing in the manager webapp: The doc says Session Statistics Display the default session timeout for a web application, and the number of currently active sessions that fall within ten-minute ranges of their actual timeout times. For example, after restarting Tomcat and then executing one of the JSP samples in the /examples web app, you might get something like this: Actually that's not true and I have the impression the code does something not very useful which we can very easily tranform to something really useful: At the moment the code calculates a histogramm of the different maxInactiveInterval values for all sessions of a context. Now most contexts I know, work with a fixed maxInactiveInterval for all sessions in the context. As a result, all of the sessions are in the same histogram class and instead of the possible up to 60 lines of result histogram, the code always simply produces a single line showing again the total number of sessions - which is already included on the same page further down. So no real sense in that. With a few lines of change we could easily list a histogram of how far sessions are away from their idle timeout. That seems to be a much more interesting information for monitoring, e.g. it enables to make a well informed decision on shrinking or sizing up session timeouts. This would also be in better alignment with the documntation of manger. This is sugestion 1a. What I would even like better is instead printing a hitogramm of the actual idle time of the sessions. I think for most admins this is a more easily understandable metric. So suggestion 1b: change sessions-function in manager webapp to show a histogram of session idle distribution instead of maxActiveTimeout distribution. Suggestion 2: another small fix would allow a manager user to prematurely expire all sessions which are idle for a longer time than the amount of minutes she types into a text field (before she presses the new expire button. I have a use case for this: some applications work with long running sessions (employee applications) that might have relatively big sessions. These applications typically have a timeout of several hours to allow resumption of work after lunch breaks, meeting etc. Often such apps depend on other external applications. When those have a bad day, the users of the web app might experience very long response times. So they decide to try a new login to the web app. From that point in time their old sessions are no longer used, but still stay in memory for several more hours. As soon as the external app has another hickup, another round of sessions gets lost by the same user behaviour. A well informed admin could now react to such a non-standard situation by deciding to expire all sessions which are idle longer than the amount of minutes she decides, e.g. one hour. I did all that for TC5 and for 5.5 it's mostly the same. If their is interest in it, I would provide patches, including doc patches. I still would need spanish and japanese translations for expire. :) Feedback is highly welcome. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r389946 [3/5] - in /tomcat/tc6.0.x/trunk: ./ java/org/apache/catalina/ant/jmx/ java/org/apache/catalina/connector/ java/org/apache/catalina/core/ java/org/apache/catalina/loader/ java
Hi Remy,
I saw you taking over classes from commons modeler into tc 6. Just
yesterday William Barker commited a very small and non-risky patch I
submitted two years ago to bugzilla against Registry.convertValue():
http://issues.apache.org/bugzilla/show_bug.cgi?id=31608
The method has conversions for Integer and Boolean, but not for Long. It
is used in Tomcats manager webapp (manager/jmxproxy) and many of
tomcat's internal JMX parameters are longs and can therefore not yet
been set via the manager webapp.
It would be very nice, if you could apply the patch to tc 6 copy of
Regitry.java. Four your convenience I include it here:
Index: Registry.java
===
--- Registry.java (revision 390034)
+++ Registry.java (working copy)
@@ -713,6 +713,9 @@
} else if( java.lang.Integer.equals( type ) ||
int.equals( type )) {
objValue=new Integer( value );
+} else if( java.lang.Long.equals( type ) ||
+long.equals( type )) {
+objValue=new Long( value );
} else if( java.lang.Boolean.equals( type ) ||
boolean.equals( type )) {
objValue=new Boolean( value );
Thank you!
[EMAIL PROTECTED] wrote:
Added: tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/modeler/Registry.java
URL:
http://svn.apache.org/viewcvs/tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/modeler/Registry.java?rev=389946view=auto
==
--- tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/modeler/Registry.java
(added)
+++ tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/modeler/Registry.java Wed
Mar 29 16:55:22 2006
...
+public Object convertValue(String type, String value)
+{
+Object objValue=value;
+
+if( type==null || java.lang.String.equals( type )) {
+// string is default
+objValue=value;
+} else if( javax.management.ObjectName.equals( type ) ||
+ObjectName.equals( type )) {
+try {
+objValue=new ObjectName( value );
+} catch (MalformedObjectNameException e) {
+return null;
+}
+} else if( java.lang.Integer.equals( type ) ||
+int.equals( type )) {
+objValue=new Integer( value );
+} else if( java.lang.Boolean.equals( type ) ||
+boolean.equals( type )) {
+objValue=new Boolean( value );
+}
+return objValue;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
mod_jk trunk: wrong version in configure.in?
While playing around with svn checkout of mod_jk trunk (1.2.16-dev) I saw, that in jk/native/configure.in there is still a line VERSION=1.2.14 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk trunk: wrong version in configure.in?
William A. Rowe, Jr. wrote: If you run automake, it's still brought in, so necessary to keep it in sync. Exactly, I was using buildconf.sh and the wrong version went into the Makefile and portable.h. From portable.h it looks like it's going nowhere, the one in the Makefile seems to be relevent for distribution building, which Mladen said does not exist. So we might be able to throw it out completely. Mladen Turk wrote: Rainer Jung wrote: While playing around with svn checkout of mod_jk trunk (1.2.16-dev) I saw, that in jk/native/configure.in there is still a line VERSION=1.2.14 Right, but it's irrelevant. We have jk_version.h. I think this was meant to be used for packaging tasks that BTW doesn't exist. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Challenges for Java hosting
Some hints, although I didn't go deeper into it and most of it might still be experimental: 1) Java Isolate API JSP-221 http://java.sys-con.com/read/99716.htm http://jcp.org/en/jsr/detail?id=121 2) Building on top Java Resource Consumption Management API JSR-284 http://jcp.org/en/jsr/detail?id=284 http://research.sun.com/techrep/2003/abstract-124.html http://research.sun.com/projects/barcelona/papers/middleware04.pdf 3) Sun's experimental JVM, implementing parts of it: http://java.sun.com/developer/technicalArticles/Programming/mvm/ https://mvm.dev.java.net/ [you'll need to get the JDK Researcher role for that last one via https://mvm.dev.java.net/] 4) Maybe 1) and 2) are things to discuss with project Harmony? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Bug in TC class loading
I logged a bug a couple of days ago:
http://issues.apache.org/bugzilla/show_bug.cgi?id=39218
Since nobody gave any response, I wanted to ping the list.
The current implementation of the server, common and shared class
loaders use the catalina.properties file to make the group of
repositories which are searched for classes configurable.
Unfortunately the order of repositories in the entries is not respected.
Instead they are rearranched into packed (jar files), unpacked (class
directories) and a URL list. Then all unpacked are searched first, after
that all jars and at the end all URLs.
A typical user would understand the configuration lines in
catalina.properties as an analogy to the usual classpath of the system
classloader. And I think that's intended. He would rely on the fact,
that the order of entries is respected by the class loader. So he will
order his patches etc. in the most obvious way. We throw away the order
and rearrange via undocumented rules.
I attached a patch to bugzilla adding another signature to the creation
of the classloader, allowing to pass in all repositories in the correct
order. It's not a major redesign of the loading, because I want to keep
the risk of breaking something minimal.
Any comments?
An example:
The tomcat product deployer might add a patch into
CATALINA_HOME/server/classes (they don't want to overwrite the original
jar files and adding them into server/lib is no way, since there is no
way of knowing, in which order *.jar will be evaluated).
The application project team prepares an instance in CATALINA_BASE and
deploys a newer version or a collection of patches as a jar file into
CATALINA_HOME/server/lib.
They prepare a catalina.properties file with
server.loader=${catalina.base}/server/lib/*.jar,\
${catalina.home}/server/classes,\
${catalina.home}/server/lib/*.jar
Their version of the patch will not be loaded, because we regroup the
entries and ${catalina.home}/server/classes will come first!
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bug in TC class loading
svn: Commit failed ... 403 Forbidden (http://svn.apache.org) Seriously: I would like to, but I'm only a contributor :) Remy Maucherat wrote: Rainer Jung wrote: I logged a bug a couple of days ago: http://issues.apache.org/bugzilla/show_bug.cgi?id=39218 I found this was a reasonable addition. If you commit something and I don't like it, I know how to complain. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Proposal] mod_jk lb changes
Hi List, hi Mladen (master of mod_jk): a year ago we changed to algorithm in mod_jk, that counts weighted requests in the lb worker to decide, which balanced worker should receive the next request. The new algorithm three main advantages: a) using only integers b) using only a limited range of values c) behaving well when one balanced worker went out of service for a longer time and then came back Unfortunately the algorithm has another deficiency and I propose to do it in yet another way. The problem is: the algo needs to update counters on all balanced workers not only on the worker that gets the request. No in more complex balancer configurations we have different groups of workers eligible for a request. A request might carry a session and the right worker is dwn, then the whole domain (replicas) are eligible. A request might not carry a session, then all available workers are eligible. Although we have different groups depending on the type of request and the status of the workers we only update one common set of load counters. This leads to incorrect balancing decisions, whenever these situations get mixed. My proposal is to go back basically to the old way of doing it, but with an implementation, that still respects a) and c) and to some extend also b). A) During initialization we calculate the smallest common multiple L of all balancing weights (lb factor) l_1,...,l_n and set L_1=L/l_1,...,L_n=L/l_n. That's cheap, the algo is well known and all is exact integer operations. B) We use a 64Bit load counter and for each request we do not only add 1, instead we add L_i whenever worker i gets chosen. C) We always choose the eligible worker with the smallest load counter (and we can use a rotating offset like it is already implemented for traffic). D) During maintenance we divide all load counters by some constant. Best would be a power of 2, so we can simply shift right all load counters. This way we shape the counters with a simple approximation of an exponential curve, so the influence of incrementing the counters in the past gets less important the longer away it is. E) If we divide in D) by 2 each minute, then the counters will never exceed 2 times the maximum a counter can reach in a single minute. For most weight factors and loads this will easily fit into a 64 Bit integer. We can furthermore care about overflows by prematurely shifting right whenever the counters get to big (with very high load aging the counters earlier on demand). I could supply a patch including documentation. I think that would be low risk, because that patch would only influence how the load counters are handled, and would not interfere with changing worker status and decision logic. Comments? Rainer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] mod_jk lb changes
OK, I expect to send the patches late Friday german time (tomorrow, but in 3 minutes today). Mladen Turk wrote: Rainer Jung wrote: Good news. Will you cut another mod_jk version close to 5.5.17 (it will be to late for that one), or are you planning to keep 1.2.16 in development for at least 1-2 weeks further on? We had a preliminary vote two weeks ago, and everyone agreed to go for the 1.2.16, so if your patches do not require any config changes we can include them within 1.2.16, because they are very valuable. I suppose the jk will be out by next Friday. I'll call for a vote as soon as you finish the maintain for the request, so that folks have a chance to test it. 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: svn commit: r394031 - /tomcat/connectors/trunk/jni/native/os/unix/system.c
Hi Mladen,
I've got another one for that file. You optimized the original Solaris
contribution by changing division with a value to multiplication with
the reciprocal value. Unfortunately we are in integer land and the
divisor was bigger than 1, so now we always multiply by 0 :(
Patch attached an CC to mturk in case the attachment gets stripped.
Rainer
Index: jni/native/os/unix/system.c
===
--- jni/native/os/unix/system.c (revision 394052)
+++ jni/native/os/unix/system.c (working copy)
@@ -53,6 +53,7 @@
#if defined(sun)
#define MAX_PROC_PATH_LEN 64
#define MAX_CPUS 512
+#define CPU_TIME_RESOLUTION 1000
#define PSINFO_T_SZ sizeof(psinfo_t)
#define PRUSAGE_T_SZ sizeof(prusage_t)
@@ -148,8 +149,7 @@
int res = 0; /* general result state */
/* non-static variables - sysinfo/swapctl use */
long ret_sysconf; /* value returned from sysconf
call */
-long tck_dividend; /* factor used by transforming
tick numbers to milliseconds */
-long tck_divisor; /* divisor used by transforming
tick numbers to milliseconds */
+long tck_divisor; /* divisor used for
transforming tick numbers to time units */
long sys_pagesize = sysconf(_SC_PAGESIZE); /* size of a system memory
page in bytes */
long sys_clk_tck = sysconf(_SC_CLK_TCK); /* number of system ticks per
second */
struct anoninfo info; /* structure for information
about sizes in anonymous memory system */
@@ -237,18 +237,7 @@
rv = apr_get_os_error();
}
else {
-tck_dividend = 1000;
-tck_divisor = sys_clk_tck;
-for (i = 0; i 3; i++) {
-if (tck_divisor % 2 == 0) {
-tck_divisor = tck_divisor / 2;
-tck_dividend = tck_dividend / 2;
-}
-if (tck_divisor % 5 == 0) {
-tck_divisor = tck_divisor / 5;
-tck_dividend = tck_dividend / 5;
-}
-}
+tck_divisor = sys_clk_tck / CPU_TIME_RESOLUTION;
if (kstat_ctl == NULL) {
kstat_ctl = kstat_open();
kid = kstat_ctl-kc_chain_id;
@@ -276,12 +265,11 @@
for (i = 0; i cpu_count; i++) {
new_kid = kstat_read(kstat_ctl, kstat_cpu[i], NULL);
if (new_kid = 0) {
-long tck_r = tck_dividend / tck_divisor;
cpu = ((cpu_stat_t *)kstat_cpu[i]-ks_data)-cpu_sysinfo;
-pvals[7] += (jlong)(((long)cpu.cpu[CPU_IDLE]) * tck_r);
-pvals[7] += (jlong)(((long)cpu.cpu[CPU_WAIT]) * tck_r);
-pvals[8] += (jlong)(((long)cpu.cpu[CPU_KERNEL]) * tck_r);
-pvals[9] += (jlong)(((long)cpu.cpu[CPU_USER]) * tck_r);
+pvals[7] += (jlong)(((long)cpu.cpu[CPU_IDLE]) /
tck_divisor);
+pvals[7] += (jlong)(((long)cpu.cpu[CPU_WAIT]) /
tck_divisor);
+pvals[8] += (jlong)(((long)cpu.cpu[CPU_KERNEL]) /
tck_divisor);
+pvals[9] += (jlong)(((long)cpu.cpu[CPU_USER]) /
tck_divisor);
}
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: TC native 1.1.3 ready?
I sent a patch for the Solaris part of tcnative to Mladen and the list this morning which is not yet included. The Bug is *not* critical (CPU used and idle in the manager status page for Solaris will be 0 always). Rainer Yoav Shapira wrote: Hi, Is tcnative 1.1.3 ready? The default build properties is still choking when trying to download it from our archive location... Yoav -- Yoav Shapira Nimalex LLC 1 Mifflin Place, Suite 310 Cambridge, MA, USA [EMAIL PROTECTED] / www.yoavshapira.com - 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: mod_jk 1.2.19 release candidate: ready to test
If you are going to build it yourself, it will work with versions much older than 2.0.54. I checked the change list for API changes of apache and found nothing that's related to what mod_jk uses at least back until 2.0.41. I think 2.0.54 is pretty save. But: If you are simply downloading provided binaries, they might be incompatible independant of the Apache version, because the build environment for the module might not fit your apache binary (different compilers etc.). Regards, Rainer [EMAIL PROTECTED] wrote: Just a quick question - does this REQUIRE Apache 2.0.58 or is verified it works with it? We're using Apache 2.0.54 but want to upgrade our mod_jk only. cheers, David x54680 |-+ | | Jim Jagielski| | | [EMAIL PROTECTED]| | || | | 19/09/2006 15:07 | | | Please respond to| | | Tomcat | | | Developers List | | || |-+ --| | | | To: Tomcat Users List users@tomcat.apache.org | | cc: Tomcat Developers List dev@tomcat.apache.org | | Subject: Re: mod_jk 1.2.19 release candidate: ready to test | --| +1 for release: Tested OS X, Sol8 and Suse 10.0 - 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] -- kippdata informationstechnologie GmbH Bornheimer Str. 33a 53111 Bonn Tel.: 0228/98549-0 Fax: 0228/98549-50 www.kippdata.de === kippdata informationstechnologie GmbH Bornheimer Str. 33a D-53111 Bonn Tel.: +49/0228/98549-0 Fax: +49/0228/98549-50 www.kippdata.de - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Reminder: Preparation for mod_jk release vote
Hi, I shortly want to remind everyone, that our release vote for mod_jk 1.2.19 will start tomorrow. So all users still have some time to give us positive or negative feedback on the release candidate. Until now, no issues have been found. You can find 1.2.19 under: http://tomcat.apache.org/dev/dist/tomcat-connectors/jk/ Thanks for participation Rainer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Releasing Tomcat Connectors 1.2.19
Hello to all Tomcat project members, mod_jk 1.2.19 has been available for testing for nearly 4 days now. For those interested, these are the download numbers for the first three days: 10 source/jk-1.2.19/tomcat-connectors-1.2.19-src.tar.gz 1 source/jk-1.2.19/tomcat-connectors-1.2.19-src.zip 17 win32/jk-1.2.19/mod_jk-apache-1.3.37.so 56 win32/jk-1.2.19/mod_jk-apache-2.0.58.so 77 win32/jk-1.2.19/mod_jk-apache-2.2.3.so 53 win32/jk-1.2.19/isapi_redirect.dll 2 win64/jk-1.2.19/amd64/isapi_redirect.dll 33 win32/jk-1.2.19/jk_symbols.zip 14 win32/jk-1.2.19/nsapi_redirect.dll 1 iseries/jk-1.2.19/MOD_JK1219.SAVF.gz (iseries was a googlebot :) ) and we had 33 views at the changelog. No new bugs have been reported so far, so I would like to proceed with the release vote. If you want to take a look, the source distribution can be downloaded from: http://tomcat.apache.org/dev/dist/tomcat-connectors/jk/ The updated documentation can be found at http://tomcat.apache.org/dev/dist/tomcat-connectors/jk/source/jk-1.2.19/docs/ So here's the vote, which will be open until Saturday September 23rd, 24:00 GMT. Apache Tomcat Connectors 1.2.19 is: [ ] Stable - no major issues, no regressions [ ] Beta - at least one significant issue -- tell us what it is [ ] Alpha - multiple significant issues -- tell us what they are Thank you, Rainer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Releasing Tomcat Connectors 1.2.19
Apache Tomcat Connectors 1.2.19 is: [X] Stable - no major issues, no regressions [ ] Beta - at least one significant issue -- tell us what it is [ ] Alpha - multiple significant issues -- tell us what they are Rainer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[RESULT][VOTE] Releasing Tomcat Connectors 1.2.19
The results of the vote are: Stable: 4+1 votes (Mladen, Henri, Peter, Rainer and Jim mailed a +1 before the vote started) Beta, Alpha: None. I'm now going to move everything to the download area, updating docs, updating cgi, mailing announcement ... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] Apache Tomcat mod_jk 1.2.19 Web Server Connector released
The Apache Tomcat team is pleased to announce the immediate availability of version 1.2.19 of the Apache Tomcat mod_jk web server connector. mod_jk is a connector which allows a web server such as Apache HTTPD to act as a front end to the Tomcat web application server. This version contains several enhancements and fixes a number of minor bugs of the previous version 1.2.18. See http://tomcat.apache.org/connectors-doc/changelog.html for a complete list of changes. Source distribtions can be downloaded from an Apache Software Foundation mirror at: http://tomcat.apache.org/download-connectors.cgi Binary distributions for a number of different operating systems and web servers can be downloaded from an Apache Software Foundation mirror at: http://tomcat.apache.org/download-connectors.cgi Documentation for using mod_jk with Tomcat 3.3, 4.1, 5.0 and 5.5 can be found at: http://tomcat.apache.org/connectors-doc/ Thank you, -- The Apache Tomcat Team - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] Apache Tomcat mod_jk 1.2.19 Web Server Connector released
The Apache Tomcat team is pleased to announce the immediate availability of version 1.2.19 of the Apache Tomcat mod_jk web server connector. mod_jk is a connector which allows a web server such as Apache HTTPD to act as a front end to the Tomcat web application server. This version contains several enhancements and fixes a number of minor bugs of the previous version 1.2.18. See http://tomcat.apache.org/connectors-doc/changelog.html for a complete list of changes. Source distribtions can be downloaded from an Apache Software Foundation mirror at: http://tomcat.apache.org/download-connectors.cgi Binary distributions for a number of different operating systems and web servers can be downloaded from an Apache Software Foundation mirror at: http://tomcat.apache.org/download-connectors.cgi Documentation for using mod_jk with Tomcat 3.3, 4.1, 5.0 and 5.5 can be found at: http://tomcat.apache.org/connectors-doc/ Thank you, -- The Apache Tomcat Team - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SetEnvIf example in docs missing =
Thanks for the hint. I fixed it. Unfortunately SetEnv takes a space and SetEnvIf an equals sign. That's were I broke the doc. Jeff Johnson wrote: It took me a while to figure out why the example at the very bottom of http://tomcat.apache.org/connectors-doc/config/apache.html kept throwing an error like this: [2006-10-06 14:05:06] [10200:7072] [info] jk_handler::mod_jk.c (2071): Could not find a worker for worker name=1 I finally figure out that instead of this: SetEnvIf REQUEST_URI ^/apps/([^/]*)/ JK_WORKER_NAME $1 it should be this: SetEnvIf REQUEST_URI ^/apps/([^/]*)/ JK_WORKER_NAME=$1 Awesome feature by the way, as well as the new ability to log which real workers the load balancer sends the requests to via apache logging! Yes, I hope a lot of people will start to use it. Thanks! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Tomcat 6 release plan
ballot [X] +1 [ ] +0 [ ] -1 /ballot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_proxy_ajp vs mod_jk
Hi, fredk2 wrote: The question is - how can you set secret in mod_proxy_ajp ? Not at the moment. If this feature is not (yet) implemented, can this be easily added - aka can we expect this in a later version :) ? Please let me know if this post should be made on apache-httpd dev forum. You'll reach Mladen, who ported mod_jk to mod_proxy_* on this list, but you should better post to httpd-dev to make sure, all the other developers are able to read it. Rainer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Tomcat 6 release plan
Remy Maucherat schrieb: Remy Maucherat wrote: I plan to tag 6.0.0 late friday. Is it ok ? OK for me. Rainer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r467787 - in /tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net: NioChannel.java NioEndpoint.java SecureNioChannel.java SocketProperties.java
Hi Filip, the fluctuation reminds me of something: depending on the client behaviour connections will end up in TIME_WAIT state. Usually you run into trouble (throughput stalls) once you have around 30K of them. They will be cleaned up every now and then by the kernel (talking about the unix/Linux style mechanisms) and then throughput (and CPU usage) start again. With modern systems handling 10-20k requests per second one can run into trouble much faster, than the usual cleanup intervals. Check with netstat -an if you can see a lot of TIME_WAIT connections (thousands). If not it's something different :( Regards, Rainer Filip Hanik - Dev Lists schrieb: Remy Maucherat wrote: [EMAIL PROTECTED] wrote: Author: fhanik Date: Wed Oct 25 15:11:10 2006 New Revision: 467787 URL: http://svn.apache.org/viewvc?view=revrev=467787 Log: Documented socket properties Added in the ability to cache bytebuffers based on number of channels or number of bytes Added in nonGC poller events to lower CPU usage during high traffic I'm starting to get emails again, so sorry for not replying. I am testing with the default VM settings, which basically means that excessive GC will have a very visible impact. I am testing to optimize, not to see which connector would be faster in the real world (probably neither unless testing scalability), so I think it's reasonable. This fixes the paranormal behavior I was seeing on Windows, so the NIO connector works properly now. Great ! However, I still have NIO which is slower than java.io which is slower than APR. It's ok if some solutions are better than others on certain platforms of course. thanks for the feedback, I'm testing with larger files now, 100k+ and also see APR-JIO-NIO NIO has a very funny CPU telemetry graph, it fluctuates way to much, so I have to find where in the code it would do this, so there is still some work to do. I'd like to see a nearly flat CPU usage when running my test, but instead the CPU goes from 20-80% up and down, up and down. during my test (for i in $(seq 1 100); do echo -n $i.; ./ab -n 1000 -c 400 http://localhost:$PORT/104k.jpg 21 |grep Requests per; done) my memory usage goes up to 40MB, then after a FullGC it goes down to 10MB again, so I wanna figure out where that comes from as well. My guess is that all that data is actually in the java.net.Socket classes, as I am seeing the same results with the JIO connector, but not with APR(cause APR allocates mem using pools) Btw, had to put in the byte[] buffer back into the InternalNioOutputBuffer.java, ByteBuffers are way to slow. With APR, I think the connections might be lingering to long as eventually, during my test, it stop accepting connections. Usually around the 89th iteration of the test. I'm gonna keep working on this for a bit, as I think I am getting to a point with the NIO connector where it is a viable alternative. Filip - 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: svn commit: r467787 - in /tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net: NioChannel.java NioEndpoint.java SecureNioChannel.java SocketProperties.java
Hi Filip, that's one of the not so nice things with linux. As far as I know it's not configurable with standard linux. There exist kernel patches for this and there is an ip filter module that lets you do that, but some say that module is very bad for IP performance (and high performance would be the major reason to decrease the time_wait interval). It' shrinkable for solaris (ndd -set /dev/tcp tcp_time_wait_interval VALUE_IN_SECONDS), but even there the thread cleaning up the tables runs only every 5 seconds. Concerning the one request 1 connection case: I often realized strange behaviour (unclean shutdown) of ab concerning the last request in a connection. I never analysed it though. If you can easily reproduce the one request over one connection is slow problem without high load, you might want to tcpdump to check, if it's really slow on the server side. Just my 0.9 cents ... Rainer Filip Hanik - Dev Lists schrieb: That's some very good info, it looks like my system never does go over 30k and cleaning it up seems to be working really well. btw. do you know where I change the cleanup intervals for linux 2.6 kernel? I figured out what the problem was: Somewhere I have a lock/wait problem for example, this runs perfectly: ./ab -n 1 -c 100 http://localhost:$PORT/run.jsp?run=TEST$i If I change -c 100 (100 sockets) to -c 1, each JSP request takes 1 second. so what was happening in my test was running 1000 requests over 400 connections, then invoking 1 request over 1 connection, and repeat. Every time I did the single connection request, it does a 1sec delay, this cause the CPU to drop. So basically, the NIO connector sucks majorly if you are a single user :), I'll trace this one down. Filip Rainer Jung wrote: Hi Filip, the fluctuation reminds me of something: depending on the client behaviour connections will end up in TIME_WAIT state. Usually you run into trouble (throughput stalls) once you have around 30K of them. They will be cleaned up every now and then by the kernel (talking about the unix/Linux style mechanisms) and then throughput (and CPU usage) start again. With modern systems handling 10-20k requests per second one can run into trouble much faster, than the usual cleanup intervals. Check with netstat -an if you can see a lot of TIME_WAIT connections (thousands). If not it's something different :( Regards, Rainer Filip Hanik - Dev Lists schrieb: Remy Maucherat wrote: [EMAIL PROTECTED] wrote: Author: fhanik Date: Wed Oct 25 15:11:10 2006 New Revision: 467787 URL: http://svn.apache.org/viewvc?view=revrev=467787 Log: Documented socket properties Added in the ability to cache bytebuffers based on number of channels or number of bytes Added in nonGC poller events to lower CPU usage during high traffic I'm starting to get emails again, so sorry for not replying. I am testing with the default VM settings, which basically means that excessive GC will have a very visible impact. I am testing to optimize, not to see which connector would be faster in the real world (probably neither unless testing scalability), so I think it's reasonable. This fixes the paranormal behavior I was seeing on Windows, so the NIO connector works properly now. Great ! However, I still have NIO which is slower than java.io which is slower than APR. It's ok if some solutions are better than others on certain platforms of course. thanks for the feedback, I'm testing with larger files now, 100k+ and also see APR-JIO-NIO NIO has a very funny CPU telemetry graph, it fluctuates way to much, so I have to find where in the code it would do this, so there is still some work to do. I'd like to see a nearly flat CPU usage when running my test, but instead the CPU goes from 20-80% up and down, up and down. during my test (for i in $(seq 1 100); do echo -n $i.; ./ab -n 1000 -c 400 http://localhost:$PORT/104k.jpg 21 |grep Requests per; done) my memory usage goes up to 40MB, then after a FullGC it goes down to 10MB again, so I wanna figure out where that comes from as well. My guess is that all that data is actually in the java.net.Socket classes, as I am seeing the same results with the JIO connector, but not with APR(cause APR allocates mem using pools) Btw, had to put in the byte[] buffer back into the InternalNioOutputBuffer.java, ByteBuffers are way to slow. With APR, I think the connections might be lingering to long as eventually, during my test, it stop accepting connections. Usually around the 89th iteration of the test. I'm gonna keep working on this for a bit, as I think I am getting to a point with the NIO connector where it is a viable alternative. Filip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED
Re: svn commit: r467787 - in /tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net: NioChannel.java NioEndpoint.java SecureNioChannel.java SocketProperties.java
Sorry: Solaris VALUE_IN_SECONDS - VALUE_IN_MILLISECONDS Rainer Jung schrieb: Hi Filip, that's one of the not so nice things with linux. As far as I know it's not configurable with standard linux. There exist kernel patches for this and there is an ip filter module that lets you do that, but some say that module is very bad for IP performance (and high performance would be the major reason to decrease the time_wait interval). It' shrinkable for solaris (ndd -set /dev/tcp tcp_time_wait_interval VALUE_IN_SECONDS), but even there the thread cleaning up the tables runs only every 5 seconds. Concerning the one request 1 connection case: I often realized strange behaviour (unclean shutdown) of ab concerning the last request in a connection. I never analysed it though. If you can easily reproduce the one request over one connection is slow problem without high load, you might want to tcpdump to check, if it's really slow on the server side. Just my 0.9 cents ... Rainer Filip Hanik - Dev Lists schrieb: That's some very good info, it looks like my system never does go over 30k and cleaning it up seems to be working really well. btw. do you know where I change the cleanup intervals for linux 2.6 kernel? I figured out what the problem was: Somewhere I have a lock/wait problem for example, this runs perfectly: ./ab -n 1 -c 100 http://localhost:$PORT/run.jsp?run=TEST$i If I change -c 100 (100 sockets) to -c 1, each JSP request takes 1 second. so what was happening in my test was running 1000 requests over 400 connections, then invoking 1 request over 1 connection, and repeat. Every time I did the single connection request, it does a 1sec delay, this cause the CPU to drop. So basically, the NIO connector sucks majorly if you are a single user :), I'll trace this one down. Filip Rainer Jung wrote: Hi Filip, the fluctuation reminds me of something: depending on the client behaviour connections will end up in TIME_WAIT state. Usually you run into trouble (throughput stalls) once you have around 30K of them. They will be cleaned up every now and then by the kernel (talking about the unix/Linux style mechanisms) and then throughput (and CPU usage) start again. With modern systems handling 10-20k requests per second one can run into trouble much faster, than the usual cleanup intervals. Check with netstat -an if you can see a lot of TIME_WAIT connections (thousands). If not it's something different :( Regards, Rainer Filip Hanik - Dev Lists schrieb: Remy Maucherat wrote: [EMAIL PROTECTED] wrote: Author: fhanik Date: Wed Oct 25 15:11:10 2006 New Revision: 467787 URL: http://svn.apache.org/viewvc?view=revrev=467787 Log: Documented socket properties Added in the ability to cache bytebuffers based on number of channels or number of bytes Added in nonGC poller events to lower CPU usage during high traffic I'm starting to get emails again, so sorry for not replying. I am testing with the default VM settings, which basically means that excessive GC will have a very visible impact. I am testing to optimize, not to see which connector would be faster in the real world (probably neither unless testing scalability), so I think it's reasonable. This fixes the paranormal behavior I was seeing on Windows, so the NIO connector works properly now. Great ! However, I still have NIO which is slower than java.io which is slower than APR. It's ok if some solutions are better than others on certain platforms of course. thanks for the feedback, I'm testing with larger files now, 100k+ and also see APR-JIO-NIO NIO has a very funny CPU telemetry graph, it fluctuates way to much, so I have to find where in the code it would do this, so there is still some work to do. I'd like to see a nearly flat CPU usage when running my test, but instead the CPU goes from 20-80% up and down, up and down. during my test (for i in $(seq 1 100); do echo -n $i.; ./ab -n 1000 -c 400 http://localhost:$PORT/104k.jpg 21 |grep Requests per; done) my memory usage goes up to 40MB, then after a FullGC it goes down to 10MB again, so I wanna figure out where that comes from as well. My guess is that all that data is actually in the java.net.Socket classes, as I am seeing the same results with the JIO connector, but not with APR(cause APR allocates mem using pools) Btw, had to put in the byte[] buffer back into the InternalNioOutputBuffer.java, ByteBuffers are way to slow. With APR, I think the connections might be lingering to long as eventually, during my test, it stop accepting connections. Usually around the 89th iteration of the test. I'm gonna keep working on this for a bit, as I think I am getting to a point with the NIO connector where it is a viable alternative. Filip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail
Re: svn commit: r467787 - in /tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net: NioChannel.java NioEndpoint.java SecureNioChannel.java SocketProperties.java
Jean-frederic Clere schrieb: Peter Rossbach wrote: For Linux: Set the timeout_timewait paramater using the following command: /sbin/sysctl -w net.ipv4.vs.timeout_timewait=30 This will set TME_WAIT for 30 seconds. No... My machine (debian 2.6.13) says: +++ [EMAIL PROTECTED]:~$ sudo /sbin/sysctl -w net.ipv4.vs.timeout_timewait=30 error: net.ipv4.vs.timeout_timewait is an unknown key It's an extension of linux virtual server not existing in a standard kernel. +++ net.ipv4.tcp_fin_timeout is probably the thing to use: +++ [EMAIL PROTECTED]:~$ more /proc/sys/net/ipv4/tcp_fin_timeout 60 No that's something different, responsible for FIN_WAIT2 and not for TIME_WAIT. I'm still pretty sure, TIME_WAIT interval is (unfortunately) not tunable on standard 2.6 kernel. +++ Cheers Jean-Frederic For Solaris: Set the tcp_time_wait_interval to 3 milliseconds as follows: /usr/sbin/ndd -set /dev/tcp tcp_time_wait_interval 3 == Tipps for tuning mac os x 10.4 are very welcome :-( Regards Peter Roßbach [EMAIL PROTECTED] Am 26.10.2006 um 20:58 schrieb Filip Hanik - Dev Lists: That's some very good info, it looks like my system never does go over 30k and cleaning it up seems to be working really well. btw. do you know where I change the cleanup intervals for linux 2.6 kernel? I figured out what the problem was: Somewhere I have a lock/wait problem for example, this runs perfectly: ./ab -n 1 -c 100 http://localhost:$PORT/run.jsp?run=TEST$i If I change -c 100 (100 sockets) to -c 1, each JSP request takes 1 second. so what was happening in my test was running 1000 requests over 400 connections, then invoking 1 request over 1 connection, and repeat. Every time I did the single connection request, it does a 1sec delay, this cause the CPU to drop. So basically, the NIO connector sucks majorly if you are a single user :), I'll trace this one down. Filip Rainer Jung wrote: Hi Filip, the fluctuation reminds me of something: depending on the client behaviour connections will end up in TIME_WAIT state. Usually you run into trouble (throughput stalls) once you have around 30K of them. They will be cleaned up every now and then by the kernel (talking about the unix/Linux style mechanisms) and then throughput (and CPU usage) start again. With modern systems handling 10-20k requests per second one can run into trouble much faster, than the usual cleanup intervals. Check with netstat -an if you can see a lot of TIME_WAIT connections (thousands). If not it's something different :( Regards, Rainer Filip Hanik - Dev Lists schrieb: Remy Maucherat wrote: [EMAIL PROTECTED] wrote: Author: fhanik Date: Wed Oct 25 15:11:10 2006 New Revision: 467787 URL: http://svn.apache.org/viewvc?view=revrev=467787 Log: Documented socket properties Added in the ability to cache bytebuffers based on number of channels or number of bytes Added in nonGC poller events to lower CPU usage during high traffic I'm starting to get emails again, so sorry for not replying. I am testing with the default VM settings, which basically means that excessive GC will have a very visible impact. I am testing to optimize, not to see which connector would be faster in the real world (probably neither unless testing scalability), so I think it's reasonable. This fixes the paranormal behavior I was seeing on Windows, so the NIO connector works properly now. Great ! However, I still have NIO which is slower than java.io which is slower than APR. It's ok if some solutions are better than others on certain platforms of course. thanks for the feedback, I'm testing with larger files now, 100k+ and also see APR-JIO-NIO NIO has a very funny CPU telemetry graph, it fluctuates way to much, so I have to find where in the code it would do this, so there is still some work to do. I'd like to see a nearly flat CPU usage when running my test, but instead the CPU goes from 20-80% up and down, up and down. during my test (for i in $(seq 1 100); do echo -n $i.; ./ab -n 1000 -c 400 http://localhost:$PORT/104k.jpg 21 |grep Requests per; done) my memory usage goes up to 40MB, then after a FullGC it goes down to 10MB again, so I wanna figure out where that comes from as well. My guess is that all that data is actually in the java.net.Socket classes, as I am seeing the same results with the JIO connector, but not with APR(cause APR allocates mem using pools) Btw, had to put in the byte[] buffer back into the InternalNioOutputBuffer.java, ByteBuffers are way to slow. With APR, I think the connections might be lingering to long as eventually, during my test, it stop accepting connections. Usually around the 89th iteration of the test. I'm gonna keep working on this for a bit, as I think I am getting to a point with the NIO connector where it is a viable alternative. Filip
Re: svn commit: r469665 - /tomcat/connectors/trunk/jk/native/common/jk_map.c
Hi Bill, Bill Barker schrieb: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ... @@ -68,7 +62,6 @@ c = (unsigned int)*++k;\ checksum |= c; \ } \ -checksum = CASE_MASK; \ } This isn't very safe on machines that care about alignment (e.g. Sparc) :(. You mean the original line? The patch deletes the line. What's unsafe concerning alignment in the code after the patch? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r471309 - in /tomcat/container/tc5.5.x: catalina/src/share/org/apache/catalina/session/StandardSession.java webapps/docs/changelog.xml
Hi, Sandy McArthur schrieb: The way it works is the StandardSessionFacade is referenced like it was with the facade field in StandardSession and a WeakReference to the StandardSessionFacade is added the the field facadeReference. After the maxInactiveInterval the facade field is set to null. Next time the garbage collector it should break the WeakReference and the next time the StandardSession is checked to see if it is still valid, it will be expired. I think session expiration neeeds to be done with some quality of service. Of course we don't aim at immediate expiration, but I think we should prevent getting worse than the default of 1 minute granularity we have at the moment (plus configurable). If we depend on GC for session expiration, the quality of this service is out of our control. I can easily imagine the relvant objects getting moved to the tenured space, which will be subject to GC very rarely (like every hour or only once a day). And such behaviour is not wrong, instead one should try to configure the new generation and the semi spaces to keep GC on the tenured space very low. ... If a request for the session comes in after the maxInactiveInterval but before the WeakReference is broken the facade field will be updated with the value of the weak reference to prevent the session expiration. Is that good? It sounds like: great, if the session is not expired and the user is coming back he will love to find his session is still there. But: if it's online banking and it's not really the user, they'll not like the idea of your session timeout expired long ago, but you can still use the session. So in my opinion we should not make session expirration dependant on GC runs. GC invocations are totally out of our control and major GC changes are to be expected. Session expiration needs to be done with a defined quality of service. Regards, Rainer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJP flush packets?
Hi, follow the list. I expect, that we will prepare 1.2.20 for release during this month. Regards, Rainer Sven Köhler schrieb: i see, you're developing Tomcat 6.0. Will Tomcat 6.0 send flush packets, when the flush()-method of the OutputStreams or the Writers are called? Yes. It's done in a way that is backward compatible. When out.flush() is called an empty data packet is sent. Did it really need to be done like that? :-( Well, not matter how, but it was done, so it's a reason to be happy :-) It's something really needed by mod_proxy_ajp, mod_jk, and so on to property transport flushes to. The implementation is in the SVN both for mod_jk and mod_proxy_ajp. You will have to wait for the next release (mod_jk 1.2.20) if you don't wish to use the SVN builds. Thanks for the hints! So i will wait for mod_jk 1.2.20. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: build faililng
Hi Filip, I think Mladen prepares for native 1.1.7. He updated the build.properties earlier today from 1.1.6 to 1.1.7. See: http://marc.theaimsgroup.com/?l=tomcat-devm=116342212016165w=2 and http://marc.theaimsgroup.com/?l=tomcat-devm=116324833720513w=2 It looks like you have fallen into a build black hole. Regards, Rainer Filip Hanik - Dev Lists wrote: testexist: [echo] Testing for /development/tomcat/tc6build/tc6.0.x/includes/tomcat-native-1.1.7/tomcat-native.tar.gz downloadfile: [mkdir] Created dir: /development/tomcat/tc6build/tc6.0.x/includes/tomcat-native-1.1.7 [get] Getting: http://archive.apache.org/dist/tomcat/tomcat-connectors/native/tomcat-native-1.1.7-src.tar.gz [get] To: /development/tomcat/tc6build/tc6.0.x/includes/tomcat-native-1.1.7/tomcat-native.tar.gz [get] Error opening connection java.io.FileNotFoundException: http://archive.apache.org/dist/tomcat/tomcat-connectors/native/tomcat-native-1.1.7-src.tar.gz [get] Error opening connection java.io.FileNotFoundException: http://archive.apache.org/dist/tomcat/tomcat-connectors/native/tomcat-native-1.1.7-src.tar.gz [get] Error opening connection java.io.FileNotFoundException: http://archive.apache.org/dist/tomcat/tomcat-connectors/native/tomcat-native-1.1.7-src.tar.gz [get] Can't get http://archive.apache.org/dist/tomcat/tomcat-connectors/native/tomcat-native-1.1.7-src.tar.gz to /development/tomcat/tc6build/tc6.0.x/includes/tomcat-native-1.1.7/tomcat-native.tar.gz BUILD FAILED /development/tomcat/tc6build/tc6.0.x/trunk/build.xml:541: The following error occurred while executing this line: /development/tomcat/tc6build/tc6.0.x/trunk/build.xml:535: Can't get http://archive.apache.org/dist/tomcat/tomcat-connectors/native/tomcat-native-1.1.7-src.tar.gz to /development/tomcat/tc6build/tc6.0.x/includes/tomcat-native-1.1.7/tomcat-native.tar.gz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- kippdata informationstechnologie GmbH Bornheimer Str. 33a 53111 Bonn Tel. 0228/98549-0 Fax 0228/98549-50 www.kippdata.de === kippdata informationstechnologie GmbH Bornheimer Str. 33a D-53111 Bonn Germany Tel. +49/228/98549-0 Fax +49/228/98549-50 www.kippdata.de - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Move all facade classes to a dedicated package
I added a comment concerning a little experiment I did to https://issues.apache.org/jira/browse/VELTOOLS-66 Regards, Rainer Darryl Miles schrieb: Remy Maucherat wrote: I disagree: if the security manager is there, then there should be no way to get the internal object. Yes. Maybe the framework is broken for not trying to reflect on the available interfaces for the subject instance. Maybe by default it should only fail terminally if it can't find anything it can grab hold of (concrete class, interface, etc...) and reflect on. Darryl - 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: svn commit: r452464 - /tomcat/connectors/trunk/jk/native/scripts/build/instdso.sh
Hello Jean-Frederic,
there is a problem with the instdso.sh you checked in. It removes a
couple of files at the end, including the mod_jk.la file. When we run
make install afterwards, apxs again tries to run instdso.sh from it's
apache installation and complains about the missing mod_jk.la.
I compared the instdso.sh with the ones in Apache httpd 2.0 and 2.3 and
they both do not have the 4 remove statements included in the mod_jk one.
Are they needed? Could we just remove those?
Regards,
Rainer
[EMAIL PROTECTED] wrote:
Author: jfclere
Date: Tue Oct 3 05:52:21 2006
New Revision: 452464
URL: http://svn.apache.org/viewvc?view=revrev=452464
Log:
libtool is not able to install on HP-UX, the Apache httpd script here does it.
Added:
tomcat/connectors/trunk/jk/native/scripts/build/instdso.sh (with props)
Added: tomcat/connectors/trunk/jk/native/scripts/build/instdso.sh
URL:
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/scripts/build/instdso.sh?view=autorev=452464
==
--- tomcat/connectors/trunk/jk/native/scripts/build/instdso.sh (added)
+++ tomcat/connectors/trunk/jk/native/scripts/build/instdso.sh Tue Oct 3
05:52:21 2006
@@ -0,0 +1,96 @@
+#!/bin/sh
+#
+# Licensed to the Apache Software Foundation (ASF) under one or more
+# contributor license agreements. See the NOTICE file distributed with
+# this work for additional information regarding copyright ownership.
+# The ASF licenses this file to You under the Apache License, Version 2.0
+# (the License); you may not use this file except in compliance with
+# the License. You may obtain a copy of the License at
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing, software
+# distributed under the License is distributed on an AS IS BASIS,
+# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+# See the License for the specific language governing permissions and
+# limitations under the License.
+#
+#
+# instdso.sh - install Apache DSO modules
+#
+# we use this instead of libtool --install because:
+# 1) on a few platforms libtool doesn't install DSOs exactly like we'd
+#want (weird names, doesn't remove DSO first)
+# 2) we never want the .la files copied, so we might as well copy
+#the .so files ourselves
+
+if test $# != 3; then
+echo wrong number of arguments to instdso.sh
+echo Usage: instdso.sh SH_LIBTOOL-value dso-name path-to-modules
+exit 1
+fi
+
+SH_LIBTOOL=`echo $1 | sed -e 's/^SH_LIBTOOL=//'`
+DSOARCHIVE=$2
+DSOARCHIVE_BASENAME=`basename $2`
+TARGETDIR=$3
+DSOBASE=`echo $DSOARCHIVE_BASENAME | sed -e 's/\.la$//'`
+TARGET_NAME=$DSOBASE.so
+
+SYS=`uname -s`
+
+if test $SYS = AIX
+then
+# on AIX, shared libraries remain in storage even when
+# all processes using them have exited; standard practice
+# prior to installing a shared library is to rm -f first
+CMD=rm -f $TARGETDIR/$TARGET_NAME
+echo $CMD
+$CMD || exit $?
+fi
+
+CMD=$SH_LIBTOOL --mode=install cp $DSOARCHIVE $TARGETDIR/
+echo $CMD
+$CMD || exit $?
+
+if test $SYS = OS/2
+then
+# on OS/2, aplibtool --install doesn't copy the .la files we can't
+# rename DLLs to have a .so extension or they won't load so none of the
+# steps below make sense.
+exit 0
+fi
+
+if test -s $TARGETDIR/$DSOARCHIVE_BASENAME
+then
+ DLNAME=`sed -n /^dlname=/{s/.*='\([^']*\)'/\1/;p;}
$TARGETDIR/$DSOARCHIVE_BASENAME`
+ LIBRARY_NAMES=`sed -n /^library_names/{s/library_names='\([^']*\)'/\1/;p;}
$TARGETDIR/$DSOARCHIVE_BASENAME`
+ LIBRARY_NAMES=`echo $LIBRARY_NAMES | sed -e s/ *$DLNAME//g`
+fi
+
+if test -z $DLNAME
+then
+ echo Warning! dlname not found in $TARGETDIR/$DSOARCHIVE_BASENAME.
+ echo Assuming installing a .so rather than a libtool archive.
+ exit 0
+fi
+
+if test -n $LIBRARY_NAMES
+then
+for f in $LIBRARY_NAMES
+do
+rm -f $TARGETDIR/$f
+done
+fi
+
+if test $DLNAME != $TARGET_NAME
+then
+mv $TARGETDIR/$DLNAME $TARGETDIR/$TARGET_NAME
+fi
+
+rm -f $TARGETDIR/$DSOARCHIVE_BASENAME
+rm -f $TARGETDIR/$DSOBASE.a
+rm -f $TARGETDIR/lib$DSOBASE.a
+rm -f $TARGETDIR/lib$TARGET_NAME
+
+exit 0
Propchange: tomcat/connectors/trunk/jk/native/scripts/build/instdso.sh
--
svn:executable = *
-
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: svn commit: r452464 - /tomcat/connectors/trunk/jk/native/scripts/build/instdso.sh
Hello again,
I got the argument wrong, but there is still a problem, so I need to
-1 (veto)
your commit to the Makefile.in. The instdso.sh from apache httpd also
has the remove lines, but they use it in a different situation, ie when
they want to install the shared lib into the modules directory. Then it
does make sense to not also copy the *.la.
Here the instdso is being called to simply convert *.la to *.so, and
that's where we still need the *.la.
You didn't give details, which original problem you tried to solve.
Maybe we can find a better solution. The situation as it is at the
moment is a release show stopper (and I plan to start releasing next week).
Regards,
Rainer
Rainer Jung schrieb:
Hello Jean-Frederic,
there is a problem with the instdso.sh you checked in. It removes a
couple of files at the end, including the mod_jk.la file. When we run
make install afterwards, apxs again tries to run instdso.sh from it's
apache installation and complains about the missing mod_jk.la.
I compared the instdso.sh with the ones in Apache httpd 2.0 and 2.3 and
they both do not have the 4 remove statements included in the mod_jk one.
Are they needed? Could we just remove those?
Regards,
Rainer
[EMAIL PROTECTED] wrote:
Author: jfclere
Date: Tue Oct 3 05:52:21 2006
New Revision: 452464
URL: http://svn.apache.org/viewvc?view=revrev=452464
Log:
libtool is not able to install on HP-UX, the Apache httpd script here
does it.
Added:
tomcat/connectors/trunk/jk/native/scripts/build/instdso.sh (with
props)
Added: tomcat/connectors/trunk/jk/native/scripts/build/instdso.sh
URL:
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/scripts/build/instdso.sh?view=autorev=452464
==
--- tomcat/connectors/trunk/jk/native/scripts/build/instdso.sh (added)
+++ tomcat/connectors/trunk/jk/native/scripts/build/instdso.sh Tue
Oct 3 05:52:21 2006
@@ -0,0 +1,96 @@
+#!/bin/sh
+#
+# Licensed to the Apache Software Foundation (ASF) under one or more
+# contributor license agreements. See the NOTICE file distributed with
+# this work for additional information regarding copyright ownership.
+# The ASF licenses this file to You under the Apache License, Version
2.0
+# (the License); you may not use this file except in compliance with
+# the License. You may obtain a copy of the License at
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing, software
+# distributed under the License is distributed on an AS IS BASIS,
+# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied.
+# See the License for the specific language governing permissions and
+# limitations under the License.
+#
+#
+# instdso.sh - install Apache DSO modules
+#
+# we use this instead of libtool --install because:
+# 1) on a few platforms libtool doesn't install DSOs exactly like we'd
+#want (weird names, doesn't remove DSO first)
+# 2) we never want the .la files copied, so we might as well copy
+#the .so files ourselves
+
+if test $# != 3; then
+echo wrong number of arguments to instdso.sh
+echo Usage: instdso.sh SH_LIBTOOL-value dso-name path-to-modules
+exit 1
+fi
+
+SH_LIBTOOL=`echo $1 | sed -e 's/^SH_LIBTOOL=//'`
+DSOARCHIVE=$2
+DSOARCHIVE_BASENAME=`basename $2`
+TARGETDIR=$3
+DSOBASE=`echo $DSOARCHIVE_BASENAME | sed -e 's/\.la$//'`
+TARGET_NAME=$DSOBASE.so
+
+SYS=`uname -s`
+
+if test $SYS = AIX
+then
+# on AIX, shared libraries remain in storage even when
+# all processes using them have exited; standard practice
+# prior to installing a shared library is to rm -f first
+CMD=rm -f $TARGETDIR/$TARGET_NAME
+echo $CMD
+$CMD || exit $?
+fi
+
+CMD=$SH_LIBTOOL --mode=install cp $DSOARCHIVE $TARGETDIR/
+echo $CMD
+$CMD || exit $?
+
+if test $SYS = OS/2
+then
+# on OS/2, aplibtool --install doesn't copy the .la files we can't
+# rename DLLs to have a .so extension or they won't load so none
of the +# steps below make sense.
+exit 0
+fi
+
+if test -s $TARGETDIR/$DSOARCHIVE_BASENAME
+then
+ DLNAME=`sed -n /^dlname=/{s/.*='\([^']*\)'/\1/;p;}
$TARGETDIR/$DSOARCHIVE_BASENAME`
+ LIBRARY_NAMES=`sed -n
/^library_names/{s/library_names='\([^']*\)'/\1/;p;}
$TARGETDIR/$DSOARCHIVE_BASENAME`
+ LIBRARY_NAMES=`echo $LIBRARY_NAMES | sed -e s/ *$DLNAME//g`
+fi
+
+if test -z $DLNAME
+then
+ echo Warning! dlname not found in $TARGETDIR/$DSOARCHIVE_BASENAME.
+ echo Assuming installing a .so rather than a libtool archive.
+ exit 0
+fi
+
+if test -n $LIBRARY_NAMES
+then
+for f in $LIBRARY_NAMES
+do
+rm -f $TARGETDIR/$f
+done
+fi
+
+if test $DLNAME != $TARGET_NAME
+then
+mv $TARGETDIR/$DLNAME $TARGETDIR/$TARGET_NAME
+fi
+
+rm -f $TARGETDIR/$DSOARCHIVE_BASENAME
+rm -f $TARGETDIR/$DSOBASE.a
+rm
Re: suggestion about new loadbalancing method of mod_jk
Hi Takayuki,
Thank you. I committed your suggested patch. It will be released with
version 1.2.20, which should be available for tests in a few days.
I added a couple of warnings to the documentation:
Please note, that session stickyness and perfect load balancing are
conflicting targets, especially when the number
of sessions is small, or the usage of sessions is extremely varying
For huge numbers of sessions this usually is not a problem.
Because the balancer does not keep any state, it actually does not know
the number of sessions. Instead it counts each request without a session
cookie or URL encoding as a new session. This method will neither
know, when a session is being invalidated, nor will it correct its load
numbers according to session timeouts or worker failover. This method
should be used, if sessions are your limiting resource, e.g. when you
only have limited memory and your sessions need a lot of memory.
I would in general *not* recommend this method to evenly distribute
requests. Somehow I would still like to know, why the requests in your
case have not been distributed evenly with the Request method. Could it
be, that only few sessions were active, and your client programm didn't
have a high degree of parallelity, concerning the used sessions?
You might know, that mod_jk can now log additional load balancing
information in your apache access log, so that we get a better idea, how
the balancer made its decisions. To collect some more runtime
information, please add the following to your Apache LogFormat:
\%{Set-Cookie}i\ \%{Cookies}o\ %{JK_WORKER_NAME}n %{JK_WORKER_TYPE}n
%{JK_REQUEST_DURATION}n %{JK_LB_FIRST_NAME}n %{JK_LB_FIRST_VALUE}n
%{JK_LB_FIRST_ACCESSED}n %{JK_LB_FIRST_ERRORS}n %{JK_LB_FIRST_BUSY}n
%{JK_LB_FIRST_STATE}n %{JK_LB_LAST_NAME}n %{JK_LB_LAST_VALUE}n
%{JK_LB_LAST_ACCESSED}n %{JK_LB_LAST_ERRORS}n %{JK_LB_LAST_BUSY}n
%{JK_LB_LAST_STATE}n %D
The STATE fields will show, if during balancing errors occured, so that
mod_jk disabled a member worker. The VALUE field shows us the load
factor at the time the decision has been made. And the ACCESSED field is
the number of requests handled since last reload. FIRST differs from
LAST, in case the first chosen worker had a problem and the load
balancer needed to try other ones.
Regards,
Rainer
Takayuki Kaneko schrieb:
Hi,
I'm evaluating mod_jk1.2.19 with 8 Tomcat application servers.
I found problems about loadbalancing method.
* method=Request
Suddenly, balancing wouldn't be equally.
When the requests were concentrated a particular Tomcat server (e.g.
tomcat1). It was caused by sticky session when a particular user
accessed a lot, user accessed the page that contains a lot of images,
and so on.
After that, mod_jk concentrated the requests to other Tomcat servers.
So tomcat1 would have idle time.
Here is the data of CPU usage when I ran the test with 2 Tomcat servers.
http://jbento.sourceforge.net/modjk/CLIENT_200.html
Sometime, tomcat1 had high CPU usage, but tomcat2 had idle.
They worked alternately.
* method=Busyness
Balancing cannot be equally when Apache has been restarted.
Because mod_jk has the offset value that is used to set the start
point of searching endpoints on each Apache process. So, each process
selects a particular Tomcat server that is the top of the endpoint
list.
Here is the summary of jk-status report.
Name V Acc Err
kuma03 0 9075 0
kuma04 0 10013 0
kuma05 0 9199 0
kuma06 0 8996 0
kuma07 0 8914 0
kuma08 0 7043 0
kuma09 0 6234 0
kuma10 0 5260 0
kuma10 is the bottom of endpoint list and it didn't work so much.
--
So, in my opinion, lb_value should be counted up when the request
doesn't have the sessionid. It is advisability because the sticky
session causes the status concentrated.
I made the patch to make the new method Session.
I run the tests and the requests were balanced equally.
Thanks.
-Takayuki
-
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: svn commit: r476817 - /tomcat/connectors/trunk/jk/native/common/jk_ajp_common.c
Mladen Turk schrieb:
[EMAIL PROTECTED] wrote:
((rc = ajp_connection_tcp_send_message(ae, op-request,
l)) != JK_TRUE)) {
if (rc != JK_FATAL_ERROR) {
-jk_log(l, JK_LOG_INFO,
+jk_log(l, JK_LOG_DEBUG,
(%s) error sending request. Will try another
pooled connection,
-1. Please change back to INFO because this is *not* part of
the normal operation.
If someone hates those messages he can increase the log level to warn.
That's true. But the message shows up, e.g. when the backend closed the
connection, and mod_jk just realized that via jk_is_socket_connected().
But OK, I'll revert.
@@ -1219,8 +1219,8 @@
jk_log(l, JK_LOG_INFO,
(%s) all endpoints are disconnected or dead,
ae-worker-name);
-JK_TRACE_EXIT(l);
-return JK_FALSE;
+jk_log(l, JK_LOG_INFO,
+ Increase the backend idle connection timeout or
the connection_pool_minsize);
I'm not sure about that either.
This is where retries should go into the action and be used for sticky
sessions.
If the sticky sessions are false, there might be other workers in the lb
that
are not disconnected.
OTOH if the retries is larger then 1 (2 is default) the same worker will be
used and the new connection will be made.
Yes, but in this case I think it's not really a retry. Assume prefork
model and the remote backend closed the connection. We will come very
often here and we should at least try once to open a new connection - as
we do after restarting the web server. In my opinion, this is not yet a
retry situation. I understand your argument concerning using a working
backend instead of connecting again, but we are far from that even with
the previous code. If maintenance closes the connections, then we will
nevertheless open new ones. This fragment here only comes into play, if
the backend closed the connections (timeout or failure). So I would
prefer keeping this change.
Regards,
Mladen.
Regards,
Rainer
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] Change in behaviour of uriworkermap.properties
Henri Gomez schrieb: Why not just extends current jkstatus ? Mapping rules are kept process local. They are only shared, because the first process generates them and afterwards all other processes inherit them during fork. To make the rules manageable via jkstatus (everyone wants that, me too; it's a much bigger task) we need to do two things: - use shared memory at least to exchange information about changes to maping rules, so that the process that handles the jkstatus request is able to distribute the changes. - also we need to think about virtual hosts: mapping rules are per virtual host. At the moment, if you call jkstatus, you will only see the rules defined for the virtual host, which you called with jkstatus. If you want to have a central administration point, jkstatus must go through all vhosts starting from the main server to produce the list, and if you change something it might need to change it in a vhost that's different from the vhost, the request runs in. This is no argument, that it is very hard to make these changes. It's simply not in scope for the next release, which should get ready in very few days, because we had a couple of nice bug fixes since 1.2.19. Regards, Rainer 2006/11/21, Rainer Jung [EMAIL PROTECTED]: Jean-frederic Clere schrieb: On Tue, 2006-11-21 at 06:52 +0100, Mladen Turk wrote: Rainer Jung wrote: E.g. if one empties the uriworkermap.properties, reloading it does not change the internal mount list. Temporarily adding and later removing an entry will not remove the entry. That's the entire point. But this is not what a user expects from a change in a list. Once new entry is added it will be there for the server lifetime. Of course it can be disabled with minus prefix. If one adds the mount point and then deletes it, other child processes might not pick that up, but that's not how they suppose to work. Deletion *must* be done only by prefixing the mount points with minus. I'm not even sure why I allow to have the new mounts at the first place. OK, but you did. And my proposal comes in, because I want to fix this behaviour exactly becauswe of the case, are adding and deleting rules. One could live with that (after we improve the docs). Sure. The entire idea of reloading a uriworkermap.properties was to temporary disable some pre-existing mount. I understand, but it can be used in a much more powerful way. It's an external file with an easy syntax, so external monitor and manage scripts can easily manipulate it's contents. Anything else should be handled via graceful restart. BTW, this was added only to help the IIS that doesn't have the graceful restart concept. Graceful restarts can produce hanging processes under heavy load. You'll notice slots in state G or L in the server-status. I don't like the idea of splitting the static and dynamic mount points. The proper way to go would be to add the second shared memory (database like) that would contain the mount points with options to manage that via jkstatus. Anything else IMHO is useless, because it can be done via simple restart, if one needs to add/remove the whole bunch of new mounts in frequent way. Yep. Static configuration is just a dynamic configuration that never changes. The right way to go is to have the configuration in shared memory the complex stuff is how to update it. I am trying to get something similar to work on mod_proxy and I need an external process to update the shared memory. That using shared memory to share the mapping rules and the changes is what I wrote too. And I will investigate this further. My suggestion is to make the current behaviour of uriworkermap.properties reloading easier to understand for the users. This is something I can easily do for the next release. Handling the rules via shared memory would definitely have to wait at least for one more release. Cheers Jean-Frederic Regards, Mladen. Regards, Rainer - 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: suggestion about new loadbalancing method of mod_jk
Takayuki Kaneko schrieb: Thank you for pointing out! I'll try this setting next time. Actually, I patched mod_jk to output the every worker's lb_value on every requests. In my analysis, it was the following situation. (Of cause the numbers of lb_value aren't real.) * before test tomcat1 lb_value=0, tomcat2 lb_value=0 * run test and concentrated login requests, but they were distributed evenly tomcat1 lb_value=50, tomcat2 lb_value=50 * made difference **1 OK, what do you mean by made difference **1? What did the test do during that time? Is it clear, why the difference happened, like huge differences in requests per session? tomcat1 lb_value=300, tomcat2 lb_value=200 * concentrated login requests and all clients were distributed to tomcat2 tomcat1 lb_value=300, tomcat2 lb_value=300 * made bigger difference tomcat1 lb_value=300, tomcat2 lb_value=800 * repeat **1 with swapping tomcat1 and tomcat2 Depending on the answer to the question above: in most real live applications users don't send hundreds of requests per session and per minute. So a couple of busy sessions might send a few dozens of requests more in a minute. mod_jk divides the lb_value once a minute by 2 so that differences that happened in the past get more and more unimportant. If you do a synthetic test and hammer one session very fast, and then soon after you make a lot of logins, the in fact the session distribution will be uneven. --- I had another idea, the offset value should be shared among the apache processes with Busyness method. What do you think? The offset is used to increase the chance of every worker getting some request, so that you can detect failures even if the load is not very high. The most observed case is when users do simple tests by sending a couple of requests and then try to understand the load balancer decision. But: this case is somehow artificial and not really relevant for load balancing. Load balancing without load is not supposed to work great. With the busyness method, the low load situations happen more frequent, especially since people might use it for apps, where it is not that adequate. For usual apps with busyness, nearly all the time you will have all lb_values equal to zero (and few equals 1 where a request is running). In my opinion busyness is best, if parallelity is your limiting ressource, like e.g. long running downloads. But again: if the parallelity is very low, ie. low load, then you shouldn't really care about evenly distributed requests. If you choose busyness, your metric is parallelity and not accumulated requests. There is no mix. The algorithm would be more perfect, if we would share the offset. But there is a performance penalty for the shared offset. At the moment we keep more data shared, than necessary. It is really necessary for the lb_value, but lots of the others could be copied out of the shared memory, because they only change via reconfiguration (jkstatus et.). I think we will have more local copies in the future and in my opinion the benefit of a shred offset is not enough to justify the likely performance penalty. Regards, -Takayuki Regards, Rainer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tagging plans for mod_jk 1.2.20
Hi, I suggest to tag mod_jk 1.2.20 next weekend. There are a couple of additions to the status worker, and only small changes concerning the apache integration (env vars, JkOptions and virtual hosts) coming from me in the next days, but I would be ready to tag around saturday. Anyone else OK with that, or are there more outstanding changes, that should go into this release? Anything in the works concerning IIS 6? Regards, Rainer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tagging plans for mod_jk 1.2.20
Mladen Turk schrieb: Rainer Jung wrote: Hi, I suggest to tag mod_jk 1.2.20 next weekend. There are a couple of additions to the status worker, and only small changes concerning the apache integration (env vars, JkOptions and virtual hosts) coming from me in the next days, but I would be ready to tag around saturday. OK. Although I have to double check your changes to the first retry handling ;) Great, just let me know if you think we need more time. We don't want to break it because of a couple of days more time. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tagging plans for mod_jk 1.2.20
Henri Gomez wrote: Did you update the documentation concerning 'apache integrations' ? I'm in the middle of doing it. I added information about vhost support to the main table of apache configs (not yet committed) and I'll add a new page concerning uri mapping (mainly uriworkermap.properties) on the copnfig dir adding to workers.properties, Apache and IIS a fourth menu item. Regards 2006/11/23, Rainer Jung [EMAIL PROTECTED]: Mladen Turk schrieb: Rainer Jung wrote: Hi, I suggest to tag mod_jk 1.2.20 next weekend. There are a couple of additions to the status worker, and only small changes concerning the apache integration (env vars, JkOptions and virtual hosts) coming from me in the next days, but I would be ready to tag around saturday. OK. Although I have to double check your changes to the first retry handling ;) Great, just let me know if you think we need more time. We don't want to break it because of a couple of days more time. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
mod_jk environment variable handling in Apache
Henri Gomez wrote: I'm doing extensive use VirtualHost and no-jk directive on our Apache 2.0.x servers so I'm very carefull about any changes in these area. There is one strange thing concerning apache and JkEnvVar. The mod_jk code handles them, as if it would make sense to have the same env var multiple times, with different default values. More precisely it uses add table instead of set table when JkEnvVar is being processed (so appending duplicates) and it also uses overlay tables to merge between base and vhost, which again appends all the base values to the vhost. This doesn't seem to make sense, because a servlet request attribute can only have one value. I would like to clean that up, so that later calls to JkEnvVar for the same variable overwrites earlier ones (using set table instead of add table), and all calls in vhost overwrite the ones in base (merging more carefully than table overlay does). Do you know any use case, where the current behaviour makes sense? I expect, that nobody really cared, because a config where the same env var is used with multiple default values doesn't really look reasonable. Regards, Rainer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
State of affairs for mod_jk 1.2.20
For those who want to test: I committed far the most part of what I planned to improve. The rest of the things, I want to work on (depending on time) concerns only much smaller code areas: - checking consistency for logging/%R/NOTES concerning worker name versus jvmRoute - XML and txt mime type enhancements in jk status - 2 more notes for logging (busy+max_busy of the lb itself) - improve envvar handling in apache wrt. duplicate configuration - document max_packet_size - write a doc page concerning mapping rules, uriworkermap etc. - write a doc page about jk status Regards, Rainer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r478809 - /tomcat/connectors/trunk/jk/native/common/jk_lb_worker.c
Hi Mladen,
very nice idea making things easier for users. I like it. But dots are
standard separation characters in host names and host names might not be
totally uncommon as jvm routes. I know, that they can be symbolic, but
we might break configs or deny using such a simple way of matching routes.
Since the feature jvm_route is not very old, not many people will use
it, but still: do you think another character could be better, by not
conflicting with fully qualified host names. E.g. what about the pipe
symbol, an at sign, a slash or a colon. Maybe the colon or the at sign
would be also easy to remember.
Regards,
Rainer
[EMAIL PROTECTED] schrieb:
Author: mturk
Date: Fri Nov 24 01:00:12 2006
New Revision: 478809
URL: http://svn.apache.org/viewvc?view=revrev=478809
Log:
Setup domain name from route name if the route name
contains dot ('.'). The first part before dot will
be used as domain name. This eases the domain sticky
session configuration.
worker.xxx.route=domain1.nonde1 is equivalent to
worker.xxx.route=domain1.nonde1
worker.xxx.domain=domain1
Modified:
tomcat/connectors/trunk/jk/native/common/jk_lb_worker.c
Modified: tomcat/connectors/trunk/jk/native/common/jk_lb_worker.c
URL:
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/common/jk_lb_worker.c?view=diffrev=478809r1=478808r2=478809
==
--- tomcat/connectors/trunk/jk/native/common/jk_lb_worker.c (original)
+++ tomcat/connectors/trunk/jk/native/common/jk_lb_worker.c Fri Nov 24
01:00:12 2006
@@ -1199,6 +1199,17 @@
close_workers(p, i, l);
}
else {
+/* Update domain names if jvm_route contains period '.' */
+for (i = 0; i num_of_workers; i++) {
+if (!p-lb_workers[i].s-domain[0]) {
+char * id_domain =
strchr(p-lb_workers[i].s-jvm_route, '.');
+if (id_domain) {
+*id_domain = '\0';
+strcpy(p-lb_workers[i].s-domain,
p-lb_workers[i].s-jvm_route);
+*id_domain = '.';
+}
+}
+}
for (i = 0; i num_of_workers; i++) {
if (JK_IS_DEBUG_LEVEL(l)) {
jk_log(l, JK_LOG_DEBUG,
-
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: State of affairs for mod_jk 1.2.20
Hi Mladen, Mladen Turk schrieb: Rainer Jung wrote: For those who want to test: I committed far the most part of what I planned to improve. Thanks Rainer, the patches you made are really great! I think we'll have a best ever mod_jk. Thanks for the credits, I hope they work. However I still have doubts about you patch: @@ -1219,8 +1219,8 @@ jk_log(l, JK_LOG_INFO, (%s) all endpoints are disconnected or dead, ae-worker-name); -JK_TRACE_EXIT(l); -return JK_FALSE; +jk_log(l, JK_LOG_INFO, + Increase the backend idle connection timeout or the connection_pool_minsize); The patch you made is IMHO dubious. I agree it works for standard sittuations when backend Tomcat closes the connection, but it fails when the backend is dead or (the major problem) when the firewall closes the connection between them. With your patch we loose the option to have a session-free nodes. There is simply no chance to have a lb that will go to another node if the existing one fails. OK, I'll think about that in the next hour and then comment. Four eyes are much better than 2 ... Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: State of affairs for mod_jk 1.2.20
Hi Mladen, I read our code as follows: in any case where a function in the while loop does produce an error, we close the connection afterwards: - if jk_is_socket_connected() fails, we do it explicitely via jk_close_socket() - if ajp_handle_cping_cpong() fails, we don't go into ajp_connection_tcp_send_message() and call ajp_next_connection(), which as a side effect closes the old connection via jk_close_socket() - if ajp_connection_tcp_send_message() fails, and we don't get a JK_FATAL_ERROR, again the conn is closed in ajp_next_connection() - if it returns with JK_FATAL_ERROR, we close explicitely with jk_close_socket() So a hanging tomcat, cut off connections by a firewall, or closed conns by the remote side all behave the same (I assume the extreme case, that all conns are concerned): we end the loop, and all conns have beend closed and replaced by JK_INVALID_SOCKET. No the question is: how to proceed? If we had known before, that no connections are established we would have passed the wile loop and directly tried to establish a new connection. The difference in our situation is, that we know we had to close conns, but we don't know the reason. If we return directly, then the first try has been burned by invalidating all established connections, and the second (re)try will start from a clean, no connection state, by trying to connect. Both tries will be handled inside the ajp code, no load balancer will know about that. After the failure of the second try we go up the stack, and if there's a load balancer it will try another worker. The load balancer counts it's own retries totally independant of the ones from the ajp workers. In my opinion the only change is: - old code: retries=2 means first try to close all conns and second try with new connection - new code: retries=2 means first try to close all conns and immediate new conn, second try a real retry. My concern is: if a user thinks he does not want a retry in the ajp worker (especially if he uses a load balancer), then I find it a little too fast to not connect once, if all established conns are broken. Concerning load balancing: the patch does not really change the interaction with an lb. It's only a question, after how man retries we break out of the service method of the ajp worker. That's internal to the ajp worker. It's code decides how early it fails and then the lb decides how to proceed. The lb retries are counted totally independently of the ajp retries. Session free node: I expect maintenance will close the conns, if the min size is 0. Concerning the code here: if the new connection also fails, then it would have also failed during in the old code during the second try. So I don't see a big difference. But maybe I overlooked something. I find this discussion helpful! Regards, Rainer Mladen Turk schrieb: Rainer Jung wrote: For those who want to test: I committed far the most part of what I planned to improve. Thanks Rainer, the patches you made are really great! I think we'll have a best ever mod_jk. However I still have doubts about you patch: @@ -1219,8 +1219,8 @@ jk_log(l, JK_LOG_INFO, (%s) all endpoints are disconnected or dead, ae-worker-name); -JK_TRACE_EXIT(l); -return JK_FALSE; +jk_log(l, JK_LOG_INFO, + Increase the backend idle connection timeout or the connection_pool_minsize); The patch you made is IMHO dubious. I agree it works for standard sittuations when backend Tomcat closes the connection, but it fails when the backend is dead or (the major problem) when the firewall closes the connection between them. With your patch we loose the option to have a session-free nodes. There is simply no chance to have a lb that will go to another node if the existing one fails. 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: svn commit: r478809 - /tomcat/connectors/trunk/jk/native/common/jk_lb_worker.c
Gotcha. OK. Mladen Turk schrieb: Rainer Jung wrote: Hi Mladen, very nice idea making things easier for users. I like it. But dots are standard separation characters in host names and host names might not be totally uncommon as jvm routes. I know, that they can be symbolic, but we might break configs or deny using such a simple way of matching routes. The dot is fine because standard jvm route comes from worker name, and they simply cannot have a dot inside, because its a worker config separator. 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: State of affairs for mod_jk 1.2.20
OK, convinced. I'll change that tomorrow and add a respective note to the docs fpr ajp retries in relation to lb. Mladen Turk schrieb: Rainer Jung wrote: In my opinion the only change is: - old code: retries=2 means first try to close all conns and second try with new connection - new code: retries=2 means first try to close all conns and immediate new conn, second try a real retry. Right, and that is the problem. With retries=1 the old code would in case of connect failure go to the next worker in the lb, while in the new code it would first try to reconnect. Now, this is OK for sticky session, but if you have session replication there is simply no need to try to reconnect, because it will connect on the next election. What I'm saying is that right now we would always reconnect, and the user has no influence in that, while with default retries=2 he can set retries=1 and have that option. Of course there will be extra [info] lines in the log in that case. 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: svn commit: r478804 - /tomcat/connectors/trunk/jk/native/common/jk_ajp_common.c
Hi Mladen,
[EMAIL PROTECTED] schrieb:
@@ -1220,12 +1220,25 @@
...
/* Connect to the backend.
* This can be either uninitalized connection or a reconnect.
*/
if (ajp_connect_to_endpoint(ae, l) == JK_TRUE) {
+/* should we send a CPING to validate connection ? */
+if (ae-worker-connect_timeout 0) {
+if (ajp_handle_cping_cpong(ae,
+ae-worker-connect_timeout, l) == JK_FALSE) {
+/* Close the socket if unable to cping/cpong */
+jk_close_socket(ae-sd);
+ae-sd = JK_INVALID_SOCKET;
+JK_TRACE_EXIT(l);
+return JK_FALSE;
+}
+}
+
Cping/Cpong is already done inside ajp_connect_to_endpoint(), if it
fails we take the else part, that does the jk_close_socket. So I think
this would lead to a double cping/cpong after connect.
Regards,
Rainer
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: recovery_option 4 not fully implemented
Tim Whittington schrieb: The JK docs state: If the value 4 is added to the recovery options, the connection between the webserver and tomcat will be closed if the client connection to the webserver is terminated during the request/response cycle. This allows to inform the servlet engine about broken client connections during lengthy operations. This seems to imply that recovery_options=0 will reuse the connection if the only errors were client read/writes, which is not the case. The connection between the webserver and Tomcat is always closed on an error writing to a client though, and I'm fairly certain if there are client read errors. Since the only place that socket reuse is set to true is in the AJP end response, which is always after the client reads and writes are done in ajp_send_request or ajp_get_reply, and the end_response is never reached if there is a read/write error, there is no recovery of AJP connections. It's a little late in the evening, but I think I agree with you. The flag reuse is set to false at the beginning of service and is only set to true during the JK_AJP13_END_RESPONSE callback, but in any case we get a client read or write error we abort earlier. Mladen, do you agree? It appears that recovery_options=4 is redundant - am I missing something? If the AJP protocol handlers were coded to reset the protocol stream on one of these errors to allow it to be reused, then this flag would come into play and would work as documented. tim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r479321 - /tomcat/connectors/trunk/jk/native/common/jk_util.c
Hi Mladen,
since this has already been out in the wild for a few month, I'd prefer
to add the old one to the deprecation list in jk_util.c and in the docs
and to have the get function fall back to the original one, if the new
attribute is empty (like for disable/stop - activation).
Regards,
Rainer
[EMAIL PROTECTED] schrieb:
Author: mturk
Date: Sun Nov 26 01:50:34 2006
New Revision: 479321
URL: http://svn.apache.org/viewvc?view=revrev=479321
Log:
Add simpler name for jvmRoute. Right now we use
jvm_rute. Allow having just route to be consistent
with domain and redirect params.
Modified:
tomcat/connectors/trunk/jk/native/common/jk_util.c
Modified: tomcat/connectors/trunk/jk/native/common/jk_util.c
URL:
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/common/jk_util.c?view=diffrev=479321r1=479320r2=479321
==
--- tomcat/connectors/trunk/jk/native/common/jk_util.c (original)
+++ tomcat/connectors/trunk/jk/native/common/jk_util.c Sun Nov 26 01:50:34
2006
@@ -66,6 +66,7 @@
#define STICKY_SESSION (sticky_session)
#define STICKY_SESSION_FORCE(sticky_session_force)
#define JVM_ROUTE_OF_WORKER (jvm_route)
+#define ROUTE_OF_WORKER (route)
#define DOMAIN_OF_WORKER(domain)
#define REDIRECT_OF_WORKER (redirect)
#define MOUNT_OF_WORKER (mount)
@@ -152,6 +153,7 @@
STICKY_SESSION,
STICKY_SESSION_FORCE,
JVM_ROUTE_OF_WORKER,
+ROUTE_OF_WORKER,
DOMAIN_OF_WORKER,
REDIRECT_OF_WORKER,
METHOD_OF_WORKER,
@@ -481,12 +483,18 @@
const char *jk_get_worker_jvm_route(jk_map_t *m, const char *wname, const
char *def)
{
+const char *rv;
char buf[1024];
if (!m || !wname) {
return NULL;
}
-MAKE_WORKER_PARAM(JVM_ROUTE_OF_WORKER);
-return jk_map_get_string(m, buf, def);
+MAKE_WORKER_PARAM(ROUTE_OF_WORKER);
+rv = jk_map_get_string(m, buf, def);
+if (!rv) {
+MAKE_WORKER_PARAM(JVM_ROUTE_OF_WORKER);
+rv = jk_map_get_string(m, buf, def);
+}
+return rv;
}
const char *jk_get_worker_domain(jk_map_t *m, const char *wname, const char
*def)
-
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: [TC6] Minimum coding style
From a very personal view I'm tempted to share Mladens dislike of trailing spaces. If I try to express, why I don't like them, then it all comes back to diffs. Trailing spaces increase the potential of diff lines with no functional differences. Nevertheless one wastes time to check very carefully, if there's really no functional change in them. And why do trailing spaces produce diff deltas? I think most of the time because of copy and paste. Copy and paste is able to remove trailing spaces, when you do it from a screen output of code. So you attempt to clone code (I know, we never want to do that) and the result looks the same, but in fact it will produce diff lines because of whitespace differences. Omitting all whitespace differences from the subversion diff mails is something I really find dangerous, because there are cases, where you need to see whitespace changes. Removing all trailing whitespace from Java source files might be doable by a script, although I didn't think about that deeply enough. All in all I would be +0 for a policy of not introducing new trailing whitespace (as long as we don't shoot at each other if it happens nevertheless, but we agree, that we should avoid it) and no idea about the best way of cleaning up existing code (once per script or during the usual editing process over time). Regards, Rainer Mladen Turk schrieb: Henri Gomez wrote: I remember the cold days of the 'Tab brigade' :) Right. Anyhow, the point of my post was 'minimal', and removing the trailing spaces. It seems that the trailing spaces are very important, so fine with me. Cheers, 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: adding communication between mod_jk and servlet code
Hello Chris, thanks for your original Busyness contribution. I'm not a big fan of transporting container meta information on top of usual request/response traffic. I know we don't have anything else we could easily use yet. 1) There is no built in protocol support in ajp13 for other types of information. There is no effort in realising ajp14 at the moment. 2) There is no easy way of supporting parallel management activity besides normal workload (creating management threads etc.), because we are multi-platform and multi-webserver. I'm thinking about adding more functionality to the status worker as an interesting compromise: - the status worker can run in parallel to usual request load. It needs to be triggered externally, but at least we don't pack something on top of every request handling. - the status worker can change state in the shared memory segment we use. Any load balancer already uses this state. So one could think about: - adding a backend status URL to each load balancer (configuration) - adding the ability to send requests via ajp13 to backends from inside the status worker (we have to fake the request) and to extract information from the response - defining a good response content scheme - reacting on the response by disabling/stopping/erring/reenabling etc. load balancer members - defining request parameters (cmd=probe...) to the status worker, that trigger the request to every member of a load balancer and the corresponding action depending on the response How does that sound? Regards, Rainer Chris Lamprecht wrote: Hi all, I previously submitted the lb 'busyness' patch for mod_jk, and it has worked well for us. Now we need some additional functionality from mod_jk and I'd like to get feedback here first before I start patching. I'd prefer to implement something that is generally useful to others, and submit the patch, so it becomes part of the mod_jk codebase. First, the problem. Currently there isn't any direct way for a servlet to tell mod_jk that it should be marked as being in 'Error' state (as being down). We have a backend HTTP service that requires high availability. If the servlet detects that something is wrong, it should take itself out of the mod_jk load balancer, at least temporarily. There are two ways I can think of to accomplish this right now. The first, which I've done, is set the reply_timeout to a fairly low value, like 4000ms, and then make the servlet intentionally sleep for 5000ms to cause it to go into Error state. This works, but having the reply_timeout so low is a risk -- if the backend servers are slow for some reason (copying large files, etc), they can all be marked as down -- oops. The second method, which I have not tried, is to have the servlet do a GET request to the mod_jk JkStatus page, to take itself out of rotation. While it may work, I just don't have good feelings about this method. If anyone has other suggestions on ways for a servlet to force itself to be marked as in 'Error' state, please reply. So, I looked through mod_jk code hoping that I could have the servlet throw an HTTP 50x error that mod_jk would interpret as down, but no such luck. There has been talk before about writing a meta communication layer between servlets and mod_jk. This could open up the doors to some cool things: Servlets could provide JK with load information, average response times, available webapp contexts, etc. See this thread: http://mail-archives.apache.org/mod_mbox/httpd-dev/200606.mbox/[EMAIL PROTECTED] For my current purposes, I just need the servlet to tell mod_jk even though I'm available, mark me as in Error state!. How should we do this? Using a hidden HTTP response header might work for communicating general strings, or returning certain reserved HTTP responses (HTTP 599 = error, etc) -- these are two options that come to mind. I'm willing to implement and test the mods, including under heavy load. Thanks, Chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Smooth applications migration in a J2EE cluster [mod_jk]
Mladen Turk wrote: Anthony Vromant wrote: Would it be possible to integrate such a feature in the original mod_jk ? If yes, we may contribute to the development by providing our code. There is no need to ask something like that. Just like for any other patch bring in the code, and we'll discuss, but it cannot be answered in advance. Anyhow, according to the description it looks very interesting. Regards, Mladen. Exactly the same from me. The upcoming release 1.2.20 will already include a lot of improvements in the jk status worker and we all think, that managing changes in a distributed 24x7 system already is a very important topic. Waiting for your proposals :) Rainer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Smooth applications migration in a J2EE cluster [mod_jk]
Hi Anthony, since your oce is based on 1.2.15 first the information for you, that between 1.2.15 and the released 1.2.19 there were a lot of features added. No old features has been dropped, so it should be feature compatible with 1.2.15. You can look at the changelog http://tomcat.apache.org/connectors-doc/changelog.html and maybe the easiest way is to scan the document http://tomcat.apache.org/connectors-doc/config/workers.html and for Apache http://tomcat.apache.org/connectors-doc/config/apache.html resp. for IIS http://tomcat.apache.org/connectors-doc/config/iis.html about new parameters, which you didn't know before. There are also hints in the docs, which of the params have been added in which version. Concerning 1.2.20 I'll make a tarball for testing including the docs most likely tonight. We changed a bit more, than was planned, so we give people a couple of days to report problems early, before we tag the release. Again, all changes will be contained in the configuration reference guide. Regards, Rainer Anthony Vromant wrote: Rainer Jung wrote: Mladen Turk wrote: Anthony Vromant wrote: Would it be possible to integrate such a feature in the original mod_jk ? If yes, we may contribute to the development by providing our code. There is no need to ask something like that. Just like for any other patch bring in the code, and we'll discuss, but it cannot be answered in advance. Anyhow, according to the description it looks very interesting. Regards, Mladen. Exactly the same from me. The upcoming release 1.2.20 will already include a lot of improvements in the jk status worker and we all think, that managing changes in a distributed 24x7 system already is a very important topic. Waiting for your proposals :) Rainer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Glad to note that you are interested in this topic. I propose to send you as soon as possible a HTTP link towards a Flash presentation of our prototype. Thus you'll have a good overview of the feature. For the source code, we have to do some 'cleaning' work before being able to submit it to you. Can you tell me where to find information about new features of mod_jk 1.2.20 ? For your information, our prototype is built from mod_jk 1.2.15. We could bring it to the 1.2.20. Regards. Anthony Vromant http://jonas.objectweb.org Bull, Architect of an Open World TM http://www.bull.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- kippdata informationstechnologie GmbH Bornheimer Str. 33a 53111 Bonn Tel. 0228/98549-0 Fax 0228/98549-50 www.kippdata.de - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r483021 - in /tomcat/connectors/trunk/jk: native/common/ xdocs/config/ xdocs/miscellaneous/
Hi Mladen,
the different notations confuse me: some parts use retry_on_status,
and some http_status_fail. I think the implementation does fail on
configured status code, whereas the name of the config param suggests
retry=do not fail on configured status code.
I would suggest, to rename the config param (and the config function)
from retry_on_status to fail_on_status.
Regards,
Rainer
[EMAIL PROTECTED] wrote:
Author: mturk
Date: Wed Dec 6 02:54:08 2006
New Revision: 483021
URL: http://svn.apache.org/viewvc?view=revrev=483021
Log:
Added retry_on_status directive that can treat HTTP return codes as failures,
allowing loadbalancing in case of 503, etc.
Modified:
tomcat/connectors/trunk/jk/native/common/jk_ajp13.h
tomcat/connectors/trunk/jk/native/common/jk_ajp_common.c
tomcat/connectors/trunk/jk/native/common/jk_ajp_common.h
tomcat/connectors/trunk/jk/native/common/jk_service.h
tomcat/connectors/trunk/jk/native/common/jk_util.c
tomcat/connectors/trunk/jk/native/common/jk_util.h
tomcat/connectors/trunk/jk/xdocs/config/workers.xml
tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml
Modified: tomcat/connectors/trunk/jk/native/common/jk_ajp13.h
URL:
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/common/jk_ajp13.h?view=diffrev=483021r1=483020r2=483021
==
--- tomcat/connectors/trunk/jk/native/common/jk_ajp13.h (original)
+++ tomcat/connectors/trunk/jk/native/common/jk_ajp13.h Wed Dec 6 02:54:08 2006
@@ -44,6 +44,7 @@
#define JK_SERVER_ERROR (-5)
#define JK_CLIENT_RD_ERROR (-6)
#define JK_CLIENT_WR_ERROR (-7)
+#define JK_STATUS_ERROR (-8)
#define AJP13_MAX_SEND_BODY_SZ (DEF_BUFFER_SZ - 6)
#define AJP13_DEF_TIMEOUT (0) /* Idle timout for pooled connections
*/
Modified: tomcat/connectors/trunk/jk/native/common/jk_ajp_common.c
URL:
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/common/jk_ajp_common.c?view=diffrev=483021r1=483020r2=483021
==
--- tomcat/connectors/trunk/jk/native/common/jk_ajp_common.c (original)
+++ tomcat/connectors/trunk/jk/native/common/jk_ajp_common.c Wed Dec 6
02:54:08 2006
@@ -1398,6 +1398,7 @@
res.num_headers);
if (r-flush r-flush_header)
r-flush(r);
+r-http_status = res.status;
}
return JK_AJP13_SEND_HEADERS;
@@ -1625,6 +1626,11 @@
return JK_TRUE;
}
else if (JK_AJP13_SEND_HEADERS == rc) {
+if (p-worker-http_status_fail
+(p-worker-http_status_fail == s-http_status)) {
+JK_TRACE_EXIT(l);
+return JK_STATUS_ERROR;
+}
headeratclient = JK_TRUE;
}
else if (JK_AJP13_HAS_RESPONSE == rc) {
@@ -1841,6 +1847,18 @@
JK_TRACE_EXIT(l);
return JK_SERVER_ERROR;
}
+else if (err == JK_STATUS_ERROR) {
+jk_log(l, JK_LOG_INFO,
+ (%s) request failed,
+ because of response status %d,
+ recoverable operation attempt=%d,
+ p-worker-http_status_fail,
+ p-worker-name, i);
+JK_TRACE_EXIT(l);
+if (i = JK_RETRIES) {
+jk_sleep(JK_SLEEP_DEF);
+}
+}
else {
/* if we can't get reply, check if no recover flag was set
* if is_recoverable_error is cleared, we have started
@@ -2062,6 +2080,8 @@
AJP_DEF_RECOVERY_OPTS);
p-max_packet_size =
jk_get_max_packet_size(props, p-name);
+
+p-http_status_fail = jk_get_worker_retry_on_status(props, p-name);
pThis-retries =
jk_get_worker_retries(props, p-name,
Modified: tomcat/connectors/trunk/jk/native/common/jk_ajp_common.h
URL:
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/common/jk_ajp_common.h?view=diffrev=483021r1=483020r2=483021
==
--- tomcat/connectors/trunk/jk/native/common/jk_ajp_common.h (original)
+++ tomcat/connectors/trunk/jk/native/common/jk_ajp_common.h Wed Dec 6
02:54:08 2006
@@ -287,6 +287,11 @@
unsigned int recovery_opts; /* Set the recovery option */
unsigned int max_packet_size; /* Maximum AJP Packet size */
+
+/*
+ * HTTP status that will cause failover (0 means disabled)
+ */
+ int http_status_fail;
};
Modified: tomcat/connectors/trunk/jk/native/common/jk_service.h
URL:
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/common/jk_service.h?view=diffrev=483021r1=483020r2=483021
mod_jk release preparation: ready for test
Hi, I think Mladen and I completed our code change plans for the next release of mod_jk. Since over all we had more changes than we expected when we started for 1.2.20 I would like to give the opportunity of testing, before I do the tagging. In case no show stoppers will be found I suggest tagging late saturday, or early sunday, so that we can finish the release vote during the next week. I produced a source tarball with the usual release script. It contains everything similar to a release except for the final version number and the correct release dates in the release docs. You can find it under: http://people.apache.org/~rjung/mod_jk-1.2.20-dev/ There is a directory docs containing the reorganized and slightly extended docs, a directory source containing the .tar.gz, .zip, the signature and checksum files and finally an empty directory binaries, which might be filled tomorrow by Mladen with Windows build(s). I would really appreciate, if some of our long term mod_jk experts could have a look at it. Major changes: - improved IIS 6 support (e.g. shm, thread counts - improved virtual host support for apache, also documented - reworked status worker (see new docs page) - reorganized docs, new pages for uriworkermap.properties and status worker Minor features: - fail_on_status attribute - rename jvm_route - route (but code still works with old config) - uriworkermap reload interval configurable - max_packet_size documented - new uriworkermap reload semantics (delete old uriworkermap entries from internal list during reload) - load balancer strategy Sessions - more flushing options BZ fixes: - 36121: Don't change main uri when mod_jk serves included uri. (markt) - 40966: Fix socket descriptor checks on windows. (mturk) - 40965: Initialize missing service parameters. (mturk) - 40938: Fix releasing of rewrite map. Thanks to Chris Adams for spotting that. (mturk) - 40856: Fixing case sensitivity bug in URL mapping. (rjung) - 40793: Documentation: Improvements to Apache HowTo provided by Paul Charles Leddy. (markt) - 40774: Fixing wrong recursion termination. This one restricted the reference feature unintentionally to 20 workers. (rjung) - 40716: Adding reference feature to IIS and Netscape. (rjung) Have fun, Rainer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
jk 1.2.20 release candidate: Windows Binaries available
Hi, Mladen Turk provided Windows Binaries for win32 (Apache mod_jk, IIS isapi plugin and Netscape nsapi plugin) and for win64 (AMD+IA64 isapi plugin): http://tomcat.apache.org/dev/dist/tomcat-connectors/jk/binaries Thanks Mladen and happy testing to everybody. Regards, Rainer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r486005 - in /tomcat/container/tc5.5.x: catalina/src/share/org/apache/catalina/connector/Request.java catalina/src/share/org/apache/catalina/session/PersistentManagerBase.java webapps
Remy Maucherat wrote:
[EMAIL PROTECTED] wrote:
if ((session != null) !session.isValid())
session = null;
if (session != null) {
+if(!requestedSessionId.equals(session.getId())) {
+Cookie cookie = new
Cookie(Globals.SESSION_COOKIE_NAME,
+session.getIdInternal());
+configureSessionCookie(cookie);
+response.addCookie(cookie);
+}
I don't know if that's a good idea. It looks a bit risky. I think it
should include (getContext() != null) getContext().getCookies().
Rémy
Also if I remember correctly, session replication with delta manager
(default) applies replica messages to sessions with the same id: So in a
three node cluster with one node failing renaming the id on a second
node might break replication from the second to the third. Unfortunately
I can't check right now, but since it might be, that 5.5.21 is not too
far, I would find this new rewriting behaviour a bit risky as a default.
I'm also asking Peter about the state of his rewriting listeners,
because I somehow remember a functionality like that might already exist.
Maybe Filip likes to comment on my first concern.
Regards,
Rainer
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r486005 - in /tomcat/container/tc5.5.x: catalina/src/share/org/apache/catalina/connector/Request.java catalina/src/share/org/apache/catalina/session/PersistentManagerBase.java webapps
My impression now is, that we should backout the commit and the user
should instead first try to use the existing Valve as described by Peter.
Filip Hanik - Dev Lists wrote:
Rainer Jung wrote:
Remy Maucherat wrote:
[EMAIL PROTECTED] wrote:
if ((session != null) !session.isValid())
session = null;
if (session != null) {
+if(!requestedSessionId.equals(session.getId())) {
+Cookie cookie = new
Cookie(Globals.SESSION_COOKIE_NAME,
+session.getIdInternal());
+configureSessionCookie(cookie);
+response.addCookie(cookie);
+}
I don't know if that's a good idea. It looks a bit risky. I think it
should include (getContext() != null) getContext().getCookies().
Rémy
Also if I remember correctly, session replication with delta manager
(default) applies replica messages to sessions with the same id: So in
a three node cluster with one node failing renaming the id on a second
node might break replication from the second to the third.
Unfortunately I can't check right now, but since it might be, that
5.5.21 is not too far, I would find this new rewriting behaviour a bit
risky as a default.
Peter did the session rewriting implementation, I haven't worked on it,
but it seems that the session Id to piggy back on could have been done
without going that deep in the code.
Not sure what the concern is in Rainer's statement above, but that
scenario should work just fine as the cluster replicates the sessionId
changes, again a far from ideal solution.
It would have been easier to filter out the JVM route way before we hit
the session manager, and then append it before the request gets sent
out, that way we could avoid both the patch above and the session Id
listeners and jvm route binder stuff. so in short terms, the session
manager never knows about jvmRoute, that is something happening on the
edge.
does that make sense?
Filip
I'm also asking Peter about the state of his rewriting listeners,
because I somehow remember a functionality like that might already exist.
Maybe Filip likes to comment on my first concern.
Regards,
Rainer
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Serious mod_jk performance issue
If noone finds a reason for it, I can go into it during the weekend. I would try to reproduce and research on Solaris. Concerning your data for Solaris: Apache and Tomcat were both on Solaris? The same machine or different? Network between Client (Browser?) and Apache was 100MBit or 1GBit? Regards, Rainer Jess Holle schrieb: We're seeing a *serious *performance issue with mod_jk and large (e.g. 500MB+) file transfers. [This is with Apache 2.0.55, Tomcat 5.0.30, and various recent mod_jk including 1.2.20.] The performance of downloading the file via Apache is good, as is the performance when downloading directly from Tomcat. The performance when downloading from Tomcat through Apache via mod_jk is, however, quite abysmal. I'd obviously expect *some* degradation due to the extra interprocess hop, but given that this is a just a single-user, single-request test, I'd expect that the network would still be the limiting factor -- or at least that the degradation would be in the order of 25% of less. What we're seeing, however, is far worse: On Windows: * Apache 2.0.55, Tomcat 5.0.30, and mod_jk 1.2.20 - Started at 10 MB/sec ended at 3 MB/sec with mod_deflate disabled (1.5 MB/sec with mod_deflate enabled) * Apache 2.0.55, Tomcat 5.0.30, and mod_jk 1.2.19 - Disabling JkFlushPackets only slightly improved performance. * Apache 2.2.3 with Tomcat 5.5.20 w/ the native connector - Didn't work period. I didn't have a chance to look into it, but the download failed after getting serveral packets (!) * Apache 2.2.3 with Tomcat 5.5.20 w/o the native connector - Was only slightly slower than going straight through Apache about 7-8 MB/sec On Solaris: * Apache 2.0.55, Tomcat 5.0.30, recent mod_jk - Fairly constant 4MB/s when going through mod_jk, 10MB/s when just downloading via Apache [This issue originally was thought to be Windows specific, which is why we have many more results for Windows.] Obviously if our end goal was simple static file transfers we'd just share/mirror them to Apache to solve this (we need the load balancing flexibility, etc, of mod_jk, so directly using Tomcat is not really an option -- nor is doing non-AJP-proxying). The static file case is the simplified reproduction of our real issue, however, which is large file downloads from our (Java-based) content store. We had much better results with Apache 2.2.3 and Tomcat 5.5.20 with tcnative, but we really don't want to force a move to 2.2.x and Tomcat 5.5.x in this case and we've had issues with tcnative (which we *hope* may be resolved with 1.1.8). Overall we'd much prefer to get mod_jk working reasonably than to force a disruptive move to 2.2.x right now. Is this a known issue? Any pointers as to where/how to look for the performance bottleneck? Some VTune examination showed that almost all of Apache's CPU time during this time was in libapr.dll, but that's obviously not terribly specific. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk release preparation: ready for test
Hi David, this message means, that no forwarding rules (=map) have been found for that worker. So no JkMount, mount attribute in workers.properties or uriworkermap.properties applies to that worker. Important: maps are associated to virtual hosts in apache. The status worker can only see those maps, that belong to the same virtual host, it has been called in. So if you add all your maps to a vhost for production use, and add a status worker on a separate vhost for admin use, this status worker will not be able to see the maps from the production vhost. If you want to inhertif maps from the global server to vhosts, you need to set JkMountCopy for the vhost. More about that in the updated Apache docs page (reference guide) and the new uriworkermap.properties page. Could that be the reason for the message? We might improve the situation concerning the status worker in the future, but making available all the maps to it will be a major refactoring in the jk code (for apache, IIS can already see all the maps). Regards, Rainer David Rees schrieb: On 12/6/06, Rainer Jung [EMAIL PROTECTED] wrote: - reworked status worker (see new docs page) On my status worker page, I get the message: Warning: No URI Mappings defined for workername ! Otherwise, everything seems to work OK so far in my limited testing. -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]
[VOTE] Releasing Tomcat Connectors 1.2.20
Hello to all Tomcat project members, mod_jk 1.2.20 has been available for testing during the last week. No new bugs have been reported so far, so I would like to proceed with the release vote. If you want to take a look, the source distribution can be downloaded from: http://tomcat.apache.org/dev/dist/tomcat-connectors/jk/ The updated documentation can be found at http://tomcat.apache.org/dev/dist/tomcat-connectors/jk/source/jk-1.2.20/docs/ So here's the vote, which will be open until Tuesday December 19, 24:00 GMT. Apache Tomcat Connectors 1.2.20 is: [ ] Stable - no major issues, no regressions [ ] Beta - at least one significant issue -- tell us what it is [ ] Alpha - multiple significant issues -- tell us what they are Thank you, Rainer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Smooth applications migration in a J2EE cluster [mod_jk]
Hi, yes I looked at the animation. Although I must confess, that I don't get much out of it technically. What's the reason for the need to test session validity? Is it needed to find out, if a node already got upgraded to a new app version, so the session needs to get routed to a node, still running the old app version? That's what I expect, since you introduced worker versions (one could also name it generation). OK, we are only talking about cluster (in the sense of session replication) and I assume, that we are interested in the case of an application update, which is non-compatible concerning sessions and/or URL structure. At the moment, sessions will be routed according to the routing suffix in their id. Sessions which failed over can be rewritten (get another routing suffix) by a Valve and thus be bound to another (surviving) node. But sessions which have been idle will still be called with the old suffix by the browser the next time they are used. If the node got an update in the meantime, they will get routed to an incompatible node and throw an error. As a first simple workaround one could use two sets of workers and of target (tomcat) nodes. One set would be stopped, on active at a time. The two sets use different jvmRoutes. Replication is not done across set boundaries. You upgrade the stopped set, test it via an internal connector/vhost and then change its activation to active. Also you change the activation of the formerly active set to disabled. New sessions will go to the updated set, old sessions will still go to the unchanged set. Invalid sessions will need to redirect to a start page without session information. After some (depending on session use time) you stop the disabled set, to prevent people with URL encoded bookmarks (or long running browsers with cookies cached) to still reach the old version. Now this scenario does not really help, if you want to do *many* updates. It granularity is somehow to coarse. To make it work more smoothly, we would need an automatic way of managing jvmRoute, worker.route and worker.domain consistently during application upgrade (increasing generation counter which gets appended to the route). It looks like you did something like that? Somehow I don't really see the need of checking the validity of a session by mod_jk. We only need to know, which version of the app the session belongs to, and which version of the app the various workers talk to. This could be done by a generation counter in jvmRoute and all routing related strings in mod_jk. In your original mail, you talked about additional hooks you would need inside mod_jk. What would that be? Regards, Rainer Anthony Vromant schrieb: Hi all, I would like to know if you had time to look at the demonstration of our prototype. We are very interested to get your feelings about that. Do you have ideas about our problem of testing the validity of a user session within mod_jk ? We're thinking about a mechanism relying on the JMX-Adaptor of Tomcat that mod_jk can invoke through the AJP interface. What's your opinion ? Thanks. Regards Anthony Vromant Anthony Vromant wrote: Hi Rainer, First of all, thank you for these informations. Here is the HTTP link for the Flash demonstration of our prototype : https://wiki.objectweb.org/jonas/Wiki.jsp?page=JOnASClusteringSmoothUpdateWebCluster I am looking at the new features provided by mod_jk 1.2.20, the dynamic configuration reloading is quite interesting. We are going to bring our prototype to this new version. In our prototype, when a new request is coming with a JSESSIONID cookie, a request is sent to the worker (tomcat) for checking the validity (we need to know whether the session is still alive). Currently, the HTTP protocol is used for invoking tomcat rather than AJP. The control at the tomcat side is done through an internal servlet which accesses the MBean manager for getting the current sessions list. Do you have any suggestion for improving that ? Regards, Anthony - 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] Release build 6.0.6 as alpha
Henri Gomez schrieb: people.apache.org seems to be down ;( and up again. Hopefully stable (p.a.o). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Draft Board report for December 2006
OK with me, thanks for doing this. Yoav Shapira schrieb: Hi, Here's an updated draft with PMC feedback. Take a day or two to comment if you'd like: I'm aiming to send this in to the Board by 5pm EST tomorrow (Monday). Yoav --- Begin Draft --- Apache Tomcat Board Report, December 2006 --- Issues requiring the Board's attention: none. Development -- Work continues apache on Tomcat 6 and the mod_jk connector. Both products have done multiple alpha- and beta-level releases since the last Board report. Both have received increased testing from the committers as well as outside contributors, resulting in some interesting issues discovered and addressed. We hope to have a stable mod_jk release, 1.2.20, in the next week or two, and the first stable Tomcat 6 release before the next Board report. Several of the fixes found in Tomcat 6 have been back-ported to Tomcat 5.x as well, but there has been no 5.x release since 5.5.20 in September. Community Not much going on here: no new committers, no new PMC members, but no one resigning or leaving either ;) Security On December 7th a possible security issue was reported to us by the Struts PMC, which had been notified of it earlier. After some discussion, we concluded this was a fairly minor issue with responsibility on both the Tomcat and Struts sides. There was a patch available in SVN within a day or so, and it was back-ported to previous Tomcat branches as well. Because the issue has yet to be publicly announced and this Board report may become public before the issue is announced, we are omitting the actual details here. The Tomcat PMC will be glad to provide any details required, and the discussions are archived on the mailing list archives of [EMAIL PROTECTED], [EMAIL PROTECTED], and [EMAIL PROTECTED] --- End Draft --- - 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: Serious mod_jk performance issue
Hi Jess, I did some simple tests and was not able to reproduce your performance observations. Nevertheless I could observe a couple of strange things, but I doubt, if they are relevant to most use cases. First my setup: Apache 2.0.59 worker with mod_jk 1.2.20 and Tomcat 5.5.17 with normal (non-apr) connectors, using Java 1.5.0_06 on an early Release of Solaris 10. Hardware Sun T-2000 (Niagara), which means relatively slow CPU but good scalability. I didn't have the system exclusively, but it was rather idle during the test. Client ab from apache 2.0.59. All ab measurements have been verified with %D in the apache access log. No restarts between measurements, so the file was most likely coming from the file system cache. Client running either on the same machine, or on a SLES 9 SP2, 64Bit AMD Opteron connected by 100MBit Ethernet. Apache and mod_jk compiled with -mcpu=v9 -O2 -g -Wall. Apache, mod_jk and Tomcat configured default (apart from ports and log format), JVM for tomcat with a couple of non-default values: -server \ -Xms64m -Xmx64m \ -XX:NewSize=8m -XX:MaxNewSize=8m \ -XX:SurvivorRatio=6 -XX:MaxTenuringThreshold=31 \ -XX:+UseConcMarkSweepGC -XX:-UseAdaptiveSizePolicy File to test throughput had size 316702480 bytes (some .tar.gz I found lying around). 1) local client, i.e. client running on the same machine as Apache and Tomcat A single request took 15.71 sec (mod_jk) (=153.8 MBit/Sec) and 15.61 (TC HTTP direct) (=154.8 MBit/sec), the same with 10 consecutive - non-parallel - requests gave 157.1 sec resp. 156.8 sec, so this result seems to be stable. Now parallel requests: I used parallelity (-c with ab) of 2 4 8 16 32 and the double amount of requests (4, 8, ...): Throughput results in MBit/sec, depending on concurrency: mod_jk http conc. 1 153.8 154.8 2 306.3 303.6 4 605.5 627.7 8 1090.0 1185.5 161137.7 1161.8 321210.7 1114.3 mod_jk and HTTP direct behave almost the same for the huge file. We saturate the system at about 1100 MBit/second (going via loopback). CPU was busy at most 60% during these tests. This also shows, that mod_jk and HTTP throughput is enough to saturate a lot of bandwidth - as long as your IP stack doesn't add to much overhead to it. 2) remote client, i.e. ab running on the SLES 9 SP2 x86_64 machine, connected via 100MBit to Apache and Tomcat. Throughput results in MBit/sec, depending on concurrency: mod_jk http conc. 1 88.689.1 2 88.989.1 So even with only one request in parallel we saturate the network and it does not make sense to measure more than two parallel requests. 3) Dependancy on file size: Measuring with local client without concurrency for 50, 100, 200, 300, 400, 500, ..., 1000MB: mod_jk http MB 50 167.5 234.9 (5 consecutive requests) 100 168.8 170.1 (5 consecutive requests) 200 168.6 169.8 (2 consecutive requests) 300 169.1 169.7 (2 consecutive requests) 400 168.9 169.7 (2 consecutive requests) 500 168.8 169.4 (2 consecutive requests) 600 167.9 168.0 (2 consecutive requests) 700 167.8 168.9 (2 consecutive requests) 800 168.1 168.6 (2 consecutive requests) 900 168.0 168.0 (2 consecutive requests) 1000 156.2 214.9 (2 consecutive requests) 2000 156.9 214.7 (1 request) Interestingly the result for 1000M and for 2000M is reproducible. But as soon as I switch from the client ab to wget or curl (writing output to /dev/null) I get the same numbers for mod_jk, but for HTTP I get the same result as for mod_jk! The numbers are slightly better than in the first test, I guess because this test was done using a file in the webapps file system, the first test was done using a file in another file system symlinked from within webapps (but still a local fs). Another possibilty would be, that a mkfile generated file has a better block layout in the fs, than a usual file, which was growing over time. All in all I think that throughput for huge files is very good in both cases. I would expect, that most often it would be much more intersting to inspect scalability and system load (cpu/memory) for massive concurrency. When serving large files, downloads will run a long time because most often the client side of the connection is not a fat line. As a result users will add up in parallel, so one might need to serve a few thousands of users. Regards, Rainer Jess Holle schrieb: Mladen Turk wrote: Jess Holle wrote: We're seeing a *serious *performance issue with mod_jk and large (e.g. 500MB+) file transfers. [This is with Apache 2.0.55, Tomcat 5.0.30, and various recent mod_jk including 1.2.20.] SunOS dev12.qa.atl.jboss.com 5.9 Generic_118558-25 sun4u sparc SUNW,Sun-Fire-V210 Tomcat:8080 Total transferred: 1782932700 bytes HTML transferred: 1782908800 bytes Requests per second:5.60 [#/sec] (mean) Apache-mod_jk-Tomcat:8009 Total transferred: 1782935400 bytes HTML transferred:
Re: Smooth applications migration in a J2EE cluster [mod_jk]
Hi Anthony, Anthony Vromant schrieb: Here is the explanation about the session validity checking : This test aims to have users with expired sessions and URL encoded bookmarks (or long running browsers with cookies cached) redirected to a node hosting the new version of the application. If this test is not done during the update, these users will start a new session on a node hosting the old version of application (and so, perhaps just before the stop of these node). Do you agree with this ? Ah OK, yes I agree. You could use a filter (or Valve) to redirect requests with an invalid session to the login page without URL encoding and invalidating the cookie. That way you would destroy the invalid binding to this node. If we would try to do that with mod_jk directly, mod_jk would need to have a shadow copy of the session list, something which doesn't sound right. OK, mod_jk could ask tomcat about the session, but we can also simply forward and let the node delete the binding. As a first simple workaround one could use two sets of workers and of target (tomcat) nodes. One set would be stopped, on active at a time. The two sets use different jvmRoutes. Replication is not done across set boundaries. When you say 2 sets of workers, you mean using the notion of domains ? With sets I simply mean sets :) Somehow you configure each worker twice, but with different names. Domains come into play, to define failover rules between the workers. Failover should not hapen between the sets. So each set will belong to one domain. A mod_jk domain is nothing else, than failover information (try another worker in the same domain first, before trying any other worker). You upgrade the stopped set, test it via an internal connector/vhost and then change its activation to active. Also you change the activation of the formerly active set to disabled. New sessions will go to the updated set, old sessions will still go to the unchanged set. Invalid sessions will need to redirect to a start page without session information. After some (depending on session use time) you stop the disabled set, to prevent people with URL encoded bookmarks (or long running browsers with cookies cached) to still reach the old version. One of our objective is to use as much as possible mod_jk's capabilities. So our prototype is based on using of these features : - disabling a worker - session rewriting (with a Valve) - route modification I've tried to pass the scenario you explain here, and i had a problem : Here's my mod_jk (1.2.20) configuration : worker1 : route = domain1.worker1, domain=domain1 worker2 : route = domain1.worker2, domain=domain1 worker3 : route = domain1.worker3, domain=domain1 Sticky session = true And here's the test : 1/ Session initialization on worker1 : JSESSIONID.domain1.worker1 2/ Stop worker1 3/ Upgrade worker1 4/ Change route/domain of worker1 : route = domain2.worker1, domain=domain2 5/ At the same time : Active worker1 and disable worker 2 and 3 6/ Refresh on JSESSIONID.domain1.worker1 - The request still access on worker1 Whereas we want her to be routed to the old version of application (so workers 2 or 3). For the requests initialization on worker 2 or 3, it's ok. Perhaps I missed something. Active: worker1a : route = worker1a, domain=domain1 worker2a : route = worker2a, domain=domain1 worker3a : route = worker3a, domain=domain1 Stopped: worker1b : route = worker1b, domain=domain2 worker2b : route = worker2b, domain=domain2 worker3b : route = worker3b, domain=domain2 Sticky session = true Then you would follow the above steps. Regards, Rainer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Smooth applications migration in a J2EE cluster [mod_jk]
Anthony Vromant schrieb:
Hi,
The scenario you explained me doesn't work in my env. I'm trying to find
out the reasons below :
Here is the code :
jk_lb_worker.c : find_bysession_route()
candidate = find_by_session(p, name, l);
if (!candidate) {
uses_domain = 1;
candidate = find_best_bydomain(p, name, l);
}
If route was changed on a worker, find_by_session() method can't find
a good worker (and thus its domain).
It's not necessary to find a good worker (whatever that would mean).
find_by_session() only checks for a worker with the right name. So the
question is: why did you change the route? If you changed the route,
because the session was invalid, we proceed with a request without
session id and it can be balanced to any active node. In all other
cases we don't want to change the route. Then the function finds the
worker as a candidate and the code will bypass the if above. The next
part of the code checks, if the candidate does work (is usable). If not,
it will use the redirect or domain attributes to find an alternative.
It seems to me strange in this case, to call find_best_bydomain()
method with a route in parameter whereas a domain name is expected ?
This part of the code does not fit into our discussion. It can be used
for stateless service swithout stickyness. You can have the same
jvmRoute on a set of nodes and then have different workers, each with
domain=jvmRoute. This is not necessary any more, because we now can
define route of a worker. This feature did not exist, when the above
code was written.
With the current code, when a route is modified (!candidate), domain
affinity doesn't work anymore for the old active session related to the
changed worker ?
Is it a normal behavior according to you ?
Why do you want to modify the route?
The JSESSIONID only knows the route, but not the domain and the code
have to cope with this miss.
By the way, I've also tried to use routes with a period like
'domain.worker', but it changes nothing.
Regards,
Rainer
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk, default value of retries is still 3?
You are right. I fixed it in svn HEAD. Thanks for spotting that! Regards, Rainer Takayuki Kaneko schrieb: Hi, I found a mismatch between the document and source code about the default value of retries. It's my understanding that the default value was changed from 3 to 2 at r420266. http://svn.apache.org/viewvc?view=revrevision=420266 But the latest doument says it is still 3. http://tomcat.apache.org/dev/dist/tomcat-connectors/jk/source/jk-1.2.20/docs/reference/workers.html Thanks. - 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] Releasing Tomcat Connectors 1.2.20
Apache Tomcat Connectors 1.2.20 is: [X] Stable - no major issues, no regressions [ ] Beta - at least one significant issue -- tell us what it is [ ] Alpha - multiple significant issues -- tell us what they are ... and now proceeding to the announcement ... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[RESULT][VOTE] Releasing Tomcat Connectors 1.2.20
The results of the vote are: Stable: 5 votes (Henri, Yoav, Mladen, Jean-Frederic, Jim, Rainer) Beta, Alpha: None. I'm waiting for the automatic copy from p.a.o to t.a.o before announcing. Rainer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] Apache Tomcat JK 1.2.20 Web Server Connector released
The Apache Tomcat team is pleased to announce the immediate availability of version 1.2.20 of the Apache Tomcat Connectors. It contains connectors, which allow a web server such as Apache HTTPD, Microsoft IIS and Sun Web Server to act as a front end to the Tomcat web application server. This version contains several enhancements and fixes a number of minor bugs of the previous version 1.2.19. See http://tomcat.apache.org/connectors-doc/miscellaneous/changelog.html for a complete list of changes. Source distribtions can be downloaded from an Apache Software Foundation mirror at: http://tomcat.apache.org/download-connectors.cgi Binary distributions for a number of different operating systems and web servers can be downloaded from an Apache Software Foundation mirror at: http://tomcat.apache.org/download-connectors.cgi Documentation for using JK with Tomcat 3.3, 4.1, 5.0 and 5.5 can be found at: http://tomcat.apache.org/connectors-doc/ Thank you, -- The Apache Tomcat Team - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk, default value of retries is still 3?
Oh, I overlooked that one. Changes it too for 1.2.21 and on the web site. The web site needs a few hours to sync. Thanks again for spotting it. Rainer Takayuki Kaneko wrote: Hi, Rainer I saw three in the description column. :) Regards, -Takayuki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJP flush packets?
This has been done on October 29th in revision r468936 fpr TC 5.5 too. It should be part of 5.5.21, which hat not been scheduled yet. Regards, Rainer Sven Köhler wrote: Mladen Turk schrieb: Sven Köhler wrote: Hi, i see, you're developing Tomcat 6.0. Will Tomcat 6.0 send flush packets, when the flush()-method of the OutputStreams or the Writers are called? Yes. It's done in a way that is backward compatible. When out.flush() is called an empty data packet is sent. I have one more question: Is this going to be backported to Tomcat 5.5? Regards, Sven - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r493203 - in /tomcat/connectors/trunk: jk/tools/lineends.pl jni/native/build/lineends.pl
Hi Bill, I took the changes over from jni to jk just for the same reasons. I hope Mladen will sync with apr. No commit rights on my side. Regards, Rainer William A. Rowe, Jr. wrote: Hello Jakarta folks, the apr folks would appreciate if improvements were pushed back to repos/asf/apr/apr/build/win32 - even to the extent that those aren't strictly necessary for apr+httpd. Yours, Bill [EMAIL PROTECTED] wrote: Author: rjung Date: Fri Jan 5 13:57:03 2007 New Revision: 493203 URL: http://svn.apache.org/viewvc?view=revrev=493203 Log: Carry over Mladen's lineends.pl improvements from jni to jk (and kill one trailing space). Modified: tomcat/connectors/trunk/jk/tools/lineends.pl tomcat/connectors/trunk/jni/native/build/lineends.pl Modified: tomcat/connectors/trunk/jk/tools/lineends.pl URL: http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/tools/lineends.pl?view=diffrev=493203r1=493202r2=493203 == --- tomcat/connectors/trunk/jk/tools/lineends.pl (original) +++ tomcat/connectors/trunk/jk/tools/lineends.pl Fri Jan 5 13:57:03 2007 @@ -23,7 +23,7 @@ $ignore .= gif-jpg-jpeg-png-ico-bmp-; # Archive formats -$ignore .= tar-gz-z-zip-jar-war-; +$ignore .= tar-gz-z-zip-jar-war-bz2-tgz-; # Many document formats $ignore .= eps-psd-pdf-ai-; @@ -32,9 +32,9 @@ $ignore .= ucs2-ucs4-; # Some binary objects -$ignore .= class-so-dll-exe-obj-; +$ignore .= class-so-dll-exe-obj-a-o-lo-slo-sl-dylib-; -# Some build env files in NW/Win32 +# Some build env files $ignore .= mcp-xdc-ncb-opt-pdb-ilk-sbr-; $preservedate = 1; Modified: tomcat/connectors/trunk/jni/native/build/lineends.pl URL: http://svn.apache.org/viewvc/tomcat/connectors/trunk/jni/native/build/lineends.pl?view=diffrev=493203r1=493202r2=493203 == --- tomcat/connectors/trunk/jni/native/build/lineends.pl (original) +++ tomcat/connectors/trunk/jni/native/build/lineends.pl Fri Jan 5 13:57:03 2007 @@ -34,7 +34,7 @@ # Some binary objects $ignore .= class-so-dll-exe-obj-a-o-lo-slo-sl-dylib-; -# Some build env files +# Some build env files $ignore .= mcp-xdc-ncb-opt-pdb-ilk-sbr-; $preservedate = 1; - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Tomcat 6.0.7
Remy Maucherat schrieb: Hi, 6.0.7 is: [ ] Alpha [X] Beta Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Discussion mod_jk and mod_dir interaction
Hi, I want to find out how to correctly fix BZ 41430 and 36121. They have to do with the way mod_dir and mod_jk interact. Before fixing the code I find it necessary to define the correct behaviour, which seems to be non-trivial. The behaviour needs to be described depending on DirectoryIndex and JkOptions ForwardDirectories. I try to answer via two general rules, that I suggest: A) The first entry in DirectoryIndex that exists either locally or matches a JkMount stops the procedure. If it exists locally it gets served by Apache, if it matches a JkMount and does not exist locally it gets forwarded to Tomcat. B) If no entry in DirectoryIndex exists locally or matches a JkMount, the Option ForwardDirectories decides: Off=Apache, On=Tomcat. The forwarded request is the original request without any DirectoryIndex files. I haven't checked, if this can be implemented easily. I first want to know, if this seems like a reasonable behaviour? The downside is: If you have JkMount /*.jsp w and DirectoryIndex index.jsp, Apache will send all dirs with index.jsp to Tomcat. Here are some cases: Assume we have DirectoryIndex file1 file2 and we process a request /test/ which points to /path/test/. 1) Non of the files /path/test/file1 and /path/test/file2 exist, non of them matches any JkMount. a) ForwardDirectories is not set: Apache tries to serve the directory /path/test/ b) ForwardDirectories is set: We forward the original request to Tomcat (/test/) without file1 or file2. 2) Non of the files /path/test/file1 and /path/test/file2 exist, but one of them (assume file1) matches a JkMount. We forward /test/file1. 3) At least one of the files exists (assume file2), non of them matches any JkMount. a) ForwardDirectories is not set: Apache tries to serve /path/test/file2 b) ForwardDirectories is set: Again Apache tries to serve /path/test/file2. 4) At least one of the files exists (assume file2), and file1 matches a JkMount. Apache serves /path/test/file2, or forward /test/file1, whichever comes first in the DirectoryIndex list. 5) The same file file1 that exists, also matches a JkMount. Apache serves locally /path/test/file1. Thanks Rainer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Discussion mod_jk and mod_dir interaction
Hi Mladen, Mladen Turk wrote: Rainer Jung wrote: Hi, I want to find out how to correctly fix BZ 41430 and 36121. They have to do with the way mod_dir and mod_jk interact. Before fixing the code I find it necessary to define the correct behaviour, which seems to be non-trivial. It is very trivial. The mod_jk is proxy to Tomcat, and nothing more. Things like mapping web app to the Apache vhost that BTW works only when both Httpd and Tomcat are on the same host is usable only for delivering static content directly by Httpd. Things like DirectoryIndex are completely useless and further more breaks the security, because the Tomcat must serve the default content. I simply don't understand, what this means functionally, i.e. how DirectoryIndex and ForwardDirectories should work with mod_jk. So, although some hacks can be done, I'll veto any option that will allow serving as default some content that wouldn't be served by Tomcat using his configure. If I try to interprete this, it would disallow to forward a request /test/ as /test/file to tomcat, if file is a DirectoryIndex - even if /test/file would match a JkMount - and even if /test/file can be matched to a file system entry by Apache. Correct? This is different from current behaviour. So you suggest to completely ignore DirectoryIndex for mod_jk and only forward directory requests to tomcat, if - they don't get served by apache - they match a JkMount - and ForwardDirectories is set. Correct? Regards, Mladen. Regards, Rainer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Discussion mod_jk and mod_dir interaction
I think we agree, that DirectoryIndex should not replace the welcome-file list on the Tomcat side. This means at least: if non of the entries in the DirectoryIndex list is visible by Apache, it should not try to prepend any of them to the URL and send to Tomcat, even if this would match a JkMount. OK? For any of the entries in the welcome-list it would suffice to send a directory request forward. Now a few cases are left over: 1) If Apache can see a file from DirectoryIndex, should it serve it locally, or send it to Tomcat? The easy answer would be: serve it locally in any case. As a consequence, when mixing dynamic and static content one would need to use a different file name to distinguish the two (or use a more elaborate per directory or location Apache config). This doesn't sound too unreasonable. The other option would be: send it to Tomcat, if it matches a JkMount. In that case Apache manipulates a browser request and sends the manipulated request to Tomcat. I tend to disagree with this option 2) If Apache can not see any file from DirectoryIndex. How should the forwarding behaviour depend on JkMount and ForwardDirectories? If the request matches a JkMount, it should definitely be forwarded. If it doesn't match a JkMount, it doesn't sound very convincing to forward at all. So I don't see a good use case for an option ForwardDirectories. Regards, Rainer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FYI: jk 1.2.20 core on iSeries v5R3
Hi Henri,
there have been two bug fixes concerning string formatting, which have
core dump potential. Both only occur with log level info or above. I
think they are *not* the reason (see below). The code is in
common/jk_ajp_common.c:
1) Wrong order of arguments; should only be relevant, if new feature
fail_on_status is being used.
@@ -1850,10 +1864,10 @@
else if (err == JK_STATUS_ERROR) {
jk_log(l, JK_LOG_INFO,
(%s) request failed,
because of response status %d,
recoverable operation attempt=%d,
- p-worker-http_status_fail,
- p-worker-name, i);
+ p-worker-name,
+ p-worker-http_status_fail, i);
2) Missing s in %s. Should not produce a core dump.
@@ -1108,7 +1122,7 @@
if ((len = ajp_read_fully_from_server(r, l, read_buf, len)) 0) {
jk_log(l, JK_LOG_INFO,
- (%) receiving data from client failed.
+ (%s) receiving data from client failed.
Connection aborted or network problems,
ae-worker-name);
JK_TRACE_EXIT(l);
We don't have any other core dump reports for 1.2.20 at the moment. From
your core analysis I expect another reason. Between 1.2.19 and 1.2.20
there was the big virtual host cleanup. That included per virtual host
loggers. The method ws_write has not been changed, but some of the
config parsing, overloading and initialization.
Could you check, if there are any startup errors in your apache or
mod_jk logs? Use JkLogLevel debug and LogLevel at least info. Please try
first with a basic config with no vhosts. Does it crash during startup,
or when running requests?
Some changes:
1) If no log file is configured, it tries to use logs/mod_jk.log.
2) Log definitions get inherited from the global server to virtual
servers, but are overwritten by explicit virtual server configs.
3) The mod_jk time stamp formats and its own request logging are also
per virtual server
Do we have a chace to find out the line numbers in ws_write, where we
called the jk_log? There are tw possibilities:
399 if (!p-response_started) {
400 if (main_log)
401 jk_log(main_log, JK_LOG_INFO,
402 Write without start, starting with
defaults);
403 if (!s-start_response(s, 200, NULL, NULL,
NULL, 0)) {
404 return JK_FALSE;
405 }
406 }
and one debug message:
435 if (JK_IS_DEBUG_LEVEL(main_log))
436 jk_log(main_log, JK_LOG_DEBUG,
437 written %d out of %d, r, ll);
438
Does the crash go away, if JkLogLevel is info?
I'm afraid we have to debug this iteratively. I had no problems on *nix
platforms and up to now also no user reports.
Henri Gomez wrote:
Thanks.
Did the 1.2.21 is expected soon or should I use the trunk ?
I think 1.2.21 is still a couple of weeks ago, but I expect trunk to
produce the same problem, because I don't see anything we changed, that
might have fixed it.
Regards,
Rainer
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: FYI: jk 1.2.20 core on iSeries v5R3
Hi Eric, maybe your observation is in fact related to Henri's, since you also get core dumps (segmentation faults), which is quite unusual. See further comments inline. Eric Wertman wrote: Sorry to jump in, I'm new here. I started watching this list because of a problem I'm having with the mod_jk 1.2.20 as well. I'm not getting core files, but I do have problems that I can't reproduce at log level trace or debug. Apache logs segmentation faults. You might be able to produce a core (which would be very helpful) by setting the coredumpdirectory in apache and maybe tweaking your os config. One point that might help to produce cores, would be to not run apache as root. I'm running it on AIX 5.3 (ml05). I compiled the apache 2.2.4 and apr-1.2.8 along with the mod_jk, and using tomcat 5.5.20 with an IBM 1.5 JRE. I compiled them all using the IBM cc_r compiler. I've actually tried a number of different flags trying to resolve my problem, assuming initially that I was doing something incorrectly. The behavior persists, though, and my compilations have all been clean. Apache without mod_jk doesn't give me any problems. Superficially it seems to work fine. Once I run tests with ab, it starts to get a little ugly. I get a number of failed requests, and these types of errors: [Tue Jan 30 03:03:53 2007] [2203720:] [error] jk_ajp_common.c (1504): Unknown AJP protocol code: 41 [Tue Jan 30 03:03:53 2007] [2203720:] [error] jk_ajp_common.c (970): wrong message format 0x3837 from 127.0.0.1:8010 hose mean, taht something is fundamentally wrong in the answer mopd_jk receives from tomcat. It doesn't really look like AJP/1.3. Is your MPM worker or prefork? Could you try again with prefork, in case it is worker? Do you get error message on the tomcat side? [Tue Jan 30 03:03:53 2007] [2203720:] [error] jk_ajp_common.c (1566): (PlatformServer) Tomcat is down or refused connection. No response has been sent to the client (yet) [Tue Jan 30 03:03:53 2007] [2203720:] [info] jk_ajp_common.c (1877): (PlatformServer) receiving from tomcat failed, recoverable operation attempt=0 [Tue Jan 30 03:03:53 2007] [2203720:] [info] jk_ajp_common.c (1916): (PlatformServer) sending request to tomcat failed, recoverable operation attempt=1 [Tue Jan 30 03:03:53 2007] [2203720:] [info] jk_ajp_common.c (1842): (PlatformServer) request failed, because of server error without recovery in send loop attempt=0 [Tue Jan 30 03:03:53 2007] [2203720:] [info] mod_jk.c (2142): Service error=-5 for worker=PlatformServer [Tue Jan 30 03:03:53 2007] [2203720:] [info] mod_jk.c (401): Write without start, starting with defaults Ths one is very unusual, and it is the log statement, that is the only one, that could have produced Henri's core dump, although we still do not know why. It correlates to a protocol error. [Tue Jan 30 03:03:53 2007] [2203720:] [error] jk_ajp_common.c (970): wrong message format 0x031a from 127.0.0.1:8010 [Tue Jan 30 03:03:53 2007] [2203720:] [error] jk_ajp_common.c (1592): (PlatformServer) Tomcat is down or network problems. Part of the response has already been sent to the cli ent [Tue Jan 30 03:03:53 2007] [2203720:] [info] jk_ajp_common.c (1877): (PlatformServer) receiving from tomcat failed, recoverable operation attempt=1 [Tue Jan 30 03:03:53 2007] [2203720:] [error] jk_ajp_common.c (1504): Unknown AJP protocol code: D8 [Tue Jan 30 03:03:53 2007] [2203720:] [info] jk_ajp_common.c (1842): (PlatformServer) request failed, because of server error without recovery in send loop attempt=0 [Tue Jan 30 03:03:53 2007] [2203720:] [info] mod_jk.c (2142): Service error=-5 for worker=PlatformServer [Tue Jan 30 03:03:53 2007] [2203720:] [info] jk_ajp_common.c (1916): (PlatformServer) sending request to tomcat failed, recoverable operation attempt=2 [Tue Jan 30 03:03:53 2007] [2203720:] [error] jk_ajp_common.c (915): sendfull returned -14 with errno=14 [Tue Jan 30 03:03:53 2007] [2203720:] [error] jk_ajp_common.c (948): (PlatformServer) can't receive the response message from tomcat, network problems or tomcat is down (127.0. 0.1:8010), err=-9 [Tue Jan 30 03:03:53 2007] [2203720:] [error] jk_ajp_common.c (1566): (PlatformServer) Tomcat is down or refused connection. No response has been sent to the client (yet) [Tue Jan 30 03:03:53 2007] [2203720:] [info] jk_ajp_common.c (1877): (PlatformServer) receiving from tomcat failed, recoverable operation attempt=0 [Tue Jan 30 03:03:53 2007] [2203720:] [error] jk_ajp_common.c (1292): (PlatformServer) failed resending request body (812760852) [Tue Jan 30 03:03:53 2007] [2203720:] [info] jk_ajp_common.c (1916): (PlatformServer) sending request to tomcat failed, recoverable operation attempt=3 [Tue Jan 30 03:03:53 2007] [2203720:] [info] jk_ajp_common.c (1916): (PlatformServer) sending request to tomcat failed, recoverable
Re: svn commit: r502062 - /tomcat/connectors/trunk/jk/jkstatus/src/share/org/apache/jk/status/JkStatusTask.java
Yes, thanks mark. I didn't build it, because I told Peter about the changes and he needs to do some cleanup for the jkstatus ant taks any ways. [EMAIL PROTECTED] wrote: Author: markt Date: Wed Jan 31 16:59:17 2007 New Revision: 502062 URL: http://svn.apache.org/viewvc?view=revrev=502062 Log: Fix build. I believe I implemented the intended behaviour. Rainer - can you confirm? Modified: tomcat/connectors/trunk/jk/jkstatus/src/share/org/apache/jk/status/JkStatusTask.java Modified: tomcat/connectors/trunk/jk/jkstatus/src/share/org/apache/jk/status/JkStatusTask.java URL: http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/jkstatus/src/share/org/apache/jk/status/JkStatusTask.java?view=diffrev=502062r1=502061r2=502062 == --- tomcat/connectors/trunk/jk/jkstatus/src/share/org/apache/jk/status/JkStatusTask.java (original) +++ tomcat/connectors/trunk/jk/jkstatus/src/share/org/apache/jk/status/JkStatusTask.java Wed Jan 31 16:59:17 2007 @@ -640,8 +640,8 @@ currentProject.setNewProperty(prefix + .time_to_recover_max, Integer.toString(member.getTime_to_recover_max())); currentProject.setNewProperty(prefix + .time_to_recover, -(Integer.toString(member.getTime_to_recover_min()) + -Integer.toString(member.getTime_to_recover_max()) / 2); +(Integer.toString((member.getTime_to_recover_min() ++ member.getTime_to_recover_max()) / 2))); } } - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FYI: jk 1.2.20 core on iSeries v5R3
Only depending on the number of workers (including load balancing sub workers). The unit is Kilobytes and the default is calculated for 64 workers, although, it might be slightly less at the moment. If you assume 1KB per worker, you should be on the safe side. Regards, Rainer Eric Wertman wrote: Mladen Turk wrote: Eric Wertman wrote: Connector: IfModule jk_module JkWorkersFile conf/workers.properties JkShmFile logs/mod_jk.shm JkShmSize 8192 This is 8MB of shared memory. Are you sure you have 1 workers? It wasn't obvious to me what a reasonable value of this was.. I tried everything from the default to commenting it out. At one point I set it to 1048576. It didn't seem to make much difference in any case.. what's the reccomendation for that setting? Is it purely based on number of workers, or does the size and type of data also count? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r502649 - /tomcat/connectors/trunk/jk/native/common/jk_global.h
Hi Jean-Frederic, shouldn't we be able to find out about the necessity to include it via configure? At least HP-UX should be able to use the configure mechanism. I think we mostly use the hard coded defines for the platforms, where we can't use the configure mechanism. Regards, Rainer [EMAIL PROTECTED] wrote: Author: jfclere Date: Fri Feb 2 08:27:53 2007 New Revision: 502649 URL: http://svn.apache.org/viewvc?view=revrev=502649 Log: Otherwise it doesn't compile with gcc on HPUX. Modified: tomcat/connectors/trunk/jk/native/common/jk_global.h Modified: tomcat/connectors/trunk/jk/native/common/jk_global.h URL: http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/common/jk_global.h?view=diffrev=502649r1=502648r2=502649 == --- tomcat/connectors/trunk/jk/native/common/jk_global.h (original) +++ tomcat/connectors/trunk/jk/native/common/jk_global.h Fri Feb 2 08:27:53 2007 @@ -142,7 +142,7 @@ #include netinet/tcp.h #include arpa/inet.h #include sys/un.h -#if !defined(_OSD_POSIX) !defined(AS400) !defined(CYGWIN) +#if !defined(_OSD_POSIX) !defined(AS400) !defined(CYGWIN) !defined(HPUX11) #include sys/socketvar.h #endif #if !defined(HPUX11) !defined(AS400) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- kippdata informationstechnologie GmbH Bornheimer Str. 33a 53111 Bonn Tel.: 0228/98549-0 Fax: 0228/98549-50 www.kippdata.de === kippdata informationstechnologie GmbH Bornheimer Str. 33a D-53111 Bonn Tel.: +49/0228/98549-0 Fax: +49/0228/98549-50 www.kippdata.de - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r502649 - /tomcat/connectors/trunk/jk/native/common/jk_global.h
I can't test on HP-UX, but maybe you (jfc) could try: Index: configure.in === --- configure.in(revision 502659) +++ configure.in(working copy) @@ -139,6 +139,10 @@ dnl check for filio.h used on Solaris to define FIONREAD ioctl. AC_CHECK_HEADERS(sys/filio.h) +dnl check for socketvar.h and select.h not used on HPUX11 +AC_CHECK_HEADERS(sys/socketvar.h) +AC_CHECK_HEADERS(sys/select.h) + AC_DEFUN([JK_CHECK_SETSOCKOPT], [ AC_MSG_CHECKING(whether to use $1 with setsockopt()) AC_TRY_RUN([ Index: common/jk_global.h === --- common/jk_global.h (revision 502659) +++ common/jk_global.h (working copy) @@ -142,10 +142,10 @@ #include netinet/tcp.h #include arpa/inet.h #include sys/un.h -#if !defined(_OSD_POSIX) !defined(AS400) !defined(CYGWIN) !defined(HPUX11) +#if !defined(_OSD_POSIX) !defined(AS400) !defined(CYGWIN) !defined(HAVE_SYS_SOCKETVAR_H) #include sys/socketvar.h #endif -#if !defined(HPUX11) !defined(AS400) +#if !defined(HAVE_SYS_SELECT_H) !defined(AS400) #include sys/select.h #endif #endif Of course you would need to rebuild configure via buildconf.sh after changing configure.in. Regards, Rainer Jim Jagielski wrote: Don't we also have a HPUX11 specific check like the 2nd line after this one? Seems consistent to me :/ On Feb 2, 2007, at 12:14 PM, Rainer Jung wrote: Hi Jean-Frederic, shouldn't we be able to find out about the necessity to include it via configure? At least HP-UX should be able to use the configure mechanism. I think we mostly use the hard coded defines for the platforms, where we can't use the configure mechanism. Regards, Rainer [EMAIL PROTECTED] wrote: Author: jfclere Date: Fri Feb 2 08:27:53 2007 New Revision: 502649 URL: http://svn.apache.org/viewvc?view=revrev=502649 Log: Otherwise it doesn't compile with gcc on HPUX. Modified: tomcat/connectors/trunk/jk/native/common/jk_global.h Modified: tomcat/connectors/trunk/jk/native/common/jk_global.h URL: http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/common/jk_global.h?view=diffrev=502649r1=502648r2=502649 == --- tomcat/connectors/trunk/jk/native/common/jk_global.h (original) +++ tomcat/connectors/trunk/jk/native/common/jk_global.h Fri Feb 2 08:27:53 2007 @@ -142,7 +142,7 @@ #include netinet/tcp.h #include arpa/inet.h #include sys/un.h -#if !defined(_OSD_POSIX) !defined(AS400) !defined(CYGWIN) +#if !defined(_OSD_POSIX) !defined(AS400) !defined(CYGWIN) !defined(HPUX11) #include sys/socketvar.h #endif #if !defined(HPUX11) !defined(AS400) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --kippdata informationstechnologie GmbH Bornheimer Str. 33a 53111 Bonn Tel.: 0228/98549-0 Fax: 0228/98549-50 www.kippdata.de === kippdata informationstechnologie GmbH Bornheimer Str. 33a D-53111 Bonn Tel.: +49/0228/98549-0 Fax: +49/0228/98549-50 www.kippdata.de - 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] -- kippdata informationstechnologie GmbH Bornheimer Str. 33a 53111 Bonn Tel.: 0228/98549-0 Fax: 0228/98549-50 www.kippdata.de === kippdata informationstechnologie GmbH Bornheimer Str. 33a D-53111 Bonn Tel.: +49/0228/98549-0 Fax: +49/0228/98549-50 www.kippdata.de - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r502649 - /tomcat/connectors/trunk/jk/native/common/jk_global.h
You are right. Jim Jagielski wrote: On Feb 2, 2007, at 12:36 PM, Rainer Jung wrote: I can't test on HP-UX, but maybe you (jfc) could try: -#if !defined(_OSD_POSIX) !defined(AS400) !defined(CYGWIN) !defined(HPUX11) +#if !defined(_OSD_POSIX) !defined(AS400) !defined(CYGWIN) !defined(HAVE_SYS_SOCKETVAR_H) #include sys/socketvar.h #endif -#if !defined(HPUX11) !defined(AS400) +#if !defined(HAVE_SYS_SELECT_H) !defined(AS400) #include sys/select.h #endif #endif Hmmm Isn't that backwards? Don't we want to include these headers if the autoconf macros *are* defined? So why not just: #if defined(HAVE_SYS_SOCKETVAR_H) #include sys/socketvar.h #endif #if defined(HAVE_SYS_SELECT_H) #include sys/select.h #endif or I must be missing something (wouldn't be the 1st time) :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- kippdata informationstechnologie GmbH Bornheimer Str. 33a 53111 Bonn Tel.: 0228/98549-0 Fax: 0228/98549-50 www.kippdata.de === kippdata informationstechnologie GmbH Bornheimer Str. 33a D-53111 Bonn Tel.: +49/0228/98549-0 Fax: +49/0228/98549-50 www.kippdata.de - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 6.0.x release process update
Remy Maucherat wrote: Hi, I propose the following release process for Tomcat 6.0.x: 1. create tarball and unofficial binaries, put them on people.apache.org/~remm/tomcat-6 2. announce candidate binaries are available for testing 3. wait 2-3 days for testing 4. call for alpha/beta/stable vote on build 5. 3 +1's later publish previously created tarball and binaries to www.apache.org/dist/tomcat/tomcat-6 6. wait 2-3 days for voting to complete and/or for more testing 7. announce release after sync of the website Votes ? +1 Rémy Rainer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r507923 - in /tomcat/connectors/trunk/jk/native: apache-1.3/mod_jk.c apache-2.0/mod_jk.c
Mladen Turk wrote:
[EMAIL PROTECTED] wrote:
Log:
Fix bug in adding content-length header (BZ 41610).
Analyzed and patch contributed by Boris Maras.
if (need_content_length_header
-!strcasecmp(s-headers_values[i],
content-length)) {
+!strcasecmp(s-headers_names[i],
content-length)) {
I simply cannot believe it!
The faulty code originates back from 1.2.6 (or even before)...
I couldn't believe it either. I'm happy, that we are getting more users
sharing the burden of finding the glitches.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r509173 - in /tomcat/connectors/trunk/jk: native/apache-1.3/mod_jk.c native/apache-2.0/mod_jk.c xdocs/miscellaneous/changelog.xml xdocs/reference/apache.xml xdocs/webserver_howto/apac
Hi Mladen, until 1.2.19 JkEnvVar would throw apache configuration error, if only called with one argument. The behaviour of 1.2.20 and 1.2.21 is the same as before, if you use a second argument. It was only in 1.2.20, that we introduced the possibility to omit the second argument, so give no default value. In this case, if during runtime the variable gets set, again there is no change in behaviour. The only change is, if you use a config that was syntactically wrong before 1.2.20 and your variable does not get set during runtime. Then 1.2.20 would forward an empty string, and 1.2.21 will not forward the variable. I changed the documentation accordingly. Somehow the additional case in 1.2.20 was implemented with wrong behaviour by me in December. Why is that change interesting? tomcat has an attribute condition for the access log, that allows to not log a request, whenever the given request attribute is set. Unfortunately the implementation checks for the attribute being set, an empty string counts as set. It would be nice, if one could use mod_setenvif, to set the attribute e.g. for the probing requests from the external load balancers, systems management etc. and thus keep them seperate in the tomcat logs. One is tempted to think, that one could remove the empty attribute in a tomcat servlet filter, but unfortunately a servlet filter can not delete attributes coming via mod_jk (which might be a bug in itself, but is much more difficult to fix). By not sending the variable if it has no default and doesn't get set during runtime, JkEnvVar and condition are able to smoothly interoperate. Regards, Rainer Mladen Turk wrote: [EMAIL PROTECTED] wrote: /* env_name is mandatory, default_value is optional. - * No value means set the variable to an empty string. + * No value means send the attribute only, if the env var is set during runtime. */ Think this will break any existing configuration. Something like that cannot be part of the 1.2.x branch thought. The directive bJkEnvVar/b allows you to forward environment variables from Apache server to Tomcat engine. The variables can be retrieved on the Tomcat side as request attributes. You can add a default value as a second parameter to the directive. -If the default value is not given explicitely, the empty string -will be used as a default. +If the default value is not given explicitely, the variable +will only be send, if it is set during runtime. What will be send in this cases: JkEnvVar FOO1 JkEnvVar FOO2 BAR 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: svn commit: r509173 - in /tomcat/connectors/trunk/jk: native/apache-1.3/mod_jk.c native/apache-2.0/mod_jk.c xdocs/miscellaneous/changelog.xml xdocs/reference/apache.xml xdocs/webserver_howto/apac
Please read my reply describing the detailed consequences of this change. The behaviour only changes n a corner case, which only exists since our latest version 1.2.20, wihch is not very old. everything that was possible with JkEnvVar before 1.2.20 neither changed in 1.2.20 not due to this patch. Regards, Rainer Jim Jagielski schrieb: On Feb 19, 2007, at 9:44 AM, Mladen Turk wrote: [EMAIL PROTECTED] wrote: /* env_name is mandatory, default_value is optional. - * No value means set the variable to an empty string. + * No value means send the attribute only, if the env var is set during runtime. */ Think this will break any existing configuration. Something like that cannot be part of the 1.2.x branch thought. If it does break existing configs, and therefore introduces a regression, then -1 on the patch. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Releasing mod_jk 1.2.21
What is still open: A Henri's core dumps on iSeries B The other user with protocol corruption on AIX for worker MPM C Porting 41439 from IIS to Apache and maybe D New design of interaction of mod_jk ForwardDirectories and httpd DirectoryIndex (BZ 41430, BZ 36121) E BZ 41330/40310 F Investigation, if it would be easy to allow Apache to send ErrorPages instead of Tomcat (centralized error page management). I would like to give A-C a chance until end of the week and would then inform the list on monday, give a couple of days for reviewing on p.a.o and tag around Feb, 28, so that we can have a voted release around the first March weekend. Does that sound good? Regards, Rainer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Releasing mod_jk 1.2.21
Mladen Turk wrote: Rainer Jung wrote: What is still open: I would like to give A-C a chance until end of the week and would then This week or a next? We have a Security issue that requires release ASAP. This week. I would be interested in the Security issue. If appropriate use direct communication. Regards, Mladen. Regards, Rainer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
