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

[mturk]

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 for testing the socket instead simply
comparing the value with integer.

Modified:
tomcat/connectors/trunk/jk/native/common/jk_ajp12_worker.c
tomcat/connectors/trunk/jk/native/common/jk_ajp_common.c
tomcat/connectors/trunk/jk/native/common/jk_ajp_common.h
tomcat/connectors/trunk/jk/native/common/jk_connect.c
tomcat/connectors/trunk/jk/native/common/jk_connect.h
tomcat/connectors/trunk/jk/native/common/jk_global.h
tomcat/connectors/trunk/jk/native/common/jk_sockbuf.h

Modified: tomcat/connectors/trunk/jk/native/common/jk_ajp12_worker.c
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/common/jk_ajp12_worker.c?rev=422996&r1=422995&r2=422996&view=diff
==
--- tomcat/connectors/trunk/jk/native/common/jk_ajp12_worker.c (original)
+++ tomcat/connectors/trunk/jk/native/common/jk_ajp12_worker.c Tue Jul 18 
00:19:27 2006
@@ -51,7 +51,7 @@
 {
 ajp12_worker_t *worker;
 
-int sd;
+jk_sock_t sd;
 jk_sockbuf_t sb;
 
 jk_endpoint_t endpoint;
@@ -105,11 +105,11 @@
 
 jk_log(l, JK_LOG_DEBUG, "In jk_endpoint_t::service, sd = %d",
p->sd);
-if (p->sd >= 0) {
+if (IS_VALID_SOCKET(p->sd)) {
 break;
 }
 }
-if (p->sd >= 0) {
+if (IS_VALID_SOCKET(p->sd)) {
 
 jk_sb_open(&p->sb, p->sd);
 if (ajpv12_handle_request(p, s, l)) {
@@ -134,7 +134,7 @@
 jk_log(l, JK_LOG_DEBUG, "Into jk_endpoint_t::done");
 if (e && *e && (*e)->endpoint_private) {
 ajp12_endpoint_t *p = (*e)->endpoint_private;
-if (p->sd > 0) {
+if (IS_VALID_SOCKET(p->sd)) {
 jk_close_socket(p->sd);
 }
 free(p);
@@ -201,7 +201,7 @@
 ajp12_endpoint_t *p =
 (ajp12_endpoint_t *) malloc(sizeof(ajp12_endpoint_t));
 if (p) {
-p->sd = -1;
+p->sd = JK_INVALID_SOCKET;
 p->worker = pThis->worker_private;
 p->endpoint.endpoint_private = p;
 p->endpoint.service = service;

Modified: tomcat/connectors/trunk/jk/native/common/jk_ajp_common.c
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/common/jk_ajp_common.c?rev=422996&r1=422995&r2=422996&view=diff
==
--- tomcat/connectors/trunk/jk/native/common/jk_ajp_common.c (original)
+++ tomcat/connectors/trunk/jk/native/common/jk_ajp_common.c Tue Jul 18 
00:19:27 2006
@@ -716,12 +716,12 @@
 {
 JK_TRACE_ENTER(l);
 
-if (ae->sd > 0) {
+if (IS_VALID_SOCKET(ae->sd)) {
 jk_shutdown_socket(ae->sd);
 if (JK_IS_DEBUG_LEVEL(l))
 jk_log(l, JK_LOG_DEBUG,
"closed socket with sd = %d", ae->sd);
-ae->sd = -1;
+ae->sd = JK_INVALID_SOCKET;
 }
 
 jk_close_pool(&(ae->pool));
@@ -741,22 +741,22 @@
 int sock = ae->sd;
 
 /* Mark existing endpoint socket as closed */
-ae->sd = -1;
+ae->sd = JK_INVALID_SOCKET;
 JK_ENTER_CS(&aw->cs, rc);
 if (rc) {
 unsigned int i;
 for (i = 0; i < aw->ep_cache_sz; i++) {
 /* Find cache slot with usable socket */
-if (aw->ep_cache[i] && aw->ep_cache[i]->sd != -1) {
+if (aw->ep_cache[i] && IS_VALID_SOCKET(aw->ep_cache[i]->sd)) {
 ae->sd = aw->ep_cache[i]->sd;
-aw->ep_cache[i]->sd = -1;
+aw->ep_cache[i]->sd = JK_INVALID_SOCKET;
 break;
 }
 }
 JK_LEAVE_CS(&aw->cs, rc);
 }
 /* Close previous socket */
-if (sock > 0)
+if (IS_VALID_SOCKET(sock))
 jk_close_socket(sock);
 }
 
@@ -859,7 +859,7 @@
 ae->worker->keepalive,
 ae->worker->socket_timeout,
 ae->worker->socket_buf, l);
-if (ae->sd >= 0) {
+if (IS_VALID_SOCKET(ae->sd)) {
 if (JK_IS_DEBUG_LEVEL(l)) {
 jk_log(l, JK_LOG_DEBUG,
"Connected socket %d to (%s)",
@@ -1170,7 +1170,7 @@
 /*
  * First try to reuse open connections...
  */
-while ((ae->sd > 0)) {
+while (IS_VALID_SOCKET(ae->sd)) {
 int rc = 0;
 err = 0;
 if (ae->worker->socket_timeout) {
@@ -1179,7 +1179,7 @@
"Socket %d is not connected any more (errno=%d)",
ae->sd, errno);
 jk_close_socket(ae->sd);
-ae->sd = -1;
+ae->sd = JK_INVALID_SOCKET;
 err++;
 }
 }
@@ -

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

[mturk]

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
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/common/jk_version.h?rev=422997&r1=422996&r2=422997&view=diff
==
--- tomcat/connectors/trunk/jk/native/common/jk_version.h (original)
+++ tomcat/connectors/trunk/jk/native/common/jk_version.h Tue Jul 18 00:19:55 
2006
@@ -25,8 +25,8 @@
 /** START OF AREA TO MODIFY BEFORE RELEASING */
 #define JK_VERMAJOR 1
 #define JK_VERMINOR 2
-#define JK_VERFIX   17
-#define JK_VERSTRING"1.2.17"
+#define JK_VERFIX   18
+#define JK_VERSTRING"1.2.18"
 
 /* Beta number */
 #define JK_VERBETA  0



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Jean-frederic Clere]

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 suggest 
the use of socklen_t and explicitely cast the return from sizeof().


I would suggest to have a JK_SOCKLEN_T as we have the JK_INT*, just in 
case a platform does not have socklen_t. (See configure.in)



Cheers

Jean-Frederic




I just wonder who is the genius that invented something that
stupid as socklen_t :)
I suppose it should be some sort of a size, correct?



Found some interesting pieces:

1) http://www.opengroup.org/onlinepubs/007908799/xns/syssocket.h.html

Says:

 makes available a type, socklen_t, which is an unsigned 
opaque integral type of length of at least 32 bits. To forestall 
portability problems, it is recommended that applications should not 
use values larger than 2^32 - 1.


2) http://www.opengroup.org/austin/docs/austin_76r1.txt

has interesting comments (...The type socklen_t is an unfortunate 
historical accident...):


 The type socklen_t was invented to cover the range of implementations
 seen in the field.  The intent of socklen_t is to be the type for all
 lengths that are naturally bounded in size, that is, that they are the
 length of a buffer which cannot sensibly become of massive size: network
 addresses, hostnames, string representations of these, ancillary data,
 control messages, and socket options are examples.  Truly boundless
 sizes are represented by size_t as in read(), write(), etc.

 All socklen_t types were originally (in BSD UNIX) of type int.
 During the development of the document it was decided to change
 all buffer lengths to size_t, which appears at face value to make sense.
 When dual mode 32/64 bit systems came along, this choice unnecessarily
 complicated system interfaces because size_t (with long) was a different
 size under ILP32 and LP64 models.  Reverting to int would have happened
 except that some systems had already shipped 64-bit only interfaces. The
 compromise was a type which could be defined to be any size by the
 implementation: socklen_t.

and


 People are continually confused about socklen_t.

 The type socklen_t is an unfortunate historical accident, and needed to
 be invented to cover the range of implementations seen in the field.
 The intent of socklen_t is to be the type for all lengths that are
 naturally bounded in size, that is, that they are the length of a
 buffer which cannot sensibly become of massive size: network addresses,
 hostnames, string representations of these, ancillary data, control
 messages, and socket options are examples.  Truly boundless sizes are
 represented by size_t as in read(), write(), etc.

 All socklen_t types were originally (in BSD UNIX) of type int.
 An overzealous unknown decided without significant review to "correct"
 all buffer lengths to size_t, which appears on its face to make sense.
 When dual mode 32/64 bit systems came along, this choice unnecessarily
 complicated system interfaces because size_t (with long) was a different
 size under ILP32 and LP64 models.  Reverting to int would have happened
 except that some systems had already shipped 64-bit only interfaces. The
 compromise was a type which could be defined to be any size by the
 implementation: socklen_t.

Rainer



--
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]

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

[mturk]

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_connect.c
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/common/jk_connect.c?rev=423000&r1=422999&r2=423000&view=diff
==
--- tomcat/connectors/trunk/jk/native/common/jk_connect.c (original)
+++ tomcat/connectors/trunk/jk/native/common/jk_connect.c Tue Jul 18 00:31:31 
2006
@@ -146,7 +146,7 @@
 /* Evaluate the efdset */
 if (FD_ISSET(sock, &efdset)) {
 /* The connect failed. */
-int rclen = sizeof(rc);
+int rclen = (int)sizeof(rc);
 if (getsockopt(sock, SOL_SOCKET, SO_ERROR, (char*) &rc, &rclen))
 rc = 0;
 soblock(sock);
@@ -177,7 +177,7 @@
&& (timeout > 0)) {
 fd_set wfdset;
 struct timeval tv;
-unsigned int rclen = sizeof(rc);
+socklen_t rclen = (socklen_t)sizeof(rc);
 
 FD_ZERO(&wfdset);
 FD_SET(sock, &wfdset);



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Henri Gomez]

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-frederic Clere <[EMAIL PROTECTED]>:

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 suggest
> the use of socklen_t and explicitely cast the return from sizeof().

I would suggest to have a JK_SOCKLEN_T as we have the JK_INT*, just in
case a platform does not have socklen_t. (See configure.in)


Cheers

Jean-Frederic

>
>> I just wonder who is the genius that invented something that
>> stupid as socklen_t :)
>> I suppose it should be some sort of a size, correct?
>
>
> Found some interesting pieces:
>
> 1) http://www.opengroup.org/onlinepubs/007908799/xns/syssocket.h.html
>
> Says:
>
>  makes available a type, socklen_t, which is an unsigned
> opaque integral type of length of at least 32 bits. To forestall
> portability problems, it is recommended that applications should not
> use values larger than 2^32 - 1.
>
> 2) http://www.opengroup.org/austin/docs/austin_76r1.txt
>
> has interesting comments (...The type socklen_t is an unfortunate
> historical accident...):
>
>  The type socklen_t was invented to cover the range of implementations
>  seen in the field.  The intent of socklen_t is to be the type for all
>  lengths that are naturally bounded in size, that is, that they are the
>  length of a buffer which cannot sensibly become of massive size: network
>  addresses, hostnames, string representations of these, ancillary data,
>  control messages, and socket options are examples.  Truly boundless
>  sizes are represented by size_t as in read(), write(), etc.
>
>  All socklen_t types were originally (in BSD UNIX) of type int.
>  During the development of the document it was decided to change
>  all buffer lengths to size_t, which appears at face value to make sense.
>  When dual mode 32/64 bit systems came along, this choice unnecessarily
>  complicated system interfaces because size_t (with long) was a different
>  size under ILP32 and LP64 models.  Reverting to int would have happened
>  except that some systems had already shipped 64-bit only interfaces. The
>  compromise was a type which could be defined to be any size by the
>  implementation: socklen_t.
>
> and
>
>
>  People are continually confused about socklen_t.
>
>  The type socklen_t is an unfortunate historical accident, and needed to
>  be invented to cover the range of implementations seen in the field.
>  The intent of socklen_t is to be the type for all lengths that are
>  naturally bounded in size, that is, that they are the length of a
>  buffer which cannot sensibly become of massive size: network addresses,
>  hostnames, string representations of these, ancillary data, control
>  messages, and socket options are examples.  Truly boundless sizes are
>  represented by size_t as in read(), write(), etc.
>
>  All socklen_t types were originally (in BSD UNIX) of type int.
>  An overzealous unknown decided without significant review to "correct"
>  all buffer lengths to size_t, which appears on its face to make sense.
>  When dual mode 32/64 bit systems came along, this choice unnecessarily
>  complicated system interfaces because size_t (with long) was a different
>  size under ILP32 and LP64 models.  Reverting to int would have happened
>  except that some systems had already shipped 64-bit only interfaces. The
>  compromise was a type which could be defined to be any size by the
>  implementation: socklen_t.
>
> Rainer
>
>>
>> --
>> 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]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Mladen Turk]

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.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[mturk]

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_worker.c
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/common/jk_lb_worker.c?rev=423038&r1=423037&r2=423038&view=diff
==
--- tomcat/connectors/trunk/jk/native/common/jk_lb_worker.c (original)
+++ tomcat/connectors/trunk/jk/native/common/jk_lb_worker.c Tue Jul 18 03:22:25 
2006
@@ -691,7 +691,7 @@
 rec->s->lb_value -= rec->s->lb_mult;
 else {
 rec->s->lb_value = 0;
-if (JK_IS_DEBUG_LEVEL(l))
+if (JK_IS_DEBUG_LEVEL(l)) {
 jk_log(l, JK_LOG_DEBUG,
"worker %s has load value to low (%"
JK_UINT64_T_FMT
@@ -702,6 +702,7 @@
rec->s->name,
rec->s->lb_value,
rec->s->lb_mult);
+}
 }
 
 /* When returning the endpoint mark the worker as not busy.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Henri Gomez]

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 used (and the build works with
> it).
>

Can you check the current head?
I committed the fix.

--
Mladen.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Rainer Jung]

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 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.

-
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: Next try: mod_jk 1.2.17 release candidate ready to test

[Mladen Turk]

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.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_jk 1.2.17 vs. mod_proxy_ajp

[Jim Jagielski]

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 of the probable/planned timeframe for mod_proxy_ajp  
catching up.




Since most of the people working on the mod_proxy_*
stuff aren't also on the TC dev lists, it is hard for them
to know of the improvements, etc...

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Jim Jagielski]

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...

% gcc --version
powerpc-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc.  
build 5247)




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_jk 1.2.17 vs. mod_proxy_ajp

[Henri Gomez]

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 other has to.  I'm just wanting to get
> some grasp of the probable/planned timeframe for mod_proxy_ajp
> catching up.
>

Since most of the people working on the mod_proxy_*
stuff aren't also on the TC dev lists, it is hard for them
to know of the improvements, etc...


:)

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Henri Gomez]

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/getsockopt.php
> says that the OS/X uses socklen_t as well, we should be fine.
>

I get no build error...

% gcc --version
powerpc-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc.
build 5247)



-
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]

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

[mturk]

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/java/org/apache/coyote/http11/Http11Protocol.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Http11Protocol.java?rev=423110&r1=423109&r2=423110&view=diff
==
--- tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Http11Protocol.java 
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Http11Protocol.java Tue 
Jul 18 08:16:38 2006
@@ -1,673 +1,673 @@
-/*
- *  Copyright 1999-2006 The Apache Software Foundation
- *
- *  Licensed under the Apache License, Version 2.0 (the "License");
- *  you may not use this file except in compliance with the License.
- *  You may obtain a copy of the License at
- *
- *  http://www.apache.org/licenses/LICENSE-2.0
- *
- *  Unless required by applicable law or agreed to in writing, software
- *  distributed under the License is distributed on an "AS IS" BASIS,
- *  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- *  See the License for the specific language governing permissions and
- *  limitations under the License.
- */
-
-package org.apache.coyote.http11;
-
-import java.net.InetAddress;
-import java.net.Socket;
-import java.net.URLEncoder;
-import java.util.HashMap;
-import java.util.Iterator;
-import java.util.concurrent.Executor;
-
-import javax.management.MBeanRegistration;
-import javax.management.MBeanServer;
-import javax.management.ObjectName;
-
-import org.apache.coyote.ActionCode;
-import org.apache.coyote.ActionHook;
-import org.apache.coyote.Adapter;
-import org.apache.coyote.ProtocolHandler;
-import org.apache.coyote.RequestGroupInfo;
-import org.apache.coyote.RequestInfo;
-import org.apache.tomcat.util.modeler.Registry;
-import org.apache.tomcat.util.net.JIoEndpoint;
-import org.apache.tomcat.util.net.SSLImplementation;
-import org.apache.tomcat.util.net.ServerSocketFactory;
-import org.apache.tomcat.util.net.JIoEndpoint.Handler;
-import org.apache.tomcat.util.res.StringManager;
-
-
-/**
- * Abstract the protocol implementation, including threading, etc.
- * Processor is single threaded and specific to stream-based protocols,
- * will not fit Jk protocols like JNI.
- *
- * @author Remy Maucherat
- * @author Costin Manolache
- * @deprecated
- */
-public class Http11Protocol 
-implements ProtocolHandler, MBeanRegistration {
-
-
-protected static org.apache.commons.logging.Log log
-= org.apache.commons.logging.LogFactory.getLog(Http11Protocol.class);
-
-/**
- * The string manager for this package.
- */
-protected static StringManager sm =
-StringManager.getManager(Constants.Package);
-
-
-//  Constructor
-
-
-public Http11Protocol() {
-setSoLinger(Constants.DEFAULT_CONNECTION_LINGER);
-setSoTimeout(Constants.DEFAULT_CONNECTION_TIMEOUT);
-//setServerSoTimeout(Constants.DEFAULT_SERVER_SOCKET_TIMEOUT);
-setTcpNoDelay(Constants.DEFAULT_TCP_NO_DELAY);
-}
-
-
-// - Fields
-
-
-protected Http11ConnectionHandler cHandler = new 
Http11ConnectionHandler(this);
-protected JIoEndpoint endpoint = new JIoEndpoint();
-
-
-// *
-protected ObjectName tpOname = null;
-// *
-protected ObjectName rgOname = null;
-
-
-protected ServerSocketFactory socketFactory = null;
-protected SSLImplementation sslImplementation = null;
-
-
-// - ProtocolHandler Implementation
-// *
-
-
-protected HashMap attributes = new HashMap();
-
-
-/**
- * Pass config info
- */
-public void setAttribute(String name, Object value) {
-if (log.isTraceEnabled()) {
-log.trace(sm.getString("http11protocol.setattribute", name, 
value));
-}
-attributes.put(name, value);
-}
-
-public Object getAttribute(String key) {
-return attributes.get(key);
-}
-
-public Iterator getAttributeNames() {
-return attributes.keySet().iterator();
-}
-
-
-/**
- * The adapter, used to call the connector.
- */
-protected Adapter adapter;
-public void setAdapter(Adapter adapter) { this.adapter = adapter; }
-public Adapter getAdapter() { return adapter; }
-
-
-public void init() throws Exception {
-endpoint.setName(getName());
-endpoint.setHandler(cHandler);
-
-// Verify the validity of the configured socket factory
-try {
-if (secure) {
-sslImplementation =
-SSLImplementation.getInstance(sslImplemen

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

[Mladen Turk]

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 PROTECTED]

mod_jk premature documentation

[Filip Hanik - Dev Lists]

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 is a release.

one example is recycle_timeout at
http://tomcat.apache.org/connectors-doc/config/workers.html

Filip

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Jim Jagielski]

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 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...

% gcc --version
powerpc-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc.
build 5247)



-
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: Next try: mod_jk 1.2.17 release candidate ready to test

[Rainer Jung]

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, so we're ready for a 1.2.18 release ?
>>
>
> Sure if the Rainer still has the energy
> for another run :)
>
> Regards,
> Mladen.
Jim Jagielski wrote:

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 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...

% gcc --version
powerpc-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc.
build 5247)


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

mod_jk 1.2.17+ Recover time

[David Rees]

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
recover_wait_time).

However, Tomcat will typically recover in just a handful of seconds so
this results in nearly a minute of downtime when downtime should only
be perhaps 10 seconds.

Compounding this problem it doesn't appear to be possible to override
this behavior either through the worker configuration and the status
module forces a minimum of 60 seconds.

The only workaround to this problem I see is to setup a Tomcat
cluster, but this isn't feasible in all cases.

I'm more than happy to help work up a patch to allow configuring of
this parameter in the workers file and to allow a lower minimum
recover_wait_time as well if such a patch would be accepted. Of
course, if a mod_jk developer can cook it up quickly that is fine too,
I will test it.

-Dave

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_jk premature documentation

[Rainer Jung]

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. Otherwise it's getting very confusing for people.


Filip Hanik - Dev Lists wrote:
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 is a release.

one example is recycle_timeout at
http://tomcat.apache.org/connectors-doc/config/workers.html

Filip



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[fhanik]

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/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/GroupChannel.java
URL: 
http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/GroupChannel.java?rev=423156&r1=423155&r2=423156&view=diff
==
--- 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/GroupChannel.java
 (original)
+++ 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/GroupChannel.java
 Tue Jul 18 11:02:36 2006
@@ -501,8 +501,9 @@
  * @param channelListener ChannelListener
  */
 public void addChannelListener(ChannelListener channelListener) {
-if (!this.channelListeners.contains(channelListener) )
+if (!this.channelListeners.contains(channelListener) ) {
 this.channelListeners.add(channelListener);
+}
 }
 
 /**



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[fhanik]

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 different contexts support

Modified:

tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tipis/AbstractReplicatedMap.java

Modified: 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tipis/AbstractReplicatedMap.java
URL: 
http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tipis/AbstractReplicatedMap.java?rev=423158&r1=423157&r2=423158&view=diff
==
--- 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tipis/AbstractReplicatedMap.java
 (original)
+++ 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tipis/AbstractReplicatedMap.java
 Tue Jul 18 11:06:57 2006
@@ -91,6 +91,7 @@
 private transient ClassLoader[] externalLoaders;
 protected transient int currentNode = 0;
 private transient long accessTimeout = 5000;
+private transient String mapname = "";
 
 
 
//--
@@ -125,6 +126,7 @@
 }
 
 private void init(Object owner, Channel channel, String mapContextName, 
long timeout, int channelSendOptions,ClassLoader[] cls) {
+log.info("Initializing AbstractReplicatedMap with context 
name:"+mapContextName);
 this.mapOwner = owner;
 this.externalLoaders = cls;
 this.channelSendOptions = channelSendOptions;
@@ -132,6 +134,7 @@
 this.rpcTimeout = timeout;
 
 try {
+this.mapname = mapContextName;
 //unique context is more efficient if it is stored as bytes
 this.mapContextName = mapContextName.getBytes(chset);
 } catch (UnsupportedEncodingException x) {
@@ -224,6 +227,18 @@
 this.stateTransferred = false;
 this.externalLoaders = null;
 }
+
+public int hashCode() {
+return Arrays.hashCode(this.mapContextName);
+}
+
+public boolean equals(Object o) {
+if ( o == null ) return false;
+if ( !(o instanceof AbstractReplicatedMap)) return false;
+if ( !(o.getClass().equals(this.getClass())) ) return false;
+AbstractReplicatedMap other = (AbstractReplicatedMap)o;
+return Arrays.equals(mapContextName,other.mapContextName);
+}
 
 
//--
 //  GROUP COM INTERFACES
@@ -438,6 +453,10 @@
 if (! (msg instanceof MapMessage)) return;
 
 MapMessage mapmsg = (MapMessage) msg;
+if ( log.isTraceEnabled() ) {
+log.trace("Map["+mapname+"] received message:"+mapmsg);
+}
+
 try {
 mapmsg.deserialize(getExternalLoaders());
 } catch (IOException x) {
@@ -518,12 +537,12 @@
 }
 
 public boolean accept(Serializable msg, Member sender) {
-if ( log.isTraceEnabled() ) log.trace("Map accepting"+msg);
 boolean result = false;
 if (msg instanceof MapMessage) {
+if ( log.isTraceEnabled() ) log.trace("Map["+mapname+"] 
accepting"+msg);
 result = Arrays.equals(mapContextName, ( (MapMessage) 
msg).getMapId());
+if ( log.isTraceEnabled() ) log.trace("Msg["+mapname+"] 
accepted["+result+"]"+msg);
 }
-if ( log.isTraceEnabled() ) log.trace("Msg 
accepted["+result+"]"+msg);
 return result;
 }
 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[bugzilla]

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_bug.cgi?id=36549





--- Additional Comments From [EMAIL PROTECTED]  2006-07-18 18:19 ---
(In reply to comment #2)
> I'm not sure this is a Tomcat problem.  I actually have a Solaris 64-bit
> installation and I can't reproduce this on Tomcat 5.5.9 with either JDK 1.4 or
> 5.0 (latest minor releases for both of them).  I wonder if it's something
> specific to mod_jk?


Hi Is there any solution for this issue. Becasue I get the same exception on JSK
1.5.0_01, Tomcat 5.5.9 and Solaris 10. I will appreciate your reply on this
thanks sin advance

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[fhanik]

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/catalina/tribes/group/GroupChannel.java

Modified: 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/GroupChannel.java
URL: 
http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/GroupChannel.java?rev=423169&r1=423168&r2=423169&view=diff
==
--- 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/GroupChannel.java
 (original)
+++ 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/GroupChannel.java
 Tue Jul 18 11:25:18 2006
@@ -503,6 +503,8 @@
 public void addChannelListener(ChannelListener channelListener) {
 if (!this.channelListeners.contains(channelListener) ) {
 this.channelListeners.add(channelListener);
+} else {
+throw new IllegalArgumentException("Listener already 
exists:"+channelListener);
 }
 }
 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_jk premature documentation

[William A. Rowe, Jr.]

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 the last release. Otherwise it's getting very confusing for people.


On httpd, we added the 'Compatibility' tag to address this, e.g.

http://httpd.apache.org/docs/trunk/mod/mod_aspdotnet.html#aspnet

or

http://httpd.apache.org/docs/trunk/mod/mod_deflate.html#deflatecompressionlevel

So users of the 'current version' know what features apply to the module they
have installed/are configuring for.

Just my 2c US.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_jk 1.2.17 vs. mod_proxy_ajp

[Jess Holle]

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
> 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 of the probable/planned timeframe for mod_proxy_ajp
> catching up.
>

Since most of the people working on the mod_proxy_*
stuff aren't also on the TC dev lists, it is hard for them
to know of the improvements, etc...


:)

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_jk 1.2.17+ Recover time

[Jess Holle]

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 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
recover_wait_time).

However, Tomcat will typically recover in just a handful of seconds so
this results in nearly a minute of downtime when downtime should only
be perhaps 10 seconds.

Compounding this problem it doesn't appear to be possible to override
this behavior either through the worker configuration and the status
module forces a minimum of 60 seconds.

The only workaround to this problem I see is to setup a Tomcat
cluster, but this isn't feasible in all cases.

I'm more than happy to help work up a patch to allow configuring of
this parameter in the workers file and to allow a lower minimum
recover_wait_time as well if such a patch would be accepted. Of
course, if a mod_jk developer can cook it up quickly that is fine too,
I will test it.

-Dave

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[bugzilla]

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_bug.cgi?id=36549





--- Additional Comments From [EMAIL PROTECTED]  2006-07-18 19:17 ---
(In reply to comment #3)
> (In reply to comment #2)
> > I'm not sure this is a Tomcat problem.  I actually have a Solaris 64-bit
> > installation and I can't reproduce this on Tomcat 5.5.9 with either JDK 1.4 
> > or
> > 5.0 (latest minor releases for both of them).  I wonder if it's something
> > specific to mod_jk?
> 
> 
> Hi Is there any solution for this issue. Becasue I get the same exception on 
> JSK
> 1.5.0_01, Tomcat 5.5.9 and Solaris 10. I will appreciate your reply on this
> thanks sin advance



Anyway  I fixed the issue for me, do not know it will help you guys or not. I
did not configure with httpd.conf, i was using standar 8080 port and default
config. now it works after putting httpd.conf

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[fhanik]

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:

tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tipis/AbstractReplicatedMap.java

Modified: 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tipis/AbstractReplicatedMap.java
URL: 
http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tipis/AbstractReplicatedMap.java?rev=423243&r1=423242&r2=423243&view=diff
==
--- 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tipis/AbstractReplicatedMap.java
 (original)
+++ 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tipis/AbstractReplicatedMap.java
 Tue Jul 18 14:03:21 2006
@@ -45,6 +45,7 @@
 import org.apache.commons.logging.Log;
 import org.apache.commons.logging.LogFactory;
 import org.apache.catalina.tribes.util.Arrays;
+import java.util.ConcurrentModificationException;
 
 /**
  * Title: 
@@ -860,11 +861,13 @@
 //todo, implement a counter variable instead
 //only count active members in this node
 int counter = 0;
-Iterator i = super.entrySet().iterator();
-while ( i.hasNext() ) {
-Map.Entry e = (Map.Entry)i.next();
-MapEntry entry = (MapEntry)e.getValue();
-if ( entry.isPrimary() && entry.getValue()!=null ) counter++;
+Object[] items = super.entrySet().toArray();
+for (int i=0; i

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/

[fhanik]

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/MessageDispatch15Interceptor.java

tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/interceptors/MessageDispatchInterceptor.java

tomcat/container/tc5.5.x/modules/groupcom/test/java/org/apache/catalina/tribes/test/channel/TestDataIntegrity.java

Modified: 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/interceptors/MessageDispatch15Interceptor.java
URL: 
http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/interceptors/MessageDispatch15Interceptor.java?rev=423244&r1=423243&r2=423244&view=diff
==
--- 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/interceptors/MessageDispatch15Interceptor.java
 (original)
+++ 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/interceptors/MessageDispatch15Interceptor.java
 Tue Jul 18 14:04:00 2006
@@ -15,17 +15,20 @@
 package org.apache.catalina.tribes.group.interceptors;
 
 import java.util.concurrent.LinkedBlockingQueue;
+import java.util.concurrent.ThreadPoolExecutor;
 import java.util.concurrent.atomic.AtomicLong;
 
 import org.apache.catalina.tribes.ChannelMessage;
 import org.apache.catalina.tribes.Member;
 import org.apache.catalina.tribes.group.InterceptorPayload;
 import org.apache.catalina.tribes.transport.bio.util.LinkObject;
+import java.util.concurrent.TimeUnit;
 
 /**
  * 
  * Same implementation as the MessageDispatchInterceptor
  * except is ues an atomic long for the currentSize calculation
+ * and uses a thread pool for message sending.
  * 
  * @author Filip Hanik
  * @version 1.0
@@ -34,7 +37,11 @@
 public class MessageDispatch15Interceptor extends MessageDispatchInterceptor {
 
 protected AtomicLong currentSize = new AtomicLong(0);
-protected LinkedBlockingQueue queue = new LinkedBlockingQueue();
+protected ThreadPoolExecutor executor = null;
+protected int maxThreads = 10;
+protected int maxSpareThreads = 2;
+protected long keepAliveTime = 5000;
+protected LinkedBlockingQueue runnablequeue = new 
LinkedBlockingQueue();
 
 public long getCurrentSize() {
 return currentSize.get();
@@ -50,32 +57,55 @@
 }
 
 public boolean addToQueue(ChannelMessage msg, Member[] destination, 
InterceptorPayload payload) {
-LinkObject obj = new LinkObject(msg,destination,payload);
-return queue.offer(obj);
+final LinkObject obj = new LinkObject(msg,destination,payload);
+Runnable r = new Runnable() {
+public void run() {
+sendAsyncData(obj);
+}
+};
+executor.execute(r);
+return true;
 }
 
 public LinkObject removeFromQueue() {
-LinkObject head = null;
-try {
-head = (LinkObject)queue.take();
-}catch ( InterruptedException x ) {}
-return head;
+return null; //not used, thread pool contains its own queue.
 }
 
 public void startQueue() {
-msgDispatchThread = new Thread(this);
-
msgDispatchThread.setName("MessageDispatch15Interceptor.MessageDispatchThread");
-msgDispatchThread.setDaemon(true);
-msgDispatchThread.setPriority(Thread.MAX_PRIORITY);
+if ( run ) return;
+executor = new 
ThreadPoolExecutor(maxSpareThreads,maxThreads,keepAliveTime,TimeUnit.MILLISECONDS,runnablequeue);
 run = true;
-msgDispatchThread.start();
 }
 
 public void stopQueue() {
 run = false;
-msgDispatchThread.interrupt();
+executor.shutdownNow();
 setAndGetCurrentSize(0);
+runnablequeue.clear();
 }
 
+public long getKeepAliveTime() {
+return keepAliveTime;
+}
+
+public int getMaxSpareThreads() {
+return maxSpareThreads;
+}
+
+public int getMaxThreads() {
+return maxThreads;
+}
+
+public void setKeepAliveTime(long keepAliveTime) {
+this.keepAliveTime = keepAliveTime;
+}
+
+public void setMaxSpareThreads(int maxSpareThreads) {
+this.maxSpareThreads = maxSpareThreads;
+}
+
+public void setMaxThreads(int maxThreads) {
+this.maxThreads = maxThreads;
+}
 
 }

Modified: 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/interceptors/MessageDispatchInterceptor.java
URL: 
http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/interceptors/MessageDispatchInterceptor.java?rev=423244&r1=423243&r2=423244&view=diff
=

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

[Peter Rossbach]

+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 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 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.

 
-

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 1.2.17+ Recover time

[David Rees]

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 took 18).


Yes, it's hard-coded. See my references in my first post.

-Dave

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]