svn commit: r422996 - in /tomcat/connectors/trunk/jk/native/common: jk_ajp12_worker.c jk_ajp_common.c jk_ajp_common.h jk_connect.c jk_connect.h jk_global.h jk_sockbuf.h

Author: mturk Date: Tue Jul 18 00:19:27 2006 New Revision: 422996 URL: http://svn.apache.org/viewvc?rev=422996&view=rev Log: Add jk_sock_t that is SOCKET on WIN32 and int on POSIX. This enables to deal with newest Microsoft PSDKs where SOCKET is defined as unsigned int pointer. Also added macros f

svn commit: r422997 - /tomcat/connectors/trunk/jk/native/common/jk_version.h

Author: mturk Date: Tue Jul 18 00:19:55 2006 New Revision: 422997 URL: http://svn.apache.org/viewvc?rev=422997&view=rev Log: Increment the working version to 1.2.18 Modified: tomcat/connectors/trunk/jk/native/common/jk_version.h Modified: tomcat/connectors/trunk/jk/native/common/jk_version.h

Re: Next try: mod_jk 1.2.17 release candidate ready to test

Rainer Jung wrote: Mladen Turk wrote: Anyhow, I suppose it should be neither int nor unsigned int, but rather size_t, at least that's the retval from sizeof, right? Of course its used by getsockopt that OTOH requires socklen_t. Since it's only use is putting it into getsockopt(), I would su

svn commit: r423000 - /tomcat/connectors/trunk/jk/native/common/jk_connect.c

Author: mturk Date: Tue Jul 18 00:31:31 2006 New Revision: 423000 URL: http://svn.apache.org/viewvc?rev=423000&view=rev Log: Use socklen_t for getsockopt param instead int. Modified: tomcat/connectors/trunk/jk/native/common/jk_connect.c Modified: tomcat/connectors/trunk/jk/native/common/jk_c

Re: Next try: mod_jk 1.2.17 release candidate ready to test

Well on iSeries the C compiler is very strict about these kind of typecast so the socklen_t should be used (and the build works with it). If you're using JK_SOCKLEN_T via configure, since the iSeries didn't use it, please define it with #ifdef AS400 to 'link' it to socklen_t. 2006/7/18, Jean-fr

Re: Next try: mod_jk 1.2.17 release candidate ready to test

Henri Gomez wrote: Well on iSeries the C compiler is very strict about these kind of typecast so the socklen_t should be used (and the build works with it). Can you check the current head? I committed the fix. -- Mladen. - T

svn commit: r423038 - /tomcat/connectors/trunk/jk/native/common/jk_lb_worker.c

Author: mturk Date: Tue Jul 18 03:22:25 2006 New Revision: 423038 URL: http://svn.apache.org/viewvc?rev=423038&view=rev Log: Fix -Wall warning about missing braces. Modified: tomcat/connectors/trunk/jk/native/common/jk_lb_worker.c Modified: tomcat/connectors/trunk/jk/native/common/jk_lb_work

Re: Next try: mod_jk 1.2.17 release candidate ready to test

Ok, build against the latest from SVN (thanks Mladen), and build without any problem on iSeries. A strong 1.2.18 candidate 2006/7/18, Mladen Turk <[EMAIL PROTECTED]>: Henri Gomez wrote: > Well on iSeries the C compiler is very strict about these kind of > typecast so the socklen_t should be use

Re: Next try: mod_jk 1.2.17 release candidate ready to test

Then let Peter try it on Mac OS X, if he only gets a warning or a real error. Henri Gomez wrote: Ok, build against the latest from SVN (thanks Mladen), and build without any problem on iSeries. A strong 1.2.18 candidate 2006/7/18, Mladen Turk <[EMAIL PROTECTED]>: Henri Gomez wrote: > Well o

Re: Next try: mod_jk 1.2.17 release candidate ready to test

Rainer Jung wrote: Then let Peter try it on Mac OS X, if he only gets a warning or a real error. Sure, but since http://www.hmug.org/man/2/getsockopt.php says that the OS/X uses socklen_t as well, we should be fine. -- Mladen.

Re: mod_jk 1.2.17 vs. mod_proxy_ajp

On Jul 14, 2006, at 10:34 AM, Jess Holle wrote: What is the plan for mod_proxy_ajp catching up with all the improvements in the latest mod_jk? As I understand it, mod_proxy_ajp is currently lagging, which is understandable -- one or the other has to. I'm just wanting to get some grasp o

Re: Next try: mod_jk 1.2.17 release candidate ready to test

On Jul 18, 2006, at 8:46 AM, Mladen Turk wrote: Rainer Jung wrote: Then let Peter try it on Mac OS X, if he only gets a warning or a real error. Sure, but since http://www.hmug.org/man/2/getsockopt.php says that the OS/X uses socklen_t as well, we should be fine. I get no build error..

Re: mod_jk 1.2.17 vs. mod_proxy_ajp

2006/7/18, Jim Jagielski <[EMAIL PROTECTED]>: On Jul 14, 2006, at 10:34 AM, Jess Holle wrote: > What is the plan for mod_proxy_ajp catching up with all the > improvements in the latest mod_jk? > > As I understand it, mod_proxy_ajp is currently lagging, which is > understandable -- one or the ot

Re: Next try: mod_jk 1.2.17 release candidate ready to test

Good, so we're ready for a 1.2.18 release ? 2006/7/18, Jim Jagielski <[EMAIL PROTECTED]>: On Jul 18, 2006, at 8:46 AM, Mladen Turk wrote: > Rainer Jung wrote: >> Then let Peter try it on Mac OS X, if he only gets a warning or a >> real error. >> > > Sure, but since > http://www.hmug.org/man/2/

svn commit: r423110 - /tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Http11Protocol.java

Author: mturk Date: Tue Jul 18 08:16:38 2006 New Revision: 423110 URL: http://svn.apache.org/viewvc?rev=423110&view=rev Log: Add svn:eol-style:native Modified: tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Http11Protocol.java (contents, props changed) Modified: tomcat/tc6.0.x/trunk/j

Re: Next try: mod_jk 1.2.17 release candidate ready to test

Henri Gomez wrote: Good, so we're ready for a 1.2.18 release ? Sure if the Rainer still has the energy for another run :) Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL P

mod_jk premature documentation

Since there is no .16 or .17 release yet, but the documentation on the tomcat website says that several options have been deprecated since .16. Instead of removing documentation, could we just add "Deprecated" but leave the explanation out there, folks don't instantly switch as soon as there i

Re: Next try: mod_jk 1.2.17 release candidate ready to test

I haven't done exhaustive testing yet, but it's looking good :) On Jul 18, 2006, at 10:44 AM, Henri Gomez wrote: Good, so we're ready for a 1.2.18 release ? 2006/7/18, Jim Jagielski <[EMAIL PROTECTED]>: On Jul 18, 2006, at 8:46 AM, Mladen Turk wrote: > Rainer Jung wrote: >> Then let Peter t

Re: Next try: mod_jk 1.2.17 release candidate ready to test

Batteries loaded, on for another run. I'll prepare 1.2.18 until tomorrow. Thanks for testing and I hope we don't overwhelm our users. At least it looks like we will end up with a good release. I knew, why I talked about release candidates... Mladen Turk wrote: > Henri Gomez wrote: > >> Good,

mod_jk 1.2.17+ Recover time

I've been testing the 1.2.17 (soon to be 1.2.18) release and have noticed a problem in worker recovery. If I restart a Tomcat instance and mod_jk notices that it went down, mod_jk waits 60 seconds recovery time before it tries again (see jk_lb_worker.h WAIT_BEFORE_RECOVER and struct jk_shm_worker

Re: mod_jk premature documentation

I'll care about that, since it looks like I'll do 1.2.18 now. But I will only update documentation on tomcat.apache.org/dev. I'm really thinking about rolling back the premature publication of newer doc on tomcat.apache.org. I think, doc there should not be more recent, than the last release. O

svn commit: r423156 - /tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/GroupChannel.java

Author: fhanik Date: Tue Jul 18 11:02:36 2006 New Revision: 423156 URL: http://svn.apache.org/viewvc?rev=423156&view=rev Log: No change, just added brackets Modified: tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/GroupChannel.java Modified: tomcat/con

svn commit: r423158 - /tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tipis/AbstractReplicatedMap.java

Author: fhanik Date: Tue Jul 18 11:06:57 2006 New Revision: 423158 URL: http://svn.apache.org/viewvc?rev=423158&view=rev Log: Added in hashCode and equals to the map, otherwise the maps will not get added as channel listeners if they aren't unique. This is needed for multiple context and differen

DO NOT REPLY [Bug 36549] - Tomcat Stopped with HotSpot libjvm error

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

svn commit: r423169 - /tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/GroupChannel.java

Author: fhanik Date: Tue Jul 18 11:25:18 2006 New Revision: 423169 URL: http://svn.apache.org/viewvc?rev=423169&view=rev Log: Throw an error if the listeners doesn't get added successfully instead of silently fail. Modified: tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/cat

Re: mod_jk premature documentation

Rainer Jung wrote: I'll care about that, since it looks like I'll do 1.2.18 now. But I will only update documentation on tomcat.apache.org/dev. I'm really thinking about rolling back the premature publication of newer doc on tomcat.apache.org. I think, doc there should not be more recent, than

Re: mod_jk 1.2.17 vs. mod_proxy_ajp

It would probably make sense to broadcast a list of improvements, etc, when 1.2.18 is released at least... Henri Gomez wrote: 2006/7/18, Jim Jagielski <[EMAIL PROTECTED]>: On Jul 14, 2006, at 10:34 AM, Jess Holle wrote: > What is the plan for mod_proxy_ajp catching up with all the > improvem

Re: mod_jk 1.2.17+ Recover time

Is the 60 seconds hard-coded? I'd hope not... Once you have some interesting web apps in Tomcat it often takes a bit longer than 10 seconds -- and on my laptop just took a full 60 seconds, but that is rather unusual (a restart thereafter only took 18). David Rees wrote: I've been testing th

DO NOT REPLY [Bug 36549] - Tomcat Stopped with HotSpot libjvm error

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

svn commit: r423243 - /tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tipis/AbstractReplicatedMap.java

Author: fhanik Date: Tue Jul 18 14:03:21 2006 New Revision: 423243 URL: http://svn.apache.org/viewvc?rev=423243&view=rev Log: Single op reduces the risk of ConcurrentModification exception, although they still occur. the correct solution is to implement an atomic size counter Modified: tomc

svn commit: r423244 - in /tomcat/container/tc5.5.x/modules/groupcom: src/share/org/apache/catalina/tribes/group/interceptors/ test/java/org/apache/catalina/tribes/test/channel/

Author: fhanik Date: Tue Jul 18 14:04:00 2006 New Revision: 423244 URL: http://svn.apache.org/viewvc?rev=423244&view=rev Log: Message dispatch interceptor uses a thread pool Modified: tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/interceptors/MessageDis

Re: *SPAM* Re: Next try: mod_jk 1.2.17 release candidate ready to test

+1 Great! Works for me without error or warnings. apache 2.0.55 and 2.0.58 works at my Powerbook G4 MAC OS X 10.4.6 with darwin ports. I can test it also at my intel mac and G5 tomorrow. Many thanks, Peter Am 18.07.2006 um 14:42 schrieb Rainer Jung: Then let Peter try it on Mac OS X, if

Re: mod_jk 1.2.17+ Recover time

On 7/18/06, Jess Holle <[EMAIL PROTECTED]> wrote: Is the 60 seconds hard-coded? I'd hope not... Once you have some interesting web apps in Tomcat it often takes a bit longer than 10 seconds -- and on my laptop just took a full 60 seconds, but that is rather unusual (a restart thereafter only to