Re: Building isapi_redirect on Win 2003
Lyndon Tiu wrote: Hello, I read the instructions on how to build isapi_redirect.dll on: http://jakarta.apache.org/tomcat/connectors-doc-archive/jk2/jk/iishowto.html But I am getting these errors: C:\tmp\jakarta-tomcat-connectors-1.2.14.1-src\jk\native\iismsdev isapi.dsp /make all Configuration: isapi - Win32 Release Compiling... jk_isapi_plugin.c C:\tmp\jakarta-tomcat-connectors-1.2.14.1-src\jk\native\iis\jk_isapi_plugin.c(658) : error C2065: 'S F_NOTIFY_AUTH_COMPLETE' : undeclared identifier You will need the Platform SDK at least from March 2003. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 5.5.12 Stability
Yoav Shapira wrote: Tomcat 5.5.12 is: [X] Stable - no major issues, [ ] Beta - at least one major issue: what is it? [ ] Alpha - multiple things or a real showstopper: please provide details.. Works like magic, really :) Tested with tomcat-native on WIN32, WIN64, Solaris 2.8 and SLES9/64 Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] JK 1.2.15
Hi, JK 1.2.15 has been tagged last week. Please see the: http://jakarta.apache.org/tomcat/connectors-doc/changelog.html for a full list of changes. Sources can be found at: http://www.apache.org/dist/jakarta/tomcat-connectors/jk/source/jk-1.2.15/ Please vote: [ ] Stable -- good build [ ] Alpha -- something serious is wrong: what is it? Regards, Mladen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What is correct for workers.properties.minimal
David Thielen wrote: Hi; First, what use is the load balancing if I have just one server running one instance of Tomcat? Does it load balance within that one instance? Second, what is jkstatus for? Jkstatus is used for displaying and managing load balancers and load balancer members. Since it can manage only the workers that are members of load balancer that simple configuration has been made as an example. If there is a single worker as member of load balancer the performance will be the same, because in that case the entire lb election phases are simply skipped. Of course you have the option to manage your worker at runtime. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
CVS-SVN Schedule
Hi, Any update on the schedule? I have couple of fixes, commits, etc, but IIUC the transition should happen last weekend, so I've postpone all that, but it seems that CVS is still operational. Can somebody make a firm statement on the timings? 1. Until when (Date:Hour:Minute) commits could be done 2. Wen the CVS will be locked for commit (same format) Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
JK 1.2.15 Release plan?
Hi, JK 1.2.15 has been tagged, and I've created the source distribution downloadable from the: http://www.apache.org/dist/jakarta/tomcat-connectors/jk/source/jk-1.2.15/ Since this version contains numerous bug fixes over the releases 1.2.14, what are your thoughts on that version, since it will be the last one released from the CVS. I would like to make a vote and release, because of the bugs this version is fixing, and since we would from now on use SVN the next release could take quite some time before becoming available. So, should I pursue for a [VOTE} on that tag or will we wait for a couple of months? I hope we'll not go for the latest option. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JK 1.2.15 Release plan?
Yoav Shapira wrote: Hi, I'd wait a couple of days and then have a vote. During those days we should actively encourage users to download and test it. Make release announcements, etc. ;) Right. I was deliberately choose the 'WTF' approach to the release subject, because each time I try something like that the wrowe comes in reminding me of the 'procedural misbehaving' :) So, excuse me if I broke again some f*ing rule. Anyhow, I would like that we vote this (1.2.15) version as stable, because it's a bug-fix release over the 1.2.14 stable. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Releasing JK 1.2.15
There has been couple of major bug fixes against 1.2.14, see: http://jakarta.apache.org/tomcat/connectors-doc/changelog.html They have been fixed in the CVS, and since couple of them actually makes 1.2.14 unusable on some platforms like Solaris 2.8 and Irix we need a release. I plan to tag the 1.2.15 by the end of this week, and pursue for a vote next week for this bug-fixing release. Any objections? Since there were no objections I plan to tag the 1.2.15 later this evening at 19:00 GMT. This will eventually be the last release from CVS, cause IIUC the transition will be made this weekend. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Releasing JK 1.2.15
Peter Rossbach wrote: Hey Mladen, can we also integrate the better domain loadbalancer support at jk_lb_worker.c? I think that we don't change the lb_value inside sticky mode at every request. Yes we do. They will be updated only for domain workers. This is needed to load balance between the workers that are members of the same domain. In other case the total_factor will be zero and lb_value will not be changed. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Releasing JK 1.2.15
Rainer Jung wrote: Hi Peter, Mladen and all others, I would like to follow Mladens suggestion from earlier this month to create a list of precise use cases for the load balancing, failover and administrative downtime scenarios. Right. The SVN transition is in progress, so it might be as well a good chance to create a 1.3 branch we are talking about for more then a year. Cleaning unused and dead code is one thing, and the other is making those use-cases for load balancer. I've tagged the 1.2.15 as the last one from the CVS, so if it will be voted as stable, fine, if not, we'll pursue for 1.2.16 from 1.2 branch. All new stuff and eventual config changes should go to the 1.3. branch. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Final phase of SVN migration - the plan
Mark Thomas wrote: All, The plan for the last phase is slightly different since these repositories are in pretty much constant use. I know there is a plan to do a JK release this week. If there is a timing clash, JK takes priority. Just shout and I'll delay giving infra the go-ahead to do the final migration. Please don't get limited with that fact. We can easily release from SVN, because when moved to SVN I'll have to change jkrelease.sh script to reflect the changes, so it might be as well a good opportunity for implementing that, cause consecutive release will be coming from SVN repository. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Releasing JK 1.2.15
Hi, There has been couple of major bug fixes against 1.2.14, see: http://jakarta.apache.org/tomcat/connectors-doc/changelog.html They have been fixed in the CVS, and since couple of them actually makes 1.2.14 unusable on some platforms like Solaris 2.8 and Irix we need a release. I plan to tag the 1.2.15 by the end of this week, and pursue for a vote next week for this bug-fixing release. Any objections? Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bug or Feature inside mod_jk loadbalancer algo?
Peter Rossbach wrote: Hey, I have a strange loadbalancer behaviour at a customer site with Apache 2/mod_jk 1.2.14, JVM 1.5, Tomcat 5.5.9 (cluster), (Suse 9.1) Hi guys, Peter you are correct about this... I found by myself too, that balancer is misbehaving in some cases. One of them is 'domain' model, where multiple workers should behave like one on the global scale, but still maintain internal load. The other is for worker-like mpm's when cachesize is lower then the ThreadsPerChild. I've been able to fix that (sort of), but I'm not happy with the fix. What would I suggest is that we gather all the 'use cases' and write down what the predicted results should be. I'll create a separate .txt file (that will later be part of loadbalancer howto) upon which we can enter the configuration and expected behavior. How that sounds? I'm moving this discussion to the tomcat-dev@, so that we have the trace of it. OK? Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Small refactoring in Http11Processor
Mark Thomas wrote: Costin Manolache wrote: Is there any plan to do a bit of cleanup ? Maybe move some of the dead code in connectors (mod_webap, jk2, etc ) to a new repo ? And maybe add a new 'sandbox' repository ? I'll start a new thread to gather candidates to move to the archive area. There are lots of things inside connectors that needs to be archived. For example: /ajp, /jk/native2, /jk/webapp. Also, not sure what the '/scandoc' is used for. Further more, inside jk/native the docs, domino, nt_service and isapi folders are obsolete. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/xdocs changelog.xml
Tim Whittington wrote: I'm pretty sure this patch is broken looking at it now. The HTTP_ variants used in the extension aren't initialized properly. I'm currently on the road, but I'll be able to fix this up next week. You are correct about that. I was presuming the patch is correct (may bad), but it lacks the HTTP_ prefixes. I'll correct that today or tomorrow if you don't provide a patch. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/xdocs changelog.xml
Tim Whittington wrote: I'm pretty sure this patch is broken looking at it now. The HTTP_ variants used in the extension aren't initialized properly. I'm currently on the road, but I'll be able to fix this up next week. I've just commit the fix for the previous fix :) Can you confirm if it's working for you? Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Small refactoring in Http11Processor
Costin Manolache wrote: Hi, Also, I would like to add another directory under j-t-c, with a build file and few classes for a 'mini' experiment - i.e. using the connector standalone, as a minimal http server, and also a target to build a minimal servlet container as a single self-contained jar. We don't have a sandbox, and j-t-c seems closest to that :-) Hi Costin, Nice to have you back :) Anyhow, seems that the SVN transition is in progress. If the time is acceptable, perhaps you can postpone that, and simply create a branch in SVN. I'm not sure when the code will be moved to SVN, perhaps Mark will know. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
On Vacation
To whom it may concern :) I'll be on vacation starting tomorrow for two weeks. If somebody really needs to contact me I can be reached at: +385.91.885.1068 Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat metrics
Yoav Shapira wrote: Howdy, This is just information for the curious or bored ;) Right. Good for any school project ;) result is only an approximation: 136K or so ;) And webdav used 92K? Weird. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk logging buffer
Jean-frederic Clere wrote: Radek Wierzbicki wrote: Hello, better : if (l-level JK_LOG_INFO_LEVEL || level==JK_LOG_EMERG || level==JK_LOG_ERROR) No? Flush should not be executed for INFO level. It slows the things down by the factor of 2. I agree for ERROR and EMERG. DEBUG and TRACE uses fflush so the order of messages can be traced, but that is also dubious because the messages could come from different threads, so the best would be to use the fflush only with ERROR and EMERGE levels. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: patch: mod_jk load balance algorithm that accounts for current worker load
Chris Lamprecht wrote: mod_jk developers: We have been using mod_jk for some time, (1.2.8, 1.2.10, and now 1.2.14), with Apache 2.0.50, Tomcat 5.5.9, under fedora (2.4.22 kernel). We have 6 tomcats as balanced workers, and we're using lb.method=[R]equest. Great! Can you open an bugzilla entry for Native:JK and attach the patch. Please file that as enhancement. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat Native binaries repository
Hi, As you might know due to the US export laws we are unable to deliver the binaries that include encryption software on any of our servers. Many Apache projects are suffering from that restriction, so we are not the only one :) Since TomcatNative uses OpenSSL for SLL protocol, delivering binaries would break such policy and probably make problems. Thanks to the courtesy of HEAnet, http://www.heanet.ie (Ireland's National Education and Research Network), and especially Colm MacCárthaigh, we have established an alternate download site: http://ftp.heanet.ie/pub/tomcat/ We have generic SSH username, and committers interested in building binaries can send me their SSH key, so I can send it to Colm. Once again... Many thanks to those guys! Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Alternate tomcat binaries repository
Hi, I have spoke with Colm MacCárthaigh from HEAnet an he said that they would be willing to give us the repo and SSL access to their servers so we can set up a distribution repository for SSL enabled binaries. As you might know due to the US export laws we can not have any encryption software on any of our (ASF) servers. Of course the binaries would be 'unofficial', but we can make a link to that site instead some of the exiting ones that offer the OpenSSL binaries. Any objections I proceed with that? Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk 1.2.14.1 Released?
Jess Holle wrote: Was 1.2.14.1 ever officially released? Well, it was voted as stable, so we only need announcement. If not, will it be soon? Think that Jean-Frederic will make official announcement. OTOH it might be that the heat wave in Spain put him in some deep shade :) Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] SOC temporary committer Anders Nyman
William A. Rowe, Jr. wrote: At 01:25 PM 7/11/2005, you wrote: If the ASF have some agreement with Google then it should have created a 'SoC Google sandbox' not trying to force every project to create a 'Google sandbox'. So it's unusual, and we aren't handing away keys to the entire kingdom. But setting up a sandbox (not your problem, it's the mentors) and watching the progress (if it scratches your itch) is not an imposition on the individual project communities. Well if Tim wants to mentor that project, then fine with me. I'm sure he will ensure the integrity of the Tomcat source outside that 'sandbox' repository. If the project will have access and modify the files outside that repository, I'll be strongly against that. I'm sure the Tim will find a solution for a files that needs to be changed and that are are of the core, by simply mirroring them to the sandbox repository or something similar. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JK 1.2.14 core dump oddity
William A. Rowe, Jr. wrote: Line 1971 of jk/native/apache-2.0/mod_jk.c says... return OK; /* NOT r-status, even if it has changed. */ This goes back to version 1.1 of the module; the question is; WHY? Well, mod_jk presumes that when Tomcat serves the page it is 200. You can make a custom error pages in Tomcat directly without using ErrorDocument 404 /xxx Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] JK 1.2.14.1
[X] Stable -- good build Thanks for volunteering for a RM! Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] SOC temporary committer Anders Nyman
Tim Funk wrote: As part of the Google SOC. Google accepted the tomcat-reverse-proxy project to be executed by Anders Nyman ( anders.nyman at gmail d ot com ) [ ] Sounds good to me [ ] I'm indifferent [X] I don't like it. Here's why IMO the reverse proxy is a good thing to be done, and Tomcat can benefit from it. I doubt if the balancer is a good place for such addition. Also I agree with Yoav. If the code is good, and if it works I see no reason why not including it in the code. I have developed, and I am developing the majority of the code without being connected to the CVS all the time. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] SOC temporary committer Anders Nyman
William A. Rowe, Jr. wrote: It's important for students involved with SoC to learn to use the tools of our organization; I don't agree with you. The Tomcat is not place for some 'sandbox' projects. If the ASF have some agreement with Google then it should have created a 'SoC Google sandbox' not trying to force every project to create a 'Google sandbox'. Again, I have nothing against the effort or goals or Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: j-t-c/common/build - j-t-c/jk/support ?
William A. Rowe, Jr. wrote: It turns out the common/build macros are only referenced within the jk tree (which is all I check out to build modjk). I'd like to move the apache.m4, get_ver.awk and os_apache.m4 scripts to this new home, preserving history by copying the ,v files, stripping old tags from the new copies and then cvs rm'ing the originals. Votes/comments/concerns? +1. Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: http://www.apache.org/dist/jakarta/tomcat-connectors/jk/source/
jean-frederic clere wrote: Hi, Just a note: the current files are a bit old, shouldn't they point via a link to the last released version? No, the current should point to the latest stable version. You can add dev that will point to the latest version. Regards, Mladen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native/common portable.h
[EMAIL PROTECTED] wrote: jfclere 2005/07/06 06:52:06 Modified:jk/native/common portable.h Log: just for the plaforms that don't have configure... Revision ChangesPath 1.4 +110 -0jakarta-tomcat-connectors/jk/native/common/portable.h Why did you commit that? It should be zero, because WIN and Netware will fail to build. The portable.h is generated with configure, not in the CVS. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native/common portable.h
jean-frederic clere wrote: Mladen Turk wrote: Why did you commit that? First because it was not up to date, I have not added it... For something weird plaforms it is nice to have it instead having to get it's content. Hmm, portable.h is generated from portable.h.in on platforms that have ./configure scripts at the first place. All other platforms simply don't use it, but the file exists so that we don't need extra #ifdef's Right... That is a pitty to break Netware - I will add the file as portable.h.sample and restore the old one - What would be the purpose of that sample? I mean, it is generated, so each platform has more or less unique one. If the configure can not generate the platform.h from platform.h.is, what's the purpose of the configure at the first place? Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Releasing JK 1.2.14
jean-frederic clere wrote: Done, the branch is ready. The files are in http://people.apache.org/~jfclere/jakarta-tomcat-connectors/ Hmm, it will not do. The .zip files should have .dsp files (at least) in CR-LF format. Think you'll need a win platform for making those. If you don't have one, I can build a .zip files. Regards, Mladen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OT] No software patents in Europe
Hi all, Sorry for the off-topic post, but IMHO this is a great news for all of us (free software developers). After years of struggle, the European Parliament finally rejected the software patent directive with 648 of 680 votes: A strong signal against patents on software logic, a sign of lost faith in the European Union and a clear request for the European Patent Office (EPO) to change its policy: the EPO must stop issuing software patents today More on: http://www.fsfeurope.org/ Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Releasing JK 1.2.14
William A. Rowe, Jr. wrote: Assuming you have apr checked out, apr/build/lineends.pl --cr will convert a tree to cr/lf dos format, and info-zip does a lovely job on Unix of zipping it up. Right, a smarter unix2dos :) Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jni error
jean-frederic clere wrote: Hi, I have the following error when compiling: +++ src/file.c 502: [error]: CFE1136 struct JNINativeInterface_ has no field GetDirectBufferAddress char *bytes = (char *)(*e)-GetDirectBufferAddress(e, buf); ^ +++ My java version is 1.3.1, why are we requiring a very new one? Yes, GetDirectBufferAddress is NIO feature of the 1.4 Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/tools jkrelease.sh
[EMAIL PROTECTED] wrote: +# Check for links or w3m +W3MOPTS=-dump -cols 80 -t 4 -S -O iso-8859-1 -T text/html +LNKOPTS=-dump Great, but I think that the links/elinks options should be: --dump --no-references --no-numbering --no-home That's at least for the elinks, but I suppose the links should have something similar. Just using dump will make the output pretty unfriendly ;) In fact, the reason why I choose w3m was because it can give a very clean .txt output. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/tools jkrelease.sh
jean-frederic clere wrote: no: links only wants -dump, but I have not problems to add elinks. Well, whatever. Didn't try the links (only elinks) so could not tell. My SuSE is coming with w3m, so I don't really care ;) Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/tools jkrelease.sh
jean-Frederic clear wrote: Mladen Turk wrote: [EMAIL PROTECTED] wrote: no: links only wants -dump, but I have not problems to add elinks. Also, how about you volunteer for a 1.2.14 RM? I was doing that for the last year and I'm getting pretty tired ;) I will build as many binaries as I can. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/tools jkrelease.sh
Henri Gomez wrote: +0, JF act as RM :) Why? He is a nice guy. He is even younger then Bob Geldof, so what the obstacle for some altruism ;) Cheers, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/tools jkrelease.sh
Henri Gomez wrote: Because JFC is a great guy and someone I meet often. He he. And yes he will be a great RM :) Go JFC, go Right. I think he can take some responsibility, if he mess up, we'll kidnap his hamsters :) Cheers, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/tools jkrelease.sh
jean-frederic clere wrote: Well there are still 20 bugs in tomcat5/mod-jk, what do with them? Not sure. Lot's of obsolete things that need a simple cleanup. I can only tell the current CVS is the best ever mod_jk we had. If it builds on all platforms (ant it does AFAICT), we should go for the release ASAP. There are just too many things that has been fixed since last stable, that we should ignore or try to wait much further. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkMain.java
Bill Barker wrote: Actually, on Solaris the big winner is ChannelNioSocket. It wins the performance race easily now. Too bad that NIO on Windows s*cks. I guess that JFA was right, and non-blocking sockets is the way to go. He he. We shall see :) Now that I've looked at it a lot, however, I dislike the Java AJP impl, as it's way overengineered in comparison to what it required by the current Tomcat. Hey, I like the overengineering ;-). Yeah, Costin got a little ambitious here before deciding to just use Coyote. On the other hand, when Mladen wants you to implement unix sockets for AJP/APR, ChannelUn is going to start to look good ;-). Well, ChannelUn is obsolete because there is no need to add the additional JNI wrapper, because we already have one. Both unix sockets and NT pipes will be supported, by adding a single param 'localAddress' or something. The platform local socket AF_UNIX or NTPIPE will be used depending on the platform itself. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkMain.java
Jeanfrancois Arcand wrote: Actually, on Solaris the big winner is ChannelNioSocket. It wins the performance race easily now. Too bad that NIO on Windows s*cks. I guess that JFA was right, and non-blocking sockets is the way to go. He he. We shall see :) :-). Just take a look at the GlassFish module called appserv-http-engine on java.net (http://weblogs.java.net/blog/jfarcand/). I'm sure you will like it :-). And I'm sure this community can come with something even better Well I'm sure only of the following: 1. Blocking sockets outperforms NIO 2. NIO scales better So the ideal would be to have them both at once. Perhaps one day the Sun will accept some of my ideas and allow to intermix the blocking and nonblocking IO. Until then, well, I have 64 bit JVM and a 1GB RAM for couple of bucks, and APR of course :) Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Releasing JK 1.2.14
Hi all, Anyone aware of any pending issues for the next release. Seems that all the bugs has been resolved from the 1.2.13. If there are no objections, we can make a release by the end of this week. How that sounds? Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Releasing JK 1.2.14
Henri Gomez wrote: could you provide a beta source tarball to make the usual iSeries builds ? Well, you have the j-t-c/tools/jkrelease.sh But I've put the current head at: http://people.apache.org/~mturk/jakarta-tomcat-connectors-current-src.tar.gz Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Releasing JK 1.2.14
jean-frederic clere wrote: Mladen Turk wrote: In file included from mod_jk.c:28: /home/jfclere/usr/local/apache2/include/ap_config.h:21:23: apr_hooks.h: No such file or directory You apache installation sucks :) Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Releasing JK 1.2.14
jean-frederic clere wrote: apr_hooks.h is in /home/jfclere/usr/local/apr-util/include/apr-1/apr_hooks.h, probably something more is needed in configure. Try to run the: apxs2 -q APU_INCLUDEDIR Seems that: apxs2 -q INCLUDEDIR is giving the /home/jfclere/usr/local/apache2/include and 'apxs2 -q APR_INCLUDEDIR' is giving the /home/jfclere/usr/local/apr/include/apr-1 The solution is to eiter copy APU_INCLUDEDIR to the INCLUDEDIR, or figure out why APU_INCLUDEDIR gives nothing or points to the wrong location. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Releasing JK 1.2.14
jean-frederic clere wrote: Try to run the: apxs2 -q APU_INCLUDEDIR it tells: +++ [EMAIL PROTECTED]:~ usr/local/apache2/bin/apxs -q APU_INCLUDEDIR /home/jfclere/usr/local/apr-util/include/apr-1 +++ That's bad. It should point to your apr-utils/include. It's probably the apxs broken, and I doubt you'll be able to compile *any* module, not just jk. The solution is to eiter copy APU_INCLUDEDIR to the INCLUDEDIR, Should I fix it? Well, the majority of apache distributions either have all httpd, apr and apr-utils includes in a single directory. The only difference is RHEL that has that separated, but even there both apr and apr-utils includes are in the single directory. Anyhow, it has nothing to do with the mod_jk. He correctly queries and populates those include dirs if the apxs reports them correctly. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Releasing JK 1.2.14
jean-frederic clere wrote:
it tells:
+++
[EMAIL PROTECTED]:~ usr/local/apache2/bin/apxs -q APU_INCLUDEDIR
/home/jfclere/usr/local/apr-util/include/apr-1
+++
That's bad.
It should point to your apr-utils/include.
NO:
+++
ls -lt /home/jfclere/usr/local/apr-util/include/
total 4
drwxr-xr-x2 jfclere users4096 2005-06-29 10:43 apr-1
+++
Sorry, it was typo.
apxs -q APU_INCLUDEDIR
/home/jfclere/usr/local/apr-util/include/apr-1
your apr-util is at:
/home/jfclere/usr/local/apr-util/include
and that's where the includes should be thought.
OTOH it might be the error in the configure.in:
INCTEMP=`$APXS -q APR_INCLUDEDIR` `$APXS -q APU_INCLUDEDIR`
for INC in ${INCTEMP}; do
APRINCLUDEDIR=${APRINCLUDEDIR} -I${INC}
done
Try to change the:
INCTEMP=`$APXS -q APR_INCLUDEDIR` `$APXS -q APU_INCLUDEDIR`
to:
INCTEMP=`$APXS -q APU_INCLUDEDIR` `$APXS -q APR_INCLUDEDIR`
Seems strange that the
-I/home/jfclere/usr/local/apr-util/include/apr-1 is not listed on the
original dump you've posted.
Regards,
Mladen.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Releasing JK 1.2.14
jean-frederic clere wrote: Seems strange that the -I/home/jfclere/usr/local/apr-util/include/apr-1 is not listed on the original dump you've posted. I have just retried from cvs it is ok. From: http://people.apache.org/~mturk/jakarta-tomcat-connectors-current-src.tar.gz it does not work. (the configure is wrong). Hmm, it might be that ./buildconf.sh I've run is not portable enough. Anyhow, re-running the ./buildconf.sh shoud work even with my shapshot. Perhaps, you can see why the generated configure doesn't work? Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Releasing JK 1.2.14
jean-frederic clere wrote: I have just retried from cvs it is ok. From: http://people.apache.org/~mturk/jakarta-tomcat-connectors-current-src.tar.gz it does not work. (the configure is wrong). I'm using the: automake 1.8.3 aclocal 1.8.3 autoconf 2.59 libtoolize 1.5.2 That's form the SuSE SLES9/AMD64 Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Releasing JK 1.2.14
Mladen Turk wrote: But I've put the current head at: http://people.apache.org/~mturk/jakarta-tomcat-connectors-current-src.tar.gz Seems I've uploaded a wrong file :(. Now it should contain the HEAD (727516 bytes). Sorry for the confusion. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jni/native configure.in
[EMAIL PROTECTED] wrote:
jfclere 2005/06/21 03:31:41
Log:
-Wall is only for gcc.
That's true. But if your 'cc' doesn't support
the -Wall then make CFLASG with some platform
switch rather then interfering with 99% of others that are using gcc.
The -Wall is very valuable when dealing with compile warnings,
and that was the main reason what the --enable-maintainer-mode
was added at the first place. It makes no sense without.
-CFLAGS=${CFLAGS} -DDEBUG -Wall
+CFLAGS=${CFLAGS} -DDEBUG
I would prefer that you add some platform case/esac that will
in ReliantUnix case add what ever you wish to the CFLAGS.
Regards,
Mladen.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native/common jk_uri_worker_map.c jk_uri_worker_map.h
Derrick Koes wrote: I tested yesterday's CVS head for compliance with session ID URL rewriting. This fails. The jsessionid is lost from the URL. Well, I tested that with the /servlets-examples/servlet/SessionExample and the jsessionid's *are* preserved. Can you post the 'JkLogLevel debug' for the requests that are in your opinion dropping the jsessionid? Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jni/native configure.in
William A. Rowe, Jr. wrote:
At 02:01 AM 6/23/2005, Mladen Turk wrote:
-CFLAGS=${CFLAGS} -DDEBUG -Wall
+CFLAGS=${CFLAGS} -DDEBUG
I would prefer that you add some platform case/esac that will
in ReliantUnix case add what ever you wish to the CFLAGS.
Conversely, a compiler case/esac would avoid altogether breaking
AIX, HP/UX, Reliant and a dozen other oddballs. Forcing users to
play cflags is really a symptom of a weak build system.
Something simple like:
if test $GCC = yes; then
CFLAGS=${CFLAGS} -DDEBUG -Wall
elif test $AIX_XLC = yes; then
CFLAGS=${CFLAGS} -DDEBUG -qfullpath -qinitauto=FE -qcheck=all
elif test $MYCOMPILER = yes; then
CFLAGS=${CFLAGS} -DDEBUG my what ever flags
else
CFLAGS=${CFLAGS} -DDEBUG
fi
Would do the trick ;)
Regards,
Mladen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status of ajplib
Alexander Lazic wrote: Hi, i have looked at http://cvs.apache.org/viewcvs.cgi/jakarta-tomcat-connectors/ajp/ajplib/src/ and there wasn't changes since 9-10 months. Right. The entire source has been moved to the Apache HTTPD, and is now part of mod_proxy. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
HEAD build failed
Anyone has any idea why I'm getting the following error when doing: 'ant download' build-tomcat-dbcp: -build-tomcat-dbcp: BUILD FAILED C:\W\projects\tomcat\jakarta-tomcat-5\build.xml:1895: The following error occurred while executing this line: C:\W\projects\tomcat\jakarta-tomcat-5\build.xml:671: The following error occurred while executing this line: C:\W\projects\tomcat\jakarta-tomcat-5\build.xml:683: The following error occurred while executing this line: C:\W\projects\tomcat\jakarta-tomcat-5\build.xml:718: Cannot replace directory C:\W\projects\tomcat\repository\tomcat-deps\src\java\org\apache\tomcat\dbcp with directory C:\W\projects\tomcat\repository\tomcat-deps\src\java\org\apache\commons Any clues. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HEAD build failed
Mladen Turk wrote: Anyone has any idea why I'm getting the following error when doing: 'ant download' build-tomcat-dbcp: -build-tomcat-dbcp: BUILD FAILED Dissreagard that email ;) It's an 'ant 1.6.4' problem. What did they do to mess up the move task? Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status of ajplib
Alexander Lazic wrote: Right. The entire source has been moved to the Apache HTTPD, and is now part of mod_proxy. Oh, is the idea behind a ajblib dead? Not sure :). Perhaps it will finish as a console application for testing AJP protocol (something like ab does for the http). Beside that I see no other purpose for that peace of code. Well, I was thinking to use it as foundation for the windows http.sys. But who knows what the next windows generation will offer. Since the development would take much more then next WIN-xx release, and since it would be a WIN only, there is no need to use the APR, so again probably useless. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat native WIN32 binaries
Hi, If someone wishes to test the bleeding edge Tomcat Native, the WIN32 binaries can be found at: http://people.apache.org/~mturk/native/ I'll try to keep those up to date until we figure out the binary distribution mode. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Domino Tomcat Redirector
Andy Armstrong wrote: I'm the current maintainer of the Domino Tomcat redirector but I haven't had time to do any work on it for the last year or so and I can't see that situation improving any time soon. I've made a couple of attempts to contact someone at IBM who might be interested in providing some (minimal) support without any success. Accordingly I'd like to pass the reigns to someone else so if anyone's interested could they contact me please. Well, IMO even IBM has give his hands out of the Domino. If someone wish to roll a dice, we have 1.2.6 that 'should' support a Domino, at least version 5. I've tried to make (newer, even 1.2.6) it work with version 6 (just as intellectual exercise) but never had any luck. IMHO there is no reason to try to maintain something that has no real-world usage or at least a support from the (well IBM-lke company). I'm trying to maintain a Netscape (SunOne now) port, just because you can find a relatively new release, and just because their API didn't change a lot. Although I think that maintaining that is useless too. Thanks - it's been fun :) You can always find some other web server :) Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Domino Tomcat Redirector
Andy Armstrong wrote: I haven't used Domino for nearly two years and I have to say, without wishing to be unkind to the people who developed it, that my head is a lot better these days :) Well, frankly I don't mind to have a support for XYZ server, if at least that server is maintained by the publisher itself. For example, I'll (personally) drop a support even for SunOne (Netscape), simply because my 6 month free license just went out. The fact that I only use Apache myself has made it difficult to stay interested in Domino... Right. Feel free to contribute to the Apache1/2 part of the mod_jk. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native/common jk_lb_worker.c jk_shm.h jk_status.c
jean-frederic clere wrote: William A. Rowe, Jr. wrote: Mladen; are you sure you weren't looking for 'long long', al la int64_t? Falling over to the FPU is rarely the best performance decision. A little more coding is needed, because I have a related error (on ReliantUnix): undefined typedef uint32_t JK_UINT4; ^ Seems that the uint32_t is not inside includes referenced by jk_global.h. Not sure what is the possible location for that type on all platforms. Perhaps u_int32_t would be more portable. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native/common jk_lb_worker.c jk_shm.h jk_status.c
jean-frederic clere wrote: Mladen Turk wrote: Perhaps u_int32_t would be more portable. I would prefer to add in configure something like: +++ AC_CHECK_SIZEOF(char, 1) AC_CHECK_SIZEOF(int, 4) AC_CHECK_SIZEOF(long, 4) AC_CHECK_SIZEOF(short, 2) AC_CHECK_SIZEOF(long long, 8) +++ and testing $ac_cv_sizeof_WHATWETESTED makes sure we right one. Yes, but all that we need is 32 bit unsigned integer for JK_UINT4 What will you use if the int is 64 bits? Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native/common jk_lb_worker.c jk_shm.h jk_status.c
jean-frederic clere wrote: Mladen Turk wrote: Yes, but all that we need is 32 bit unsigned integer for JK_UINT4 What will you use if the int is 64 bits? a long ;-) Right :) You will need the portable.in in that case, right? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Regression -- jakarta-tomcat-connectors/jk/native/common jk_uri_worker_map.c
Derrick Koes wrote: URL rewriting is once again broken. 1.2.14 exhibits the problem for certain. Older version may as well. This was fixed in 1.2.8, but has regressed. Has anyone else noticed the regression? Could you explain what do you mean by 'regression', and URL rewriting? If you give some example of what are you doing, what the JK does, and what in your opinion it should do, that would be helpful. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jni/native/src ssl.c sslcontext.c
jean-frederic clere wrote: [EMAIL PROTECTED] wrote: Log: Change the BIOCallback interface to use write(byte[] buf) and read(byte[] buf); Add SSL_accept to do the client handshake. Arrange the corresponding example. +++ CUT +++ Hi, I am not 100% happy with the code. Mladen already asked me to rollback the changes. I think the worst thing is setSock() I have added to BIOCallback. Yes please rollback. My idea is/was to use BIOCallback or a similar interface to be able to openssl either with normal JAVA sockets or APR native ones. I plan to create the SSLSocket that will use created Socket (here I speak about Native sockets only) then obtain apr_os_sock_t and then do a SSL accept on that accepted socket. SSLSocket.create will create tcn_ssl_t from SSLContext and will contain both apr_sock_t* and SSL*. We need APR socket to be able to do the polling on the SSL sockets as well. Please give me a day or two to finish the skeleton implementation, that will do a basic s_server/s_client. BIOCallback will be used only for: 1. Password callbacks 2. Error logging 3. Custom byte streams for certificate data contained in non file system storage. For example right now we have: SSLContext.setCertificate(..., file, ...) I plan to add the: SSLContext.setCertificate(..., BIOCallback, ...) read/write callback methods could be used for reading certificate data from database blobs, or directly from keystorage. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jni/native/src ssl.c sslcontext.c
Bill Barker wrote: I am not 100% happy with the code. Mladen already asked me to rollback the changes. It looked OK to me. Basically it's the APR implementation of SSLEngine. Don't really see a problem. It does not, because it should fit inside the APR standard socket implementation. Having callbacks would actually make a thing way slower, because we would have to call the native, and from the native call the Java that would call back the native again. Of course, I don't really care about the APR-SSL Connector one way or the other. Since the config is the same as for mod_ssl, there is absolutely no reason to not simply use mod_ssl instead. If I just wanted the native-code optimizations, I'd use PureTLS instead. It's not an APR-SSL connector, but rather the SSL support for the APR connector. Since all that is optional feel free to just not use it :) Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jni/native/src ssl.c sslcontext.c
jean-frederic clere wrote: It does not, because it should fit inside the APR standard socket implementation. Having callbacks would actually make a thing way slower, because we would have to call the native, and from the native call the Java that would call back the native again. Well we just need a nativeBIO and a javaBIO. The plan is to use the: 1. apr_sock_accept/connect 2. obtain a os_sock 3. Make a BIO with os_sock_t 4. Use APR for socket_opt_set/socket_opt_get 5. Do a SSL_accept/SSL_connect 6. Make verify/handshake 7. use SSL_write/SSL_read for I/O. All that will use the poller and the pool cleanup. The Java part will go to the SSLSocket with the Socket API with specific read* and write* Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jni/native/src ssl.c sslcontext.c
jean-frederic clere wrote: OK, I will create a SSLBIO.java/sslbio.c to go on testing/experimenting using with the BIOCallback, the interest there is to use an hardware accelator with openssl. Please, can you give me a day to finish initial implementation. Hardware accelerator is used by default on SSL.initialize(egineName) Once again, can you hold up with adding new files? Thanks, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] jakarta-tomcat-connectors Chunked transfer encoding for IIS
Tim Whittington wrote: This patch adds chunked encoding for IIS responses - i.e. Transfer-Encoding: chunked responses for HTTP/1.1 clients - allowing IIS to maintain persistent connections to HTTP/1.1 clients through the ISAPI redirector. Could you create a bugzilla entry for that as an enhancement. I doubt this will be committed to the 1.2 branch, because we wish to keep it frozen for any new features. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jni/native/src error.c
[EMAIL PROTECTED] wrote: jfclere 2005/06/07 03:08:08 Modified:jni/native/src error.c Log: typo? It cores in my machine... -free(msg); Yes, nasty typo. I was freeing a static string. Just great :) Thanks for tracking that down, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session Affinity after Graceful Apache restart? [was Re: Adding working dynamically with mod_jk status?]
[EMAIL PROTECTED] wrote: Hi, I've been asking some more questions about restarts on the Apache list, and was redirected back here... Does anyone know (David, Mladen?) what will happen to session affinity is this situation? ie with Apache in front of several tomcats using mod_jk, when Apache is restarted gracefully using apache -k restart (Windows) will session affinity be preserved across the restart? ie will browsers with a session open with a particular Tomcat continue being directed to that particular Tomcat after the restart? First of all graceful restart will not work on Windows for any busy server. I suggest that you move to some unix/linux version. And yes, the session affinity will be preserved because it is related to the worker name and jvmRoute. Also, like somebody already told you: The easiest is to try by yourself, and then come up with the real problem. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session Affinity after Graceful Apache restart? [was Re: Adding working dynamically with mod_jk status?]
[EMAIL PROTECTED] wrote: First of all graceful restart will not work on Windows for any busy server. I suggest that you move to some unix/linux version. Errr...could you explain why? I was told on the Apache list that it does work on Windows...what am I missing? It works of course, but IIRC you are planning to use it for reconfiguring mod_jk. I think you might get into the problems with shared memory (particularly on unix) because some child might have a different idea about shared memory addresses. If you do not delete any worker and add new one at the end of the worker.list it might work. Anyhow it's not something I would use in the production and rely on its proper behavior. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session Affinity after Graceful Apache restart? [was Re: Adding working dynamically with mod_jk status?]
William A. Rowe, Jr. wrote: At 02:08 PM 6/7/2005, Mladen Turk wrote: It works of course, but IIRC you are planning to use it for reconfiguring mod_jk. I think you might get into the problems with shared memory (particularly on unix) because some child might have a different idea about shared memory addresses. Oh - so this is a bug/design flaw in mod_jk? Does the same affect the prefork/worker MPMs? Actually the WIN32 has no such problems because it uses the plain memory instead of shared. Problem with WIN32 is because the closing child and new child will not share the worker data during restart, so you will loose the statistics during restart. With unixes the problem is because the workers are allocated according to the worker.list and balance_members. If you change those lists in the config on restart the child processes could have different shared memory segment addresses. Like said if you only add to the end of list then everything will probably be OK. To resolve that we would actually need a database like shared memory with worker name as a key. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: source code for tomcat as a service...
Mark wrote: OK, I got the source code. From what I can tell, this will install my program in the same manner as Tomcat. I will get the little icon in the system tray and all that, which is awesome. Do you know which parts of this I should be loading into MSVC++ in order to build the executable? Project files are for VisualStudio .NET Open the src/native/nt/procrun/procrun.sln prunmgr is tomcat5w.exe prunsrv is tomcat5.exe Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector Connector.java Response.java
[EMAIL PROTECTED] wrote: billbarker2005/05/20 20:02:25 Modified:catalina/src/share/org/apache/catalina/connector Connector.java Response.java Log: Reverting previous patch in favor of the better one submitted by JFC No idea why but suddenly I'm getting the following when stopping the Tomcat with simple CTRL+C and AJP connector enabled. INFO: Pausing Coyote HTTP/1.1 on http-8080 May 25, 2005 4:46:53 PM org.apache.tomcat.util.threads.ThreadPool$ControlRunnable run SEVERE: Caught exception (java.lang.NoSuchMethodError: org.apache.jk.core.MsgContext.getRequest()Ljava/lang/Object;) executing [EMAIL PROTECTED], terminating thread May 25, 2005 4:46:54 PM org.apache.catalina.core.StandardService stop INFO: Stopping service Catalina Any ideas why? Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector Connector.java Response.java
jean-frederic clere wrote: Mladen Turk wrote: INFO: Pausing Coyote HTTP/1.1 on http-8080 May 25, 2005 4:46:53 PM org.apache.tomcat.util.threads.ThreadPool$ControlRunnable run SEVERE: Caught exception (java.lang.NoSuchMethodError: org.apache.jk.core.MsgContext.getRequest()Ljava/lang/Object;) executing [EMAIL PROTECTED], terminating thread May 25, 2005 4:46:54 PM org.apache.catalina.core.StandardService stop INFO: Stopping service Catalina Any ideas why? Why do you think the changes in Connector and Response cause the problem? If I would have an idea I wouldn't ask 'Any ideas why?' :). Anyhow seems the problem with MsgContext.java when Bill changed the : -public final Object getRequest() +public final Request getRequest() Think that down the classtree getRequest() is still considered to return the Ljava/lang/Object. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Hybrid (NIO+Multithread, SSL enabled) architecture for Coyote
Remy Maucherat wrote: In my mind, the argument for tomcat supporting 1000 concurrent connections for an extended period of time isn't valid from my experience. - all the other APR features which are really useful and not provided by the core Java platform Actually I just read a perfect use case scenario request for the new APR connector on [EMAIL PROTECTED] With only couple of threads all the 1000 connections could be handled without having 1000 threads. Users are connecting to the solution by invoking a servlet (runned by tomcat). If a user is auhentified, then I use HTTPServletResponse object (in the service method) to get the Outputstream of that object = HTTPServletResponse.getoutputstream) Then this stream will be use to handle communications between my client application and my custom Server Process (I need to send real time informations through this canal). Important = A client session can last several hours, so the life of the servlet is set to time infinite . In fact I had the idea delegate socket connection managment, to tomcat engine, by setting servlet life time to infinite. Is it a good way to do, or should I use a socket pooling algorithm (actualy, the server can freeze, after unregular amout of times, time for writing operation in the Output stream can increase until being totaly unusuable, I have to close, and reconnect) The objective is to handle more than 1000 client sessions. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector Connector.java Response.java
Bill Barker wrote: Doing a clean build of j-t-c/jk/java should fix it. MsgContext isn't referenced outside of there. I'm doing 'ant checkout ant'. This is actually changed as part of Mark's Form-auth POST-replay, not the Connector/Response buffering. OK. Will try the clean build. Thanks, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adding working dynamically with mod_jk status?
[EMAIL PROTECTED] wrote: Is this still true if we were to define extra workers that are marked as disabled at startup? Could we then point them to any new servers as they are added and enable them without a restart? I know it's not very clean, but would it work? It will work if you know the hostname and the port that new server will have in advance. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk 1.2.11 / 1.2.13 not working on iSeries
Henri Gomez wrote: A quick note to tell that both jk 1.2.11 and 1.2.13 didn't works on iSeries. Very informative email. Thanks for sharing that ;) Can't check why now but iSeries users should stay with 1.2.10 :) Any particular messages or clues? Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk 1.2.11 / 1.2.13 not working on iSeries
Henri Gomez wrote: Nope, but I suspect a bad build options somewhere. Probably some libraries missing in detecting network capabilities within configure.in. I rebuild 1.2.13 with the up to date options and wait my net engineers to make a try. Aha... Now we even have a staff of engineers. Cool :) stray tuned No problemo, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk 1.2.11 / 1.2.13 not working on iSeries
Henri Gomez wrote: Well I couldn't use configure on iSeries. What's libs are you talking for ? See the JK_CHECK_SETSOCKOPT function in configure.in Perhaps the -lsocket (socket lib) is missing on iSeries? If it is, we'll need some arch switch. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adding working dynamically with mod_jk status?
[EMAIL PROTECTED] wrote: Any ideas or recommendations on this? Adding workers would be tricky because if member of load balancer it has to be known at startup time so that shared memory slot can be allocated. The only solution would be to edit the workers.properties file and then forcing the Apache to restart. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adding working dynamically with mod_jk status?
[EMAIL PROTECTED] wrote: Hi, Is there any way in the current implementatio to **add** a new worker (for a new Tomcat instance) dynamically? Using mod_jk status? Another way? No. Can you elaborate why would you need such a feature? Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Hybrid (NIO+Multithread, SSL enabled) architecture for Coyote
Vicenç Beltran wrote: Hi, attached you'll find a patch that changes the coyote multithreading model to a hybrid threading model (NIO+Mulithread). It's fully compatible with the existing Catalina code and is SSL enabled. diff -uprN jakarta-tomcat-5.5.9-src/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java Can't you simply make two new files Http11NioProcessor and Http11NioProtocol. Trying to change default implementation that Tomcat uses will never be committed (at least I'll vote -1 on that). Simply create two files that can be used instead current implementation, in a fashion we did for Http11AprProtocol. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Hybrid (NIO+Multithread, SSL enabled) architecture for Coyote
Vicenc Beltran Querol wrote: Hi guys, I'm not trying to be a Tomcat developer. I'm working on my PhD on web performance and just decided to share with you the experimental code I've developed after studying the performance obtained ;). I've done some serious testings with HTTP server and NIO. The results were always bad for NIO. Blocking I/O is minimum 25% faster then NIO. You may tray that simply by using demo HTTP servers Blocking/Blocking Pool/NIO single thread/NIO multiple threads that comes with new Java6 (see java.net for sources). OTOH, I'm sure you must have some performance results :) Simply run the 'ab -n 10 -c 100 -k host:8080/tomcat.gif' with your patch and standard Tomcat5.5.9. Anyway, it's OK. I'll work on the new patch and resubmit it. Great. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Hybrid (NIO+Multithread, SSL enabled) architecture for Coyote
Jeanfrancois Arcand wrote: I've done some serious testings with HTTP server and NIO. The results were always bad for NIO. Blocking I/O is minimum 25% faster then NIO. Faster in what? Throughput and/or scalability? I disagree ;-) I would like to see your implementation, because from what I'm seeing/measuring, it is completely the inverse. I would be interested to see how you did implement your NIO connector. I do not understand why the people are so obsessed with NIO, really. Like said there IS a example from Sun that tries all the strategies you can imagine, even using mapped byte buffers, single/multiple threads etc... Feel free to test by yourself if you don't believe me. Download the Mustang sources from http://www.java.net/download/jdk6/ You have a complete stack of 5 web servers inside: j2se/src/share/sample/nio/server Also read a nice aricle: http://www.usenix.org/events/hotos03/tech/full_papers/vonbehren/vonbehren_html/index.html Solaris and Linux 2.6 threading support is much more advanced then it was in a days the even architecture was 'pushed'. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JK shutdown problem
Jean-Jacques Clar wrote:
Hi,
file: jk_connect.c
in jk_shutdown_socket(); when reading data from tomcat in the while loop,
the variable ttl is incremented every time by one, until breaking out of the loop:
snippet:
line 505 *-
/* Read all data from the peer until we reach end-of-file (FIN
* from peer) or we've exceeded our overall timeout. If the client does
* not send us bytes within12 second, close the connection.
*/
while (1) {
nbytes = jk_tcp_socket_recvfull(s, dummy, sizeof(dummy));
if (nbytes = 0)
break;
ttl += SECONDS_TO_LINGER;
if (ttl MAX_SECS_TO_LINGER)
break;
}
The problem is because I do not have a Netware box.
You guys can try to enable the following:
#if defined(WIN32)
setsockopt(s, SOL_SOCKET, SO_RCVTIMEO,
(const char *) tmout, sizeof(int));
#endif
for Netware too...
I didn't try to enable that because so many times the
JK has been broken because of Netware build bugs ;)
Also the code in nb_connect:
#if defined(WIN32)
int tmout = timeout * 1000;
setsockopt(sock, SOL_SOCKET, SO_RCVTIMEO,
(const char *) tmout, sizeof(int));
setsockopt(sock, SOL_SOCKET, SO_SNDTIMEO,
(const char *) tmout, sizeof(int));
#else ...
Shuld be checked for: (probably but who knows ;)
for :
#if defined(WIN32) || (defined(NETWARE) defined(__NOVELL_LIBC__))
Regards,
Mladen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
AJP/Java connector issues
Hi, Just noticed a strange behavior in the Java part of the JK dealing with large (over 8184 bytes) data transfers. Since with 8192 bytes AJP packet size, the maximum transferred size per each packet is 8184 bytes one would expect that for 2 bytes file the packets would be in a form of: 1:8184,2:8184,3:3632 thus total of 2 bytes. But in fact the behavior is rely weird: 1:8184,2:8,3:8184,4:8,5:3616. Instead only three, the five! packets are transferred. Seems that algorithm is breaking 8192 bytes of data to two packets (8184 and 8 bytes). Bill, Any idea how to solve this, because it's way too inefficient. What's makes the things even worse is that for each packet Apache2 creates a transient bucket thus rising the memory usage. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJP/Java connector issues
Bill Barker wrote: I see what this is now: The default Connector OutputBuffer size is 8K, so it's sending the output to JkInputStream in 8K chunks. JkInputStream sends all of the 8K to Apache in two chunks. As a Coyote OutputBuffer, it's not really JkInputStream's job to do additional buffering. It's probably better to do response.setBufferSize(2); so that the Connector will send the whole thing to JkInputStream as one chunk. Sure that seems to be the problem, but it's hard to convince the users to write the applications having AJP packet size in mind ;) The best would be that instead default 8192 bytes, when AJP connector is loaded that response size is either set to 8184 or 16386 bytes (one or two packets) by default. Is something like that possible? Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJP/Java connector issues
Bill Barker wrote: Is something like that possible? It would be really easy to default to 8184 for all Connectors (just change the value in o.a.c.connector.OutputBuffer). I'm not so sure how happy that would make Remy. Not much I'm afraid ;) It wouldn't be too hard to have Connector.createResponse check the protocol, and if it's AJP/1.3 then set the buffer size to 16386 (currently it's not possible to decrease the buffer size). That would be great. It wouldn't be that hard to add buffering to JkInputStream so that it always tries to write out a 8184 packet. This would also prevent fracturing in the event that the webapp programmer decides to call response.setBufferSize herself. The downside would be an extra arraycopy when writing (and, of course, an extra 8184*numThreads bytes of memory used :). Not very optimal IMO. If somebody sets the buffer size by hand, then, well, he probably knows better :) Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JK 1.2.13 TAGGED
Günter Knauf wrote: Hi Mladen, JK 1.2.13 has been taggeded as we agreed last week, and the tarballs are available at: http://www.apache.org/dist/jakarta/tomcat-connectors/jk/source/jk-1.2.13/ any particular reason why you didnt tag my last commit on jk_connect.c? http://cvs.apache.org/viewcvs.cgi/jakarta-tomcat-connectors/jk/native/common/jk_connect.c?rev=1.59view=log now we can again not build for AP13 on NetWare without patching. I thought you said last time that you are fine with the patch? Yes I am. Have no idea why this file wasn't tagged. Can we retag that file only and rerelease? Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JK 1.2.13 TAGGED
Henri Gomez wrote: Yes ;-) Yes what? Broke a rule or recreate the tarballs, or both :)? And put a note about this change also in the download location In a form of? Any example? Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JK 1.2.13 TAGGED - ws_write call to ap_rflush in mod_jk.c
jean-frederic clere wrote: Mladen Turk wrote: JkFlush (On|Off|size) with On as default for each packet write. That way we'd be able to flush after each write, flush after each 'size' bytes or not flush at all. Won't it be better to have a ws_flush()? Not sure what you mean by that. Like a generic callback? Not sure if it would make sense. IIS for example does auto flushing, so It's only needed for Apache2. Having 'JkFlush size' like 'JkFlush 65536' will insert an EOS bucket after 64K. Having large chunks might make problems to outgoing filters like deflate, that depends on EOS bucket for compressing window size. Right now the chunk size is AJP packet size (8K) that might cause memory problems like JJC said. Adding that as configurable server wide option will not break exiting behavior, while it might speed up large data transfer, and keep the memory low. If 'JkFlush Off' is used a single ap_rflush will be issued when all the data is send. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JK 1.2.13 TAGGED
Henri Gomez wrote: Or provide a jk 1.2.13a including this fix for novell ? I would like to skip that, but I like the Jean-Frederic's idea about putting the tarballs inside binaries/netware/ Anyhow, the plan was retag that as 1.2.14 if everything else is OK, or make 1.2.14-rc-(xxx), after some test period, like couple of weeks. If you guys are OK with JJC concerns and my proposal on ap_rflush/JkFlush we can add that to 1.2.14-rc-1, or leave that for 1.3 branch. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JK 1.2.13 TAGGED - ws_write call to ap_rflush in mod_jk.c
jean-frederic clere wrote: Mladen Turk wrote: I think on/off is enough - Think of the questions nnn will bring in user list - So how about to just add the flag to JkOptions like +FlushPackets? Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
