Re: State of affairs for mod_jk 1.2.20
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]
Re: svn commit: r479316 [2/2] - /tomcat/connectors/trunk/jk/native/common/jk_status.c
[EMAIL PROTECTED] wrote: Modified: tomcat/connectors/trunk/jk/native/common/jk_status.c URL: http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/common/jk_status.c?view=diff&rev=479316&r1=479315&r2=479316 == --- tomcat/connectors/trunk/jk/native/common/jk_status.c (original) +++ tomcat/connectors/trunk/jk/native/common/jk_status.c Sun Nov 26 01:17:17 2006 @@ -38,6 +38,82 @@ There are few compile time warnings: jk_status.c \jk\native\common\jk_status.c(1914) : warning C4101: 'i' : unreferenced local variable \jk\native\common\jk_status.c(1947) : warning C4101: 'i' : unreferenced local variable \jk\native\common\jk_status.c(1978) : warning C4101: 'i' : unreferenced local variable \jk\native\common\jk_status.c(2275) : warning C4018: '<' : signed/unsigned mismatch \jk\native\common\jk_status.c(2618) : warning C4018: '<' : signed/unsigned mismatch - 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
Rainer Jung wrote: since this has already been out in the wild for a few month, You are right. I've reverted the commit. I thought it was introduced more recently. The name should be fine, although it is a little bit strange (route or jvmroute would fit better thought) Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r479317 - in /tomcat/tc6.0.x/trunk/java/org/apache/coyote/ajp: AjpAprProcessor.java AjpProcessor.java Constants.java
Remy Maucherat wrote: [EMAIL PROTECTED] wrote: +Integer i = responseTransHash.get(header.toLowerCase(Locale.US)); -0. The String operations take away any benefit this could have. Perhaps for CPU usage on the Tomcat, that is annihilated by the lower processing on the mod_jk side. Also the network traffic is much lower. The standard header having Content-Type, Content-Length and Date is 30 bytes smaller. If we can guarantee header names will always be in the proper case, the toLowerCase can be omitted, or by using something other to compare with array of string. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat web site admin problems.
Remy, Can you change the permissions for the files in /x1/www/tomcat.apache.org/tomcat-6.0-doc-v6.0.2 from 0644 to 0664? Add group write permission, so other can modify the docs. I know, it's a version related, but we should not create a new tag if there is error in the docs thought. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[TC6] Minimum coding style
Hi,
Just committed two files, and again I've bumped
upon the coding style.
Although it seems we are quite good relating to the
tabs, the trailing spaces are a real mess in some files.
There are lots of files where we have
if (...) {
followed with the one or more spaces.
Also there are lots empty lines that contains only
one more space chars.
I propose I make a simple script that will remove
all the trailing spaces from all files in the repository,
and after that we should take care on that just like
we take care on tabs.
I know it's not something critical, but neither are
unused imports, etc...
IMHO, it's better to do that at once rather then
having commits changing lots of irrelevant coding style
related issues.
Comments?
Regards,
Mladen.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [TC6] Minimum coding style
Remy Maucherat wrote: Mladen Turk wrote: Comments? -1. This will screw up diffs, and these really irrelevant things will be added back very quickly. Tabs is one thing since it can be hard to work with, but this is simply ridiculous. Right, but at least the empty lines with spaces are very well ridiculous, don't you think? Most of those things come as a copy/paste from older Tomcat versions. Also, don't do commits that include these cosmetic changes and real changes if you can avoid it. I'm using editor (UltraEdit) that has an option to remove the trailing spaces on save. I'm sure most other editors have something similar, so I occasionally forget the rule of different ASF project. Anyhow, we still don't have a release for TC6, so we might consider cleaning up the code style at this early stage. Also, I love the Filip style (sorry if that doesn't originates from you): for example, MessageDispatchInterceptor: }//end if }//sync }//end if Now, that is what I call ridiculous. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [TC6] Minimum coding style
Remy Maucherat wrote: -1 for enforcing any coding style (except tabs, since it can make code unreadable very easily). You must be joking, right? Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [TC6] Minimum coding style
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]
Re: svn commit: r480552 - in /tomcat/tc6.0.x/trunk: java/org/apache/coyote/ajp/ java/org/apache/coyote/http11/ java/org/apache/tomcat/util/net/ webapps/docs/config/
Remy Maucherat wrote: [EMAIL PROTECTED] wrote: Author: mturk Date: Wed Nov 29 04:26:37 2006 New Revision: 480552 URL: http://svn.apache.org/viewvc?view=rev&rev=480552 Log: Commit the voted keepAliveTimeout patch. It is still as bad as what the original version was. -1 for this, +0 for my modified version. I really don't care about your -1. I've collected enough votes, so feel free to issue a veto. IMHO it's a simple additional directive, that can only help tuning the Tomcat. By default the conf is the same like before. So, you can either veto my patch and all the votes, or simply ... Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r480558 - in /tomcat/tc6.0.x/trunk/java/org/apache: catalina/core/ coyote/ajp/ coyote/http11/ tomcat/util/net/
[EMAIL PROTECTED] wrote: Author: remm -timeout = keepAliveTimeout * 50; +timeout = soTimeout * 50; -sendfilePollset = allocatePoller(size, pool, keepAliveTimeout); +sendfilePollset = allocatePoller(size, pool, soTimeout); -sendfilePollset = allocatePoller(size, pool, keepAliveTimeout); +sendfilePollset = allocatePoller(size, pool, soTimeout); -sendfilePollset = allocatePoller(size, pool, keepAliveTimeout); +sendfilePollset = allocatePoller(size, pool, soTimeout); Beside you changed my patch without asking anyone, you made the entire patch unusable and pointless. Looks like we can do few things: 1. Revert your patch 2. Revert mine patch 3. Go on and forget all about programming, and do some shepherding. So, please, unless you are going to adopt 3), revert your patch for my patch. You know, Tomcat is not your private backyard, and we have some rules, weather you like them or not. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r480558 - in /tomcat/tc6.0.x/trunk/java/org/apache: catalina/core/ coyote/ajp/ coyote/http11/ tomcat/util/net/
Remy Maucherat wrote: Mladen Turk wrote: Looks like we can do few things: 1. Revert your patch 2. Revert mine patch 3. Go on and forget all about programming, and do some shepherding. So, please, unless you are going to adopt 3), revert your patch for my patch. You know, Tomcat is not your private backyard, and we have some rules, weather you like them or not. Sendfile is for processing the request (sending a file), as a regular servlet does. It is thus normal to use soTimeout, since keepAliveTimeout is the maximum amount of time between requests. It is the same for the comet poller. Look, the keepAliveTimeout defaults to soTimeout. Further more I collected enough votes, so your explanation is useless. So either you'll revert the commits to my patches, or I'll do them. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r480558 - in /tomcat/tc6.0.x/trunk/java/org/apache: catalina/core/ coyote/ajp/ coyote/http11/ tomcat/util/net/
Remy Maucherat wrote: Mladen Turk wrote: Further more I collected enough votes, so your explanation is useless. I am free to commit things, especially since I actually fixed some of your patch. You are free to veto my commit, in which case it would be time to take this to the PMC for resolution, as I would stand by my veto of your original patch unless it is adjusted according to my changes. Of course you are entitled to commit anything, as well as any committer is. I just wonder what would happen if this would be an *open source* project. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Tomcat 6.0.3 alpha release
+1 BTW, Can we make minimum native version required for 6.0.x to 1.1.7 (It's 1.1.3 right now copied from 5.5.x)? I mean there was no released versions of 6.0, and the latest one has more stable API. Regards, Mladen. Remy Maucherat wrote: Hi, In line with what Filip wanted to have, I propose releasing a new 6.0.3 test build, which will incorporate the fixes that have been made since 6.0.2. Comments ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Smooth applications migration in a J2EE cluster [mod_jk]
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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r481745 - in /tomcat/connectors/trunk/procrun/bin: tomcat5.exe tomcat5.exe.amd64 tomcat5w.exe tomcat5w.exe.amd64
Remy Maucherat wrote: [EMAIL PROTECTED] wrote: Author: mturk Date: Sun Dec 3 01:49:18 2006 New Revision: 481745 URL: http://svn.apache.org/viewvc?view=rev&rev=481745 Log: Update binaries with --ServiceUser/ServicePassword option. Modified: tomcat/connectors/trunk/procrun/bin/tomcat5.exe tomcat/connectors/trunk/procrun/bin/tomcat5.exe.amd64 tomcat/connectors/trunk/procrun/bin/tomcat5w.exe tomcat/connectors/trunk/procrun/bin/tomcat5w.exe.amd64 There is likely a glitch with those new binaries: logs end up in weird folders when installing (in the start menu for Tomcat /stop, or in webapps/stop folder in the installed directory; it depends). This does not appear to be caused by the installer (6.0.2 does not have the problem). Right, my bad. I've updated the binaries. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r482093 - /tomcat/connectors/trunk/jk/native/common/jk_status.c
Rainer Jung wrote: I think it's perfectly valid having to simply use "&" in URLs, no need to encode. On the other hand as long as we don't have a proper decoding for the incoming URLs and I don't know, if all supported web servers decode before putting the query string into our service struct, I would prefer to stick with the original notation (not encoded). Hmm, we have a strong DTD, and the tidy is complaining about &. Although I agree we can simply use & instead & Not sure what is more valid. Regards, Mladen. - 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/
Rainer Jung wrote: 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". Sure, makes sense. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk release preparation: ready for test
Henri Gomez wrote: BTW, windows binaries are very welcome ! I'll prepare them later today, and hand them over to the Rainer. (Well I'll put them on my people.a.o) Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk release preparation: ready for test
Henri Gomez wrote: There is still a serious problem in jk 1.2.20 when flushing some large file (ie: PDF). Hard to tell without some test case and config files. What is the socket_timeout, what is the ServerTimeout? Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk release preparation: ready for test
Henri Gomez wrote: FYI, when I disable use of Apr, the problem disappears. Does it works with AjpProtocol (not AjpAprProtocol) By default if native load fails, the JK connector is used, that is different then Ajp connector. Can you set the protocol="org.apache.coyote.ajp.AjpProtocol" and if is fails as well? In case it doesn't, then it's probably a native fault. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk release preparation: ready for test
Henri Gomez wrote: As I said, when I removed APR, it works I commented APR listener and remove the libtcnative.so from LIBRARY_PATH Yes, I figured that out, but when removing native, the org.apache.coyote.jk. will be used that is different from o.a.c.ajp so, just set protocol="org.apache.coyote.ajp.AjpProtocol" This is not APR protocol, it plain Java! Regards, Mladen 2006/12/7, Mladen Turk <[EMAIL PROTECTED]>: Henri Gomez wrote: > FYI, when I disable use of Apr, the problem disappears. > Does it works with AjpProtocol (not AjpAprProtocol) By default if native load fails, the JK connector is used, that is different then Ajp connector. Can you set the protocol="org.apache.coyote.ajp.AjpProtocol" and if is fails as well? In case it doesn't, then it's probably a native fault. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk release preparation: ready for test
Henri Gomez wrote: Used : So, it's either AjpAprProtocol or native fault. In any case its not mod_jk fault. Just file the BZ report. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk release preparation: ready for test
Henri Gomez wrote: it's a seems to be a tomcat-native (1.1.7) problem And since we discuss Tomcat 6.0.4 release, should we consider that error as a show stopper ? No. It works quite fine on Solaris and RHEL, as well on HP-UX and Windows. I simply cannot reproduce this problem. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Tomcat 6.0.4 alpha build
+1 Remy Maucherat wrote: Replacing the 6.0.3 tag, with fixes for the visible glitches: http://people.apache.org/~remm/tomcat-6/v6.0.4/ Votes ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OT] Windows cmd parsing
Hi, If anyone has access to the Windows 2000 or Windows NT 4.0 (I have 2k3 and XP, so I know its working), can you do the following: Open cmd.exe C:> set "FOO=FOO BAR" C:> echo %FOO% And give me the output? The problem is that I'm not sure how pre-XP handles the SET directive is there is a single quoted param containing '=' Thanks, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Windows cmd parsing
Fenlason, Josh wrote: Microsoft Windows 2000 [Version 5.00.2195] (C) Copyright 1985-2000 Microsoft Corp. C:\Documents and Settings\stagecoach>set "FOO=FOO BAR" C:\Documents and Settings\stagecoach>echo %FOO% FOO BAR Excellent, so it works on 2K as well! Thanks, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tagging tomcat-native 1.1.8
Hi, I'll tag the 1.1.8 later today and put the distro files in regular places, so they can be used for Tomcat builds. BTW, can we again consider to use the minimum version required to that version (1.1.8). Although the API is compatible with 1.1.3 version, the all versions between 1.1.3 and 1.1.8 are broken for AjpAprConnector except the current Tomcat trunk. Think it'll lower down the support questions, because user will be forced to install the 1.1.8 version instead wondering why the previous version doesn't work or eats CPU. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tagging tomcat-native 1.1.8
Remy Maucherat wrote: Mladen Turk wrote: My little tweak will most likely be ported back to 5.5.x. As a result, when you install a new build, you'll get a warning, and the code will not use the problematic method by default. As a result, the forced upgrade is a waste of time for most. OK. So I am against this plan. I've stated my position already: unless there's an API change that was needed, the minimum version number should not be upgraded. Also fine. The problem we have is the 1.1.5 that eats the CPU. The 1.1.3 as minimum means that any version up to recommended is allowable, which is not the real case. Anyhow, this should at least be clearly documented if not enforced. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk 1.2.20 max_packet_size handling
Peter Rossbach wrote: Hi Rainer and Mladen, I made the paketSize port to tomcat 5.5 tree. Now, I start some testing and ... OK. Although it's not that important. It worked already via APR connector. - second use case: Test a post file upload mod_jk don't send more then 8k at a fileupload request! There is no need to send more then 8K. The only place where we need 8K+ is header packet. For post/reply the packet size is irrelevant. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [6] New wrap up release
Remy Maucherat wrote: Hi, I plan to produce a new build of Tomcat 6 incorporating the latest fixes (including a new native build). Comments ? Can you hold on for few hours (15:00 GMT) ? I've just tagged the 1.1.8, so it'll need couple of hours to sync. I'd also like to add the [INFO] logging for APR with version used when loaded successfully. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tagging tomcat-native 1.1.8
Peter Rossbach wrote: Hi I have test to compile apr at mac os x 10.4..8 intel and get following warning: src/network.c:449: warning: pointer targets in passing argument 2 of 's->net->send' differ in signedness OK. This should be resolved. Rely don't understand the vast universe of compilers that could impose such a warning. The unsigned char should always be mapped to char without warning. I really see no how the size of 'unsigned char' and size of 'char' could be different so that warning could be issued. Weired! Other problem is that poller are not created: 11.12.2006 20:17:26 org.apache.tomcat.util.net.AprEndpoint allocatePoller INFO: Failed to create poller with specified size of 8192 Looks like OS/X doesn't allow default 8192 poller size. The solution is either to increase the ulimit or add the pollerSize="xxx" to the APR connector. Can you see what is default maximum limit for that by lowering down the pollerSize in 1024 decrements on OS/X, so we can make that OS related like on WIN32/WIN64? If it's only ulimit dependent, then no patch should be needed. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Serious mod_jk performance issue
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: 1782908800 bytes Requests per second:3.68 [#/sec] (mean) So I see no performance degradation that would be higher then the performance needed to transfer the data twice. Anyhow, why would you like to serve the 500+ MB files trough mod_jk? The entire point is that you have the option to separate the static and dynamic content. Regards, Mladen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [6] New wrap up release
Remy Maucherat wrote: Mladen Turk wrote: I've just tagged the 1.1.8, so it'll need couple of hours to sync. I'd also like to add the [INFO] logging for APR with version used when loaded successfully. I am aware of that. It would have been a bit hard to miss given the noise level on the subject (hehe). I really do not understand the reason for the sarcasm you are spreading around all the time. Perhaps its some weired French humor that I don't get it? Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r487168 - /tomcat/tc6.0.x/trunk/res/side_left.bmp
Remy Maucherat wrote: [EMAIL PROTECTED] wrote: Author: mturk Date: Thu Dec 14 02:42:33 2006 New Revision: 487168 URL: http://svn.apache.org/viewvc?view=rev&rev=487168 Log: More artwork Modified: tomcat/tc6.0.x/trunk/res/side_left.bmp Your new bitmap does not look good to me: it's stretched. Oops. Forgot to rotate the image. It should also not read "The Apache Tomcat 6", but "Apache Tomcat 6". Done. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Releasing Tomcat Connectors 1.2.20
Rainer Jung wrote: Apache Tomcat Connectors 1.2.20 is: [X] Stable - no major issues, no regressions Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release build 6.0.6 as alpha
Remy Maucherat wrote: Hi, The vote is to release Apache Tomcat 6.0.6 as alpha. The build is located here: http://people.apache.org/~remm/tomcat-6/v6.0.6/ Votes ? The .exe installer looks really weired due to my fault because I forget to rotate the left side image :( Can you just rebuild the exe without retaging? Other the that... +1 Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release build 6.0.6 as alpha
Remy Maucherat wrote: The .exe installer looks really weired due to my fault because I forget to rotate the left side image :( Can you just rebuild the exe without retaging? The build is supposed to correspond to the tag, so it's not possible to fix it without a new tag. I supposed it would end up with something like that. Sorry again for messing the bitmap :( Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tcnative 1.1.8 -- offically released as stable?
Jess Holle wrote: Has tcnative 1.1.8 been officially released, i.e. as stable? There is no vote on tcnative releases. The vote is part of Tomcat release. It seemed like it was going to be from various votes, etc -- but I never saw any form of announcement. Given the serious issues in a number of the previous tcnative releases, we've had to disable tcnative. Tcnative is bound to the Tomcat release. The major problem is that we have releases as non mandatory. You will have INFO message in case the tcnative version is below recommended one. Of course that allows to run the tcnative versions that have known bugs. I've tried to enforce that rule, but was over voted :) Although the API is the same, I really see no reason to allow tcnative-1.1.5 (or any pre 1.1.8) running on any further Tomcat release. It would make sense if this was performance release, but since its mostly bugfix release having next Tomcat release allowing buggy tcnative versions would only bring more concerns like yours. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tcnative 1.1.8 -- offically released as stable?
Fenlason, Josh wrote: Since there is no vote on tcnative, is it always safe to say that the latest native source available in http://archive.apache.org/dist/tomcat/tomcat-connectors/native/ is as close to "official" or "stable" as it's going to get? Will tcnative 1.1.8 work with Tomcat 5.5.20? Sure it will. Also, any tcnative version (1.1.x) is API compatible so it'll work with previous Tomcat versions. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: libtcnative configure check for apr version
William L. Thomson Jr. wrote: If possible could the configure script for tomcat-native/libtcnative check for apr versions. I wasted quite some time with a libtcnative I compiled against apr 0.x instead of 1.x. Which allowed it to build, but was really tiny and not usable. If the configure checked for apr version 1.x or greater. Would have save much grief. Likely my own fault for not reading or knowing about the apr 1.x dependency. But a check in the configure script would make it idiot proof. :) Agreed. I'll take a look. However, it would be appreciated if you could provide us a patch :) Regards, Mladen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: new access log valve implementation
Takayuki Kaneko wrote: Is this beneficial? I doubt. The same could be done by simply buffering the log and then flushing to the disk on overflow. Is it beneficial? No, its misleading, because you will never know if your log data is the correct one or there is something in the write buffer waiting to be written to the log file. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Tomcat 6.0.7
Remy Maucherat wrote: Hi, 6.0.7 is: [ ] Alpha [x] Beta -- Mladen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Discussion mod_jk and mod_dir interaction
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. 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. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Discussion mod_jk and mod_dir interaction
Rainer Jung wrote: Hi Mladen, 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. The shouldn't ;) 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 Yes. It works only when they are on the same box at the first place. However the Tomcat might have different welcome file list order, and that's the problem. - 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? Basically, the entire point is that Tomcat *must* decide what should be served for a directory request by welcome file. Forcing that via foreign application is a clear breakage of the specs. The entire concept originates back from the days when most of the deployments were on the same box (having a cluster decade ago was a privilege only for few companies in the world). Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Discussion mod_jk and mod_dir interaction
Giampaolo Tomassoni wrote: Finally, it seems to me that mod_jk doesn't map a request to tomcat as a sub-request, but instead seems to tweek the req->main field, which may probably create the kind of problems reported in BZ 36121. I'm not an expert of the apache req structure nor of the mod_jk designs, but I have the "feeling" that it should go in a sub-request instead. Am I wrong? This would also allow for a probably slower, but more complete integration between Apache and Tomcat. In example, it would be (probably?) possible to detect a 404 response from Tomcat to a given DirectoryIndex name and attempt the next in list, if any. Which in turn could allow a DirectoryIndex behaviour much more uniform between the mod_jk and non-mod_jk cases. Better integration can be done by using mod_proxy_ajp that comes with Apache 2.2. Any other 'better' integration would probably require patching Apache core, and thats IMHO unfeasible by majority of users. Anything you mentioned can be done with ease using current mod_jk and standard Apache directives, but the thing one must always have in front, is the fact that Tomcat (or any other backend) is part of virtual file system, not the physical one used by Apache Httpd itself. Static content delivery by Apache requires thorough application design so that it can be served outside the application itself. This is usually done by adding separate 'static' virtual directories outside the application itself. This both ease the configuration and increases the security, because the worst thing you can do is to physically map the web application to the Apache Directory. In that case all the Tomcat and Servlet spec security is jeopardized. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Discussion mod_jk and mod_dir interaction
Giampaolo Tomassoni wrote: Any other 'better' integration would probably require patching Apache core, and thats IMHO unfeasible by majority of users. Which one? Checking the 404 response? If mod_jk adopts sub-requests to Tomcat, why should Apache get patched? Or if you mean the JkMount directive to be -based, isn't it a matter of how mod_jk handles its own directives? So, again, why would it need patching Apache? Look, I don't wish to go into discussion with you, because you obviously already have your perspective (IMHO wrong). Static content delivery by Apache requires thorough application design so that it can be served outside the application itself. No, it doesn't. The purpose of mod_jk is exactly this, I think. Company A makes a servlet-based application, which probably has both static and dynamic content, using their preferred IDE/application builder. Company B publishes it using Tomcat and Apache, and wants to avoid wasting cpu cicles and memory by allowing apache to delivery the static content, not Tomcap. Mod_jk may be used just to map a virtual space to Tomcat. It is also used to deliver static content more or less regardless of the servlet app. Of course, you may not be able to deliver *all* the static content by apache (think, in example, to the deliverable resources in Tomahawk), but most of your app's icons, css, js and the like can. An they get even cached into the client this way. What if the application is inside a .war or .sar. What then? You don't have a file system, so if you wish to have a static content served by Apache you *must* design your application accordingly. First of all you will loose auto deployers, etc... This both ease the configuration and increases the security, because the worst thing you can do is to physically map the web application to the Apache Directory. In that case all the Tomcat and Servlet spec security is jeopardized. Well, not exactly. Of course you have to know what you're doing, but often it is not that difficult: when you want to secure an area of a webapp, you often doesn't mean to secure the delivery of its static contents (who cares of icons?). You mean to do this for the dynamic part. Sure, you have to avoid downloading "META-INF/*" and "WEB-INF/*". Well, in most cases this is all you need to secure from the apache side. Also, if you need to secure some static branch of the VFS, you may just JkMount "/your_own_secure_statics/*" and rely on Tomcat to handle it... But all that requires management of two different configs. Any change in Tomcat configuration (well, for start let's forget JMX, an all other dynamic configs) would require to at least 'thinking' of what that change would mean for the Apache Httpd in front, and that simply sucks. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OT] Problems with [EMAIL PROTECTED]
Hi, Few days ago I changed my email address for Tomcat Users List with standard unsubscribe/subscribe, and although I can receive messages, send messages, I cannot see the messages send by me. (mladen_dot_turk_at_gmail_dot_com) It looks others can see the messages I sent. They are even listed on http://mail-archives.apache.org/mod_mbox/tomcat-users/200701.mbox/browser but like said, I'm not receiving the messages I send. Am I missing something trivial? Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Problems with [EMAIL PROTECTED]
Thanks Mark and Yoav! As I suspected, it is a 'trivial feature' of gmail :) Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FYI: jk 1.2.20 core on iSeries v5R3
Henri Gomez wrote: Hi to all, I built and installed the jk 1.2.20 on iSeries i5/OS V5R3 Apache 2 server to replace the previous 1.2.19. Think there was some problem with wrong printf format. Rainer fixed that post 1.2.20, but he should know better. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FYI: jk 1.2.20 core on iSeries v5R3
Eric Wertman wrote: Connector: JkWorkersFile conf/workers.properties JkShmFile logs/mod_jk.shm JkShmSize 8192 This is 8MB of shared memory. Are you sure you have 1 workers? JkLogFile logs/mod_jk.log JkLogLeveldebug Segmentation fault in sig_coredump at 0x10037590 0x10037590 (sig_coredump+0x84) 80410014lwz r2,0x14(r1) (dbx) where sig_coredump() at 0x10037590 malloc_y.malloc_y(0x2000, 0x0, 0x1fe8, 0x30411700, 0xf879614d, 0x7858c51, 0x17, 0x0) at 0xd03002c4 malloc_common.malloc_common_53_36(??) at 0xd02fd8b8 jk_pool_dyn_alloc() at 0xdc05a4c0 jk_pool_alloc() at 0xdc05a5b4 jk_b_set_buffer_size() at 0xdc06c0fc This looks like you run out of memory. We would probably need to add some checking code to the allocated buffers (if they are really allocated or not). Regards, Mladen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release build 6.0.9 as alpha
Remy Maucherat wrote: Candidate binaries are available here: http://people.apache.org/~remm/tomcat-6/v6.0.9/ Votes ? +1 Tested on Linux, Solaris, HP-UX and WIN64 Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Let's get 5.5.21 out the door...
Yoav Shapira wrote: ... it's got a lot of good and important fixes in it. Filip, you up for cutting the release, say this weekend or early next week? ++1 -- Mladen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Let's get 5.5.21 out the door...
Filip Hanik - Dev Lists wrote: yes, early next week, i'll email when I have a target time for the tag Anyhow, a thing like Remy is doing for 6.0 would be nice to have. It offers a build before official tag Can we have that for 5.5.12 as well? The RM can put 'what will be released' in his private people.apache.org so we can test without going trough the entire SVN build procedure. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Let's get 5.5.21 out the door...
Remy Maucherat wrote: Mladen Turk wrote: Anyhow, a thing like Remy is doing for 6.0 would be nice to have. It offers a build before official tag Yes, and it is useless, and it makes the release procedure days longer. Thanks to this nonsense the release procedure now takes over two weeks. If you think its a PITA, don't do it. > Unfortunately, it seems I have to do it (at least that's what one > committer who apparently likes seeing people waste their time claimed). > ??? Can you tell us who that person is? Regards, Mladen. - 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
[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)...
Boris Maras (the guy who spotted that and provided a patch)
has a name like many Croatians have. Is it coincidence ;)
Regards,
Mladen.
-
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/apach
[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 JkEnvVar 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]
Re: Releasing mod_jk 1.2.21
Jean-Frederic wrote: Hi, I think time as arrive to release 1.2.21. Are there pending changes? Or urgent ugly bugs? What about a date like Friday evening (GMT) for tagging? I don't think we'll be able to cut that before Monday. There are few pending things that needs to be ported across server. -- Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Releasing mod_jk 1.2.21
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. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Releasing mod_jk 1.2.21
Jean-Frederic wrote: C Porting 41439 from IIS to Apache You want to remove sessionid=D5E2FE08F02400159DFD6231 11F98FEE.p-ng-ptom2 from /shoppingcc/img/btn_nav_main_login.gif;jsessionid=D5E2FE08F02400159DFD6231 11F98FEE.p-ng-ptom2 do it with mod_rewrite: RewriteRule ^/(.*).gif;jsessionid=.*$ /$1.gif [PT] Right. Since Apache has mod_rewrite, use that instead. IIS comes with no mod_rewrite surrogate so strip_session makes sense as a workaround. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Releasing mod_jk 1.2.21
Rainer Jung wrote: D New design of interaction of mod_jk ForwardDirectories and httpd DirectoryIndex (BZ 41430, BZ 36121) As I said so many times, any attempt to from DirectoryIndex that will force serving something that is not part of the Tomcat's welcome file list will be vetoed. I would support only the complete removal of the entire stat logic and leave that entirely to Tomcat. IMO, the entire DirectoryIndex is complete breakage of the Servlet API, as I said so many times on the so many BZ reports having the same subject. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Releasing mod_jk 1.2.21
Rainer Jung wrote: Jean-Frederic wrote: On Fri, 2007-02-23 at 09:20 +0100, Rainer Jung wrote: What is still open: A Henri's core dumps on iSeries Wasn't it only a wrong printf? I doubt that very much, at the stack in his core didn't point to these statements. I'm still waiting for feedback from Henri. B The other user with protocol corruption on AIX for worker MPM Is there are bugzilla number for this one? No, he participated in the mail thread started by Henri on the iSeries core dump. C Porting 41439 from IIS to Apache You want to remove sessionid=D5E2FE08F02400159DFD6231 11F98FEE.p-ng-ptom2 from /shoppingcc/img/btn_nav_main_login.gif;jsessionid=D5E2FE08F02400159DFD6231 11F98FEE.p-ng-ptom2 do it with mod_rewrite: RewriteRule ^/(.*).gif;jsessionid=.*$ /$1.gif [PT] Of course I know, but you need to coordinate with your Jkmounts, so you need to duplicate your rules to detect static URLs between mod_jk and mod_rewrite. Anyhow the feature is not high on my list and I actually dropped it for 1.2.21. I have the patch for that with new directive JkStripSession On|Off definable per vhost Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Releasing mod_jk 1.2.21
Rainer Jung wrote: Yes, but then you ignore the fact, that we already have such a functionality, and that we changed it's behaviour between 1.2.19 and 1.2.20. So at least we need to decide, if it's behaviour should be - disabled completely (breaking existing configs for all versions) My favorite :) The point is that using DirectoryIndex one can force for example that index.jsp is served as default welcome file. However, the web application might have different thoughts on that subject in web.xml, and then your web application doesn't behave like it should. In fact with that you are breaking the Servlet spec, because something gets served outside the config. So, you must edit httpd.conf in parallel with web.xml (very bogus and cumbersome). Also the usage of the DirectoryIndex is possible *only* and *only when* you have a physical access to the web application's directory tree, meaning that this is limited to the negligible number of deployments where you have both Apache and Tomcat on the same box. And as last, DirectoryIndex doesn't allow you to do anything you cannot do with web.xml and except breaking it. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Releasing mod_jk 1.2.21
Jean-Frederic wrote: I also have the pending patch... To prevent typos in the properties no beeing detected what starting httpd. Should I include it? Looks like a good feature for unexperienced admins :) +1 Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Releasing mod_jk 1.2.21
Rainer Jung wrote: and we will get a lot of bug reports, if we break those. So I think all in all we should only check attributes beginning with "worker.". Right, good point. After all this is what matters. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r511252 - in /tomcat/connectors/trunk/jk/native/iis: Makefile.amd64 Makefile.vc isapi.dsp jk_isapi_plugin.c
William A. Rowe, Jr. wrote: GOOD GOD you can't be serious :) strncat strncpy exist for a reason, C's been safe for decades if only the correct functions are chosen :) Didn't say it's wrong or something like that, but beside constantly fighting with hacking and suppressing newest MS compilers security presumptions, I see nothing wrong of using provided SDK functions for MS only related code. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Releasing mod_jk 1.2.21
Jim Jagielski wrote: On Feb 23, 2007, at 1:10 PM, Jean-Frederic wrote: I also have the pending patch... To prevent typos in the properties no beeing detected what starting httpd. Should I include it? Sorry for the delay... unless it's too late, why the change from HTTP_INTERNAL_SERVER_ERROR to !OK? No it's not too late. Rainer just did a 'worm-start' :) However, Jean-Frederic already changed that back to HTTP_INTERNAL_SERVER_ERROR before release tryout. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tagging JK 1.2.21
Rainer Jung wrote: I'm travelin at the moment, otherwise I would have suggested to tag even earlier. Anyone planning to apply important changes to trunk before saturday, please show up now :) No changes. I would like to double check the IIS builds, but the testing will be done by Friday. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Releasing Tomcat Connectors 1.2.21
Jean-Frederic wrote: Apache Tomcat Connectors 1.2.21 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] Apache Tomcat JK 1.2.21 Web Server Connector released
Jean-Frederic wrote: Source distribtions can be downloaded from an Apache Software Foundation mirror at: http://tomcat.apache.org/download-connectors.cgi Can you fix the files to 664 in www.apache.org/dist for 1.2.21 ? Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] Apache Tomcat JK 1.2.21 Web Server Connector released
Jean-Frederic wrote: On Fri, 2007-03-02 at 17:34 +0100, Mladen Turk wrote: Jean-Frederic wrote: Source distribtions can be downloaded from an Apache Software Foundation mirror at: http://tomcat.apache.org/download-connectors.cgi Can you fix the files to 664 in www.apache.org/dist for 1.2.21 ? Done thanks Cool. I'll create Windows binaries as soon as the sources gets synced with mirrors. I propose we don't maintain the Apache 1.3 binaries for Win32 any more. Apache 2.0 and 2.2 binaries should be more then enough. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JK2 confusion
William A. Rowe, Jr. wrote: Since JK2 is now off the map, does it make sense to update Not even that. We are talking for more then a year for a next generation binary http(s) protocol. Almost everyone agreed that we need at least few things: 1. Encryption 2. Variable sized messages 3. Client connection close notification. Regards, -- Mladen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 6 Scales
Filip Hanik - Dev Lists wrote: The processSocketWithOptions is a blocking call, hence you wont be able to acccept new connections as long as your worker threads are all busy. Not entirely true. What we need to do, is set the socket options, then simply add the socket to the poller waiting for a read event, the poller will assign it a worker thread when one is available and the socket has data to be read. This was one of the major improvements I just did in the NIO connector. otherwise you can't accept connections fast enough and they will get dropped. Basically you simulate the OS socket implementation pending connections queue (backlog) on the OSI layer 7 instead depending on the layer 5 provided by the OS. The only beneficiary for that would be lab test environment where you have a lots of burst connections, then a void, then a connection burst again (not an real-life situation thought). The point is that no matter how large your queue is (and how it's done) if the connection rate is higher then a processing rate, your connections will be rejected at some point. So, it's all about tuning. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 6 Scales
Henri Gomez wrote: Great article ! I agree. But like Filip said, the entire NIO (as well as APR) is sort of a hack. It is obvious that the current JSE spec doesn't fit for hybrid logic (both blocking and non-blocking) because the cost of switching between them is simply to high for any practical reason. Since we have enough expertize in the subject, perhaps we can propose some additions to the JSE NIO specs that would satisfy the operations needed instead constantly hacking the NIO and trying to achieve the possible maximum out of it, or creating a new layer powered by APR for example. IMHO the initial designers of NIO overlooked couple of important aspects, and that is confirmed by the simple fact that the number of web related designs that are using NIO is negligible to the years the NIO is present as a part of JSE spec. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 6 Scales
Filip Hanik - Dev Lists wrote: Mladen Turk wrote: The ultimate goal is to have 20k connections and still handle them evenly. The question is what will you do with those 20K connections. The current servlet implementation as well as http protocol is transactional (request/response), and presumes that there is no thread context switches during that transaction. So, you are limited by design to handle the keep-alive only on the opened connection. If there is no keep-alive you are just filling the queue with incoming connections, that needs to be served by limited number of worker threads. The worker thread can be reused only when the transaction ends (request/response). True async behavior would need a true async servlet specification, with all the thread local data persisted to a socket key, but then again the memory consumption would be as large as traditional one. Of course one can always try to propose something like Restlet and hope people will start programming concurrently :) Regards, Mladen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 6 Scales
Filip Hanik - Dev Lists wrote: Remy Maucherat wrote: Mladen Turk wrote: Thanks everyone for the feedback, I'll let you know how everything progresses. Be sure to read the http://www.faqs.org/rfcs/rfc1925.html :) Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Should we release mod_jk 1.2.21.1 or 1.2.22?
Rainer Jung wrote: What's the preferred solution? [ ] Try to improve the header files for a 1.2.21.1 [X] Simply release 1.2.22 [ ] Don't release at all, wait for more fixes or features before releasing. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 6 Scales
Costin Manolache wrote: Yes, 100 concurent requests is a sign you need lb - serving 1000 on Sometimes it is desired to have the capability of serving 1000 concurrent connections (not requests). The typical situation is when the frontend server is used for delivering a static content with higher concurrency then backend application server. The thread per request model like implemented with APR connector solves this problem. NIO would need AJP protocol implementation to be able to do that as well. one server is a false problem in most cases. I would rather have a server smartly reject requests and notify a lb rather then degrading all requests by accepting more than it can handle properly. Agreed, but without some sort of IPC it's impossible. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk 1.2.22-dev test
Henri Gomez wrote: I'm tracking right now the iSeries problem (present in 1.2.20 and 1.2.21) and it's located somewhere in jk_log() (jk_util.c). That would be great, since only you reported that there is a core on that platform. Nevertheless, I presume it is either compiler or OS issue, since nothing like was detected on any other platform, and thus should not be an show stopper. Of course, it would be great if you find a problem, cause it might be silently skipped for other platform. Regards, Mladen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r518581 - /tomcat/connectors/trunk/jk/native/common/jk_shm.c
Rainer Jung wrote: Hi Mladen, I didn't really read this commit, but it's Log entry reminds me of the following: This is for shm lock, not for the shared memory, so the name is irrelevant, and will be destroyed on exit. Also, we store workers in shared memory, so any attempt to have a shared memory between instances is tricky, because it can lead to a total mess if the configuration is not exactly the same (even ordering matters). Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r518581 - /tomcat/connectors/trunk/jk/native/common/jk_shm.c
Jim Jagielski wrote: Do we *really* want 0666 on these things? Wouldn't 0644 be better? Of course. I just made that compile time enabled for faulty kernels. I'll check if the 0644 works for flock. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r518581 - /tomcat/connectors/trunk/jk/native/common/jk_shm.c
Jim Jagielski wrote: On Mar 15, 2007, at 9:36 AM, Mladen Turk wrote: Jim Jagielski wrote: Do we *really* want 0666 on these things? Wouldn't 0644 be better? Of course. I just made that compile time enabled for faulty kernels. I'll check if the 0644 works for flock. It should... these are opened early enough and since the fd's are shared, the subprocesses/threads should still have access. Under Apache 1.3 we even have them 0600 :) Right, this is for shared descriptors. The patch does not work unless you set umask(0), so it's actually 0666. By default umask is 0022, so lock file was 0644 and the open( O_RDWR) in child fails with EPERM. Anyhow, this is for rare cases where there is a kernel bug with shared files and flock, and disabled unless compiled manually with -DJK_SHM_LOCK_REOPEN. Of course this lowers the security of the system, cause you have /tmp/jkshmlock.X file with -rw-rw-rw Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r518581 - /tomcat/connectors/trunk/jk/native/common/jk_shm.c
Rainer Jung wrote: I have the impression, that this would be nice for our shm file too. Right, it can be done with ease, just like we append .lock to JkShmFile we can append the pid Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r519367 - /tomcat/connectors/trunk/jni/
[EMAIL PROTECTED] wrote: Modified: tomcat/connectors/trunk/jni/ (props changed) Propchange: tomcat/connectors/trunk/jni/ -- --- svn:ignore (added) +++ svn:ignore Sat Mar 17 09:51:13 2007 Can you explain why you add that, and why we were able to live without it so far? Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r520029 - /tomcat/connectors/trunk/jk/native/apache-2.0/bldjk.qclsrc
[EMAIL PROTECTED] wrote: Author: hgomez Modified: tomcat/connectors/trunk/jk/native/apache-2.0/bldjk.qclsrc URL: http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/apache-2.0/bldjk.qclsrc?view=diff&rev=520029&r1=520028&r2=520029 == Binary files - no diff available. Why did you set the binary property for this file? It looks like a regular .txt to me. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: Vendor Notification VU#239041 - apache-tomcat]
Remy Maucherat wrote: Tomcat permits both '\' and '%5C' as path delimiters. When Tomcat is used behind a proxy (including, but not limited to, Apache HTTP server with mod_proxy and mod_jk) configured to only proxy some contexts, a HTTP request containing strings like "/\../" may allow attackers to work around the context restriction of the proxy, and access the non-proxied contexts. But this is unlikely to happen unless you explicitly add AllowEncodedSlashes and unless you physically put your webapps inside ServerRoot so they can be directly access by web server regardless of proxy used. The following Java startup options have been added to Tomcat to provide additional control of the handling of '\' and '%5c' in URLs (both options default to false): * -Dorg.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH=true|false * -Dorg.apache.catalina.connector.CoyoteAdapter.ALLOW_BACKSLASH=true|false This issue can also be solved by configuring the appropriate URL handling in the proxy server. Due to the impossibility to guarantee that all URLs are handled by Tomcat as they are in proxy servers, Tomcat should always be secured as if no proxy restricting context access was used. Comments ? Makes sense to have those double secured. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r521417 - /tomcat/connectors/trunk/jk/native/common/jk_util.c
Rainer Jung wrote: I think I added those after I was frustrated by a customer whose mod_jk logs had all non-windows line endings. Sorry, I didn't really test your change, but my experience questions this patch. With you patch the line endings were \r,\r,\n Do we need to set text mode on the file? Will this work for direct logs and piped logs? Text mode is default unless you open the file with "ab+" The "b" standing for binary. Probably not. The logs will have \n line endings unless the log rotator itself mangles them. Anyhow, either we can have binary files (using read/write) instead stdio for logs, and use platform specific lineends, or depend on the stdio provided ones. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tagging TOMCAT_NATIVE_1_1_9
Hi, I'll tag the tcnative to 1.1.9. It fixes the JVM core in case the acceptor breaks when we are inside the Socket.accept, and adds OpenBSD platform detection. -- Regards, Mladen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tagging TOMCAT_NATIVE_1_1_9
William L. Thomson Jr. wrote: I never got a chance to make patch since I am not to familiar with configure. But would be nice for tcnative, to know during configure that it needs >=apr-1.x. If a check can't be added less a patch. I will get with another Gentoo dev, and get a patch made and to you all. That would be a nice feature. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tagging TOMCAT_NATIVE_1_1_9
Filip Hanik - Dev Lists wrote: cool, yes, lets get this done before 6.0.11 Right, that is the idea, because of .tar.gz and binary dependencies. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mktemp didn't exist on i5
Henri Gomez wrote:
While rebuild trunk from mod_jk I got an error on iSeries about
missing mktemp in iSeries.
if (!jk_shmem.lockname) {
#ifnedef WHATEVER
if (shm_lock_reopen) {
int i;
jk_shmem.fd_lock = -1;
mode_t mask = umask(0);
for (i = 0; i < 8; i++) {
strcpy(flkname, "/tmp/jkshmlock.XX");
if (mktemp(flkname)) {
jk_shmem.fd_lock = open(flkname,
O_RDWR|O_CREAT|O_TRUNC, 0666);
if (jk_shmem.fd_lock >= 0)
break;
}
}
umask(mask);
}
#endif
The shm_lock_reopen is compile time anyhow.
Regards,
Mladen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: mktemp didn't exist on i5
Henri Gomez wrote: Good thanks Check now. I put that inside #ifdef JK_SHM_LOCK_REOPEN, like before, but now, the entire code is compile time dependent instead just using a var. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: strange problem on i5
Henri Gomez wrote:
It works back when jklog is :
int jk_log(jk_logger_t *l,
const char *file, int line, const char *funcname, int level,
const char *fmt, ...)
{
int rc = 0;
/* Need to reserve space for newline and terminating zero byte. */
static int usable_size = HUGE_BUFFER_SIZE-2;
return (0);
Don't get it.
This is exactly how it's in the code.
However we are using fputs instead fwrite.
Don't tell me that fputs is broken on that weired OS
as well? We are already 2 weeks behind the release
because of the fact that your box is totally POSIX
broken. I wonder, what's next?
Regards,
Mladen.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: strange problem on i5
Henri Gomez wrote: I allready told you that you didn't have to delay the release for i5 problems and you could go on with it. Sounds fair. If you came up with the patches, we can bump a next release that'll fix them. However, since we got that far I wonder why the logging is faulty. Can it be because of fputs instead fwrite, and EBCDIC? If you can, try replacing fputs with fwrite and see if it works. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
TC 6.0.X SVN repo
Hi, I have deleted and added as external trunk/native/connector, because there is no reason to have that duplicated. Perhaps the similar (via external) can be done for org/apache/tomcat/jni as well. Comments? Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r521417 - /tomcat/connectors/trunk/jk/native/common/jk_util.c
Rainer Jung wrote: Hi Mladen, I think we don't use stdio. APR has apr_file_open() which uses CreateFile() and apr_file_write() which goes back to WriteFile() on Windows. We are using stdio for other web servers, so if you add CRLF then the IIS will be broken. Perhaps opening the files as binary for windows, and then forcing CRLF will do. However this would break cygwin builds thought. I'll check 1.3 tomorrow. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r521417 - /tomcat/connectors/trunk/jk/native/common/jk_util.c
Rainer Jung wrote: Hi Mladen, I built against an installed form of the official download apache_1.3.37-win32-x86-src.msi. ... and you are using VS 2005 I suppose? That won't work cause you have different MSVCRT's Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r524660 - in /tomcat/tc6.0.x/trunk: build.properties.default java/org/apache/catalina/core/AprLifecycleListener.java res/tomcat.nsi
Remy Maucherat wrote: [EMAIL PROTECTED] wrote: Author: mturk Date: Sun Apr 1 12:37:58 2007 New Revision: 524660 URL: http://svn.apache.org/viewvc?view=rev&rev=524660 Log: Use the tomcat-native-1.1.9 as recommended version. I am against this change. Other than minor fixes, existing users should be allowed to continue using 1.1.8, I don't see any showstopper being fixed in that build. But they can use it. protected static final int TCN_REQUIRED_PATCH = 8; -protected static final int TCN_RECOMMENDED_PV = 8; +protected static final int TCN_RECOMMENDED_PV = 9; So, the minimum required is 1.1.8 Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r521417 - /tomcat/connectors/trunk/jk/native/common/jk_util.c
Rainer Jung wrote: I used 2003 .net, but this includes a 7.0 version of msvcrt.dll. I build apache httpd 1.3 by myself and then mod_jk, and now everything works as expected. So you are right, the binary httpd download is not compatible with module compilation by vc++ 7.0. Any idea how one can make vc++ 7 use the 6.0 msvcrt dll? The 6.0 dll is included in the msi for apache 1.3 from the download. You cannot do that unless you have VS 6.0. This is BTW the reason why the httpd binaries are compiled with msvcrt.dll (the binaries can be used with msvcrt71 or msvcrt80, but not the other way round). Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r521417 - /tomcat/connectors/trunk/jk/native/common/jk_util.c
Henri Gomez wrote: May be at some time in the future we should think about a mod_jk 2.x requiring and using APR to remove all platform complexity :-) Think we tried that with jk2 and failed. Even on Apache 1.3 we could have jk bundled with APR statically Don't think so. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
