Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup Bootstrap.java

2005-09-16 Thread Costin Manolache 
I have few weeks, I'm trying to sync up some of the few changes I made 
in the last year before the code is moved to svn and try a bit more
the 'embedded' scenario ( both single-jar tomcat - that actually works 
well, and also coyote-only ).


I uploaded 2 jars at http://people.apache.org/~costin/mini - one has 
full jasper, the other only the jsp runtime. There are still few 
requirements  on the dir structure - you need to have the conf/web.xml, 
work/, webapps/, but besides that it's just 'java -jar 
tomcat+jasper.jar', no extra jars required.


tomcat-http11.jar is just coyote, with a javascript adapter as example ( 
 let me know if you want to play with it, I'll send additional info ).


Costin


Henri Gomez wrote:

Happy to see Costin is back :)

15 Sep 2005 06:04:01 -, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:


costin  2005/09/14 23:04:01

 Modified:catalina/src/share/org/apache/catalina/startup
   Bootstrap.java
 Log:
 Support for corner case, when all tomcat is in a single jar and no fancy 
classloaders are used.

 Revision  ChangesPath
 1.23  +9 -5  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/Bootstrap.java

 Index: Bootstrap.java
 ===
 RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/Bootstrap.java,v
 retrieving revision 1.22
 retrieving revision 1.23
 diff -u -r1.22 -r1.23
 --- Bootstrap.java3 May 2005 14:12:52 -   1.22
 +++ Bootstrap.java15 Sep 2005 06:04:01 -  1.23
 @@ -95,6 +95,10 @@
  private void initClassLoaders() {
  try {
  commonLoader = createClassLoader("common", null);
 +if( commonLoader == null ) {
 +// no config file, default to this loader - we might be in a 
'single' env.
 +commonLoader=this.getClass().getClassLoader();
 +}
  catalinaLoader = createClassLoader("server", commonLoader);
  sharedLoader = createClassLoader("shared", commonLoader);
  } catch (Throwable t) {
 @@ -122,10 +126,10 @@
  // Local repository
  boolean packed = false;
  if (repository.startsWith(CATALINA_HOME_TOKEN)) {
 -repository = getCatalinaHome()
 +repository = getCatalinaHome()
  + repository.substring(CATALINA_HOME_TOKEN.length());
  } else if (repository.startsWith(CATALINA_BASE_TOKEN)) {
 -repository = getCatalinaBase()
 +repository = getCatalinaBase()
  + repository.substring(CATALINA_BASE_TOKEN.length());
  }

 @@ -159,14 +163,14 @@
  // Retrieving MBean server
  MBeanServer mBeanServer = null;
  if (MBeanServerFactory.findMBeanServer(null).size() > 0) {
 -mBeanServer =
 +mBeanServer =
  (MBeanServer) MBeanServerFactory.findMBeanServer(null).get(0);
  } else {
  mBeanServer = MBeanServerFactory.createMBeanServer();
  }

  // Register the server classloader
 -ObjectName objectName =
 +ObjectName objectName =
  new ObjectName("Catalina:type=ServerClassLoader,name=" + name);
  mBeanServer.registerMBean(classLoader, objectName);





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

Michael Bünermann/HBF/Minden/kampa/DE ist außer Haus .

2005-09-16 Thread Michael . Buenermann 

Ich werde ab  16.09.2005 nicht im Büro sein. Ich kehre zurück am
20.09.2005.

Ich werde Ihre Nachricht nach meiner Rückkehr beantworten. In dringenden
Fällen wenden Sie sich bitte Herrn Bagehorn
([EMAIL PROTECTED]). Herr Bagehorn hat die Rufnummer
0571/93425-80) In ganz dringenden Fällen hinterlassen Sie bitte eine
Nachricht auf meiner Mobilbox unter der Funk-Rufnummer: 0171/99 33 525.

DO NOT REPLY [Bug 35835] - Submitting changes through admin app corrupts the HTTPS connector definition in server.xml

2005-09-16 Thread 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=35835





--- Additional Comments From [EMAIL PROTECTED]  2005-09-17 03:28 ---
I verified that this works in 5.5.11-alpha. Any idea whether/when the fix will
be ported to 5.0.x (currently 5.0.30) ? If the fix is to the admin webapp only,
then,
can I just take the admin webapp from 5.5.11 and then try it under 5.0.x ? 
thanks.

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

5.0.28 chunked input?

2005-09-16 Thread Jim Moy 
I am running standalone Tomcat 5.0.28, and am having problems with
chunked requests.

My servlet is being called before a chunked POST has completed the
transfer of its body containing x-www-form-urlencoded data.  My
servlet calls to getParameter() return empty values, because the chunk
containing the data has not arrived yet.  I expected the chunked data
to be processed before I am called, is this an incorrect assumption?

I am watching the exchange in Ethereal and see that the chunk does
eventually arrive, but I have already completed my servlet processing
by that time.  I've attached the TCP trace (with proprietary paths
fixed up), thanks to anyone who can shed light on this problem.  Note
that my servlet is generating the XML response.

Thanks for any help,

Jim Moy


POST /site/path/ HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Accept: */*
User-Agent: UNTRUSTED/1.0
Host: myhost.net
Transfer-Encoding: chunked

HTTP/1.1 200 OK
Content-Type: text/plain;charset=ISO-8859-1
Content-Length: 77
Date: Thu, 15 Sep 2005 15:18:07 GMT
Server: Apache-Coyote/1.1



 mystatus


18
data1=value1&data2=value2
0

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

DO NOT REPLY [Bug 36681] - 2 Tomcat 5.5.7 clusters come to a grinding hault and generate errors

2005-09-16 Thread 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=36681





--- Additional Comments From [EMAIL PROTECTED]  2005-09-16 22:46 ---
Be careful when upgrading to 5.5.9 and the cluster fix pak from bug 34389. I see
that you are using pooled cluster replication which appears to be broken. (see
Bug 36540) I didn't test that config, but the 5.5.11 release though. But that
release uses the fix pak, too.

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

DO NOT REPLY [Bug 36681] - 2 Tomcat 5.5.7 clusters come to a grinding hault and generate errors

2005-09-16 Thread 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=36681





--- Additional Comments From [EMAIL PROTECTED]  2005-09-16 20:57 ---
Since one of the messages is "member disappeared": If you use a big heap size,
make sure you activate verbose logging of GC to check, if you have full GCs
lasting longer than your heartbeat timeout of 3 seconds. In that case, increase
your heartbeat timeout or optimize GC duration.

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

DO NOT REPLY [Bug 36681] - 2 Tomcat 5.5.7 clusters come to a grinding hault and generate errors

2005-09-16 Thread 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=36681





--- Additional Comments From [EMAIL PROTECTED]  2005-09-16 18:18 ---
Hi Peter,

Thank you for your quick reply. Below is my server.xml that you requested for 
both server 1 and server 2.

Tomcat 1







  
  
  
  

  
  







  

  

  
  




















 
 



  
  

  

  
  

  
  

  

  

  

  

  
  

 











   
















  



  





Tomcat 2








  
  
  
  

  
  







  

  

  
  




















 
 



  
  

  

  
  

  
  

  

  

  

  

  
  

 











   
















  



  



Hope this helps you out.  I will however in the mean time take your advice and 
install Tomcat 5.5.9 on a dev env't and do cluster testing before I deploy on 
Production.  Let me know if we can tweak the above.  Thanks

Zubair


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

Re: [EMAIL PROTECTED]: Project jakarta-tomcat-jk-native (in module jakarta-tomcat-connectors) failed

2005-09-16 Thread Bill Barker 


- Original Message - 
From: "William A. Rowe, Jr." <[EMAIL PROTECTED]>

To: "Tomcat Developers List" 
Sent: Friday, September 16, 2005 8:26 AM
Subject: Re: [EMAIL PROTECTED]: Project jakarta-tomcat-jk-native (in module 
jakarta-tomcat-connectors) failed




Question - is gump building against apache 2 trunk or against the
httpd/branches/2.0.x (or some other particular httpd snapshot/rev)?



It's building against the apache2 trunk.  That's the only branch that Graham 
has setup to build in Gump.



The failure below...


Making all in apache-2.0
make[1]: Entering directory 
`/x1/gump/public/workspace/jakarta-tomcat-connectors/jk/native/apache-2.0'
/usr/local/gump/public/workspace/apr/dest-16092005/build-1/libtool --silent 
 --mode=compile 
gcc -I/usr/local/gump/public/workspace/apache-httpd/dest-16092005/include 
 -g -O2 -DUSE_APACHE_MD5 -I ../common  -I /opt/jdk1.4/include -I 
/opt/jdk1.4/include/unix -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE 
 -g -O2 -pthread -DHAVE_APR  -I/usr/local/gump/public/workspace/apr/dest-16092005/include/apr-1 
 -I/usr/local/gump/public/workspace/apr-util/dest-16092005/include/apr-1  
-g -O2 -g -O2 -pthread -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE 
 -c mod_jk.c -o mod_jk.lo

mod_jk.c:85:28: #if with no expression


didn't jive with my expectations below, unless AP_NEED_SET_MUTEX_PERMS
was actually defined, and it shouldn't be defined on 2.0.x.  I'm going
to propose the patch today to define AP_NEED_SET_MUTEX_PERMS to 1, and
then move forward to define it 0 everywhere else on httpd 2.1.x and 
beyond.  I'll propose today so if we are fetching up 2.1+ to build

against, this problem should be resolved.  The code (the final #if was
the one which had 'no expression').

/* Yes; sorta sucks - with luck we will clean this up before httpd-2.2
 * ships, leaving AP_NEED_SET_MUTEX_PERMS def'd as 1 or 0 on all 
platforms.

 */
#ifdef AP_NEED_SET_MUTEX_PERMS
# define JK_NEED_SET_MUTEX_PERMS AP_NEED_SET_MUTEX_PERMS
#else
  /* A special case for httpd-2.0 */
# if !defined(OS2) && !defined(WIN32) && !defined(BEOS) && 
!defined(NETWARE)

#  define JK_NEED_SET_MUTEX_PERMS 1
# else
#  define JK_NEED_SET_MUTEX_PERMS 0
# endif
#endif

#if JK_NEED_SET_MUTEX_PERMS
#include "unixd.h"  /* for unixd_set_global_mutex_perms */
#endif

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







This message is intended only for the use of the person(s) listed above as the 
intended recipient(s), and may contain information that is PRIVILEGED and 
CONFIDENTIAL.  If you are not an intended recipient, you may not read, copy, or 
distribute this message or any attachment. If you received this communication 
in error, please notify us immediately by e-mail and then delete all copies of 
this message and any attachments.

In addition you should be aware that ordinary (unencrypted) e-mail sent through 
the Internet is not secure. Do not send confidential or sensitive information, 
such as social security numbers, account numbers, personal identification 
numbers and passwords, to us via ordinary (unencrypted) e-mail.


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

Re: [EMAIL PROTECTED]: Project jakarta-tomcat-jk-native (in module jakarta-tomcat-connectors) failed

2005-09-16 Thread William A. Rowe, Jr. 

Question - is gump building against apache 2 trunk or against the
httpd/branches/2.0.x (or some other particular httpd snapshot/rev)?

The failure below...


Making all in apache-2.0
make[1]: Entering directory 
`/x1/gump/public/workspace/jakarta-tomcat-connectors/jk/native/apache-2.0'
/usr/local/gump/public/workspace/apr/dest-16092005/build-1/libtool --silent 
--mode=compile gcc 
-I/usr/local/gump/public/workspace/apache-httpd/dest-16092005/include -g -O2 
-DUSE_APACHE_MD5 -I ../common  -I /opt/jdk1.4/include -I 
/opt/jdk1.4/include/unix -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE 
-D_LARGEFILE64_SOURCE -g -O2 -pthread -DHAVE_APR  
-I/usr/local/gump/public/workspace/apr/dest-16092005/include/apr-1 
-I/usr/local/gump/public/workspace/apr-util/dest-16092005/include/apr-1 -g -O2 
-g -O2 -pthread -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -c 
mod_jk.c -o mod_jk.lo
mod_jk.c:85:28: #if with no expression


didn't jive with my expectations below, unless AP_NEED_SET_MUTEX_PERMS
was actually defined, and it shouldn't be defined on 2.0.x.  I'm going
to propose the patch today to define AP_NEED_SET_MUTEX_PERMS to 1, and
then move forward to define it 0 everywhere else on httpd 2.1.x and 
beyond.  I'll propose today so if we are fetching up 2.1+ to build

against, this problem should be resolved.  The code (the final #if was
the one which had 'no expression').

/* Yes; sorta sucks - with luck we will clean this up before httpd-2.2
 * ships, leaving AP_NEED_SET_MUTEX_PERMS def'd as 1 or 0 on all platforms.
 */
#ifdef AP_NEED_SET_MUTEX_PERMS
# define JK_NEED_SET_MUTEX_PERMS AP_NEED_SET_MUTEX_PERMS
#else
  /* A special case for httpd-2.0 */
# if !defined(OS2) && !defined(WIN32) && !defined(BEOS) && !defined(NETWARE)
#  define JK_NEED_SET_MUTEX_PERMS 1
# else
#  define JK_NEED_SET_MUTEX_PERMS 0
# endif
#endif

#if JK_NEED_SET_MUTEX_PERMS
#include "unixd.h"  /* for unixd_set_global_mutex_perms */
#endif

-
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/startup Bootstrap.java

2005-09-16 Thread Remy Maucherat 

[EMAIL PROTECTED] wrote:

costin  2005/09/14 23:04:01

  Modified:catalina/src/share/org/apache/catalina/startup
Bootstrap.java
  Log:
  Support for corner case, when all tomcat is in a single jar and no fancy 
classloaders are used.


That's nice functionality :)

Rémy

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

Re: Bug or Feature inside mod_jk loadbalancer algo?

2005-09-16 Thread Peter Rossbach 

Sounds good to me.

Wrote a spec before implementation is very helpfull :-)

The domain case with sticky session and real clustered szenarios  is  
not easy.


Peter

Mladen Turk schrieb:


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]









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

Re: Small refactoring in Http11Processor

2005-09-16 Thread Mladen Turk 

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]

[EMAIL PROTECTED]: Project jakarta-tomcat-jk-native (in module jakarta-tomcat-connectors) failed

2005-09-16 Thread Bill Barker 
To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project jakarta-tomcat-jk-native has an issue affecting its community 
integration.
This issue affects 1 projects,
 and has been outstanding for 11 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- jakarta-tomcat-jk-native :  Connectors to various web servers


Full details are available at:

http://vmgump.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -INFO- Failed with reason build failed



The following work was performed:
http://vmgump.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native/gump_work/build_jakarta-tomcat-connectors_jakarta-tomcat-jk-native.html
Work Name: build_jakarta-tomcat-connectors_jakarta-tomcat-jk-native (Type: 
Build)
Work ended in a state of : Failed
Elapsed: 32 secs
Command Line: make 
[Working Directory: 
/usr/local/gump/public/workspace/jakarta-tomcat-connectors/jk/native]
-
Making all in common
make[1]: Entering directory 
`/x1/gump/public/workspace/jakarta-tomcat-connectors/jk/native/common'
/usr/local/gump/public/workspace/apr/dest-16092005/build-1/libtool --silent 
--mode=compile gcc 
-I/usr/local/gump/public/workspace/apache-httpd/dest-16092005/include -g -O2 -g 
-O2 -pthread -DHAVE_APR  
-I/usr/local/gump/public/workspace/apr/dest-16092005/include/apr-1 
-I/usr/local/gump/public/workspace/apr-util/dest-16092005/include/apr-1 -g -O2 
-DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -I 
/opt/jdk1.4/include -I /opt/jdk1.4/include/ -c jk_ajp12_worker.c -o 
jk_ajp12_worker.lo
/usr/local/gump/public/workspace/apr/dest-16092005/build-1/libtool --silent 
--mode=compile gcc 
-I/usr/local/gump/public/workspace/apache-httpd/dest-16092005/include -g -O2 -g 
-O2 -pthread -DHAVE_APR  
-I/usr/local/gump/public/workspace/apr/dest-16092005/include/apr-1 
-I/usr/local/gump/public/workspace/apr-util/dest-16092005/include/apr-1 -g -O2 
-DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -I 
/opt/jdk1.4/include -I /opt/jdk1.4/include/ -c jk_connect.c -o jk_connect.lo
/usr/local/gump/public/workspace/apr/dest-16092005/build-1/libtool --silent 
--mode=compile gcc 
-I/usr/local/gump/public/workspace/apache-httpd/dest-16092005/include -g -O2 -g 
-O2 -pthread -DHAVE_APR  
-I/usr/local/gump/public/workspace/apr/dest-16092005/include/apr-1 
-I/usr/local/gump/public/workspace/apr-util/dest-16092005/include/apr-1 -g -O2 
-DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -I 
/opt/jdk1.4/include -I /opt/jdk1.4/include/ -c jk_msg_buff.c -o jk_msg_buff.lo
/usr/local/gump/public/workspace/apr/dest-16092005/build-1/libtool --silent 
--mode=compile gcc 
-I/usr/local/gump/public/workspace/apache-httpd/dest-16092005/include -g -O2 -g 
-O2 -pthread -DHAVE_APR  
-I/usr/local/gump/public/workspace/apr/dest-16092005/include/apr-1 
-I/usr/local/gump/public/workspace/apr-util/dest-16092005/include/apr-1 -g -O2 
-DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -I 
/opt/jdk1.4/include -I /opt/jdk1.4/include/ -c jk_util.c -o jk_util.lo
/usr/local/gump/public/workspace/apr/dest-16092005/build-1/libtool --silent 
--mode=compile gcc 
-I/usr/local/gump/public/workspace/apache-httpd/dest-16092005/include -g -O2 -g 
-O2 -pthread -DHAVE_APR  
-I/usr/local/gump/public/workspace/apr/dest-16092005/include/apr-1 
-I/usr/local/gump/public/workspace/apr-util/dest-16092005/include/apr-1 -g -O2 
-DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -I 
/opt/jdk1.4/include -I /opt/jdk1.4/include/ -c jk_ajp13.c -o jk_ajp13.lo
/usr/local/gump/public/workspace/apr/dest-16092005/build-1/libtool --silent 
--mode=compile gcc 
-I/usr/local/gump/public/workspace/apache-httpd/dest-16092005/include -g -O2 -g 
-O2 -pthread -DHAVE_APR  
-I/usr/local/gump/public/workspace/apr/dest-16092005/include/apr-1 
-I/usr/local/gump/public/workspace/apr-util/dest-16092005/include/apr-1 -g -O2 
-DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -I 
/opt/jdk1.4/include -I /opt/jdk1.4/include/ -c jk_pool.c -o jk_pool.lo
/usr/local/gump/public/workspace/apr/dest-16092005/build-1/libtool --silent 
--mode=compile gcc 
-I/usr/local/gump/public/workspace/apache-httpd/dest-16092005/include -g -O2 -g 
-O2 -pthread -DHAVE_APR  
-I/usr/local/gump/public/workspace/apr/dest-16092005/include/apr-1 
-I/usr/local/gump/public/workspace/apr-util/dest-16092005/include/apr-1 -g -O2 
-DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -I 
/opt/jdk1.4/include -I /opt/jdk1.4/include/ -c jk_worker.c -o jk_worker.lo
/usr/local/gump/public/workspace/apr/dest-16092005/build-

[EMAIL PROTECTED]: Project jakarta-tomcat-jk-native (in module jakarta-tomcat-connectors) failed

2005-09-16 Thread Bill Barker 
To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project jakarta-tomcat-jk-native has an issue affecting its community 
integration.
This issue affects 1 projects,
 and has been outstanding for 11 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- jakarta-tomcat-jk-native :  Connectors to various web servers


Full details are available at:

http://vmgump.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -INFO- Failed with reason build failed



The following work was performed:
http://vmgump.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native/gump_work/build_jakarta-tomcat-connectors_jakarta-tomcat-jk-native.html
Work Name: build_jakarta-tomcat-connectors_jakarta-tomcat-jk-native (Type: 
Build)
Work ended in a state of : Failed
Elapsed: 32 secs
Command Line: make 
[Working Directory: 
/usr/local/gump/public/workspace/jakarta-tomcat-connectors/jk/native]
-
Making all in common
make[1]: Entering directory 
`/x1/gump/public/workspace/jakarta-tomcat-connectors/jk/native/common'
/usr/local/gump/public/workspace/apr/dest-16092005/build-1/libtool --silent 
--mode=compile gcc 
-I/usr/local/gump/public/workspace/apache-httpd/dest-16092005/include -g -O2 -g 
-O2 -pthread -DHAVE_APR  
-I/usr/local/gump/public/workspace/apr/dest-16092005/include/apr-1 
-I/usr/local/gump/public/workspace/apr-util/dest-16092005/include/apr-1 -g -O2 
-DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -I 
/opt/jdk1.4/include -I /opt/jdk1.4/include/ -c jk_ajp12_worker.c -o 
jk_ajp12_worker.lo
/usr/local/gump/public/workspace/apr/dest-16092005/build-1/libtool --silent 
--mode=compile gcc 
-I/usr/local/gump/public/workspace/apache-httpd/dest-16092005/include -g -O2 -g 
-O2 -pthread -DHAVE_APR  
-I/usr/local/gump/public/workspace/apr/dest-16092005/include/apr-1 
-I/usr/local/gump/public/workspace/apr-util/dest-16092005/include/apr-1 -g -O2 
-DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -I 
/opt/jdk1.4/include -I /opt/jdk1.4/include/ -c jk_connect.c -o jk_connect.lo
/usr/local/gump/public/workspace/apr/dest-16092005/build-1/libtool --silent 
--mode=compile gcc 
-I/usr/local/gump/public/workspace/apache-httpd/dest-16092005/include -g -O2 -g 
-O2 -pthread -DHAVE_APR  
-I/usr/local/gump/public/workspace/apr/dest-16092005/include/apr-1 
-I/usr/local/gump/public/workspace/apr-util/dest-16092005/include/apr-1 -g -O2 
-DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -I 
/opt/jdk1.4/include -I /opt/jdk1.4/include/ -c jk_msg_buff.c -o jk_msg_buff.lo
/usr/local/gump/public/workspace/apr/dest-16092005/build-1/libtool --silent 
--mode=compile gcc 
-I/usr/local/gump/public/workspace/apache-httpd/dest-16092005/include -g -O2 -g 
-O2 -pthread -DHAVE_APR  
-I/usr/local/gump/public/workspace/apr/dest-16092005/include/apr-1 
-I/usr/local/gump/public/workspace/apr-util/dest-16092005/include/apr-1 -g -O2 
-DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -I 
/opt/jdk1.4/include -I /opt/jdk1.4/include/ -c jk_util.c -o jk_util.lo
/usr/local/gump/public/workspace/apr/dest-16092005/build-1/libtool --silent 
--mode=compile gcc 
-I/usr/local/gump/public/workspace/apache-httpd/dest-16092005/include -g -O2 -g 
-O2 -pthread -DHAVE_APR  
-I/usr/local/gump/public/workspace/apr/dest-16092005/include/apr-1 
-I/usr/local/gump/public/workspace/apr-util/dest-16092005/include/apr-1 -g -O2 
-DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -I 
/opt/jdk1.4/include -I /opt/jdk1.4/include/ -c jk_ajp13.c -o jk_ajp13.lo
/usr/local/gump/public/workspace/apr/dest-16092005/build-1/libtool --silent 
--mode=compile gcc 
-I/usr/local/gump/public/workspace/apache-httpd/dest-16092005/include -g -O2 -g 
-O2 -pthread -DHAVE_APR  
-I/usr/local/gump/public/workspace/apr/dest-16092005/include/apr-1 
-I/usr/local/gump/public/workspace/apr-util/dest-16092005/include/apr-1 -g -O2 
-DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -I 
/opt/jdk1.4/include -I /opt/jdk1.4/include/ -c jk_pool.c -o jk_pool.lo
/usr/local/gump/public/workspace/apr/dest-16092005/build-1/libtool --silent 
--mode=compile gcc 
-I/usr/local/gump/public/workspace/apache-httpd/dest-16092005/include -g -O2 -g 
-O2 -pthread -DHAVE_APR  
-I/usr/local/gump/public/workspace/apr/dest-16092005/include/apr-1 
-I/usr/local/gump/public/workspace/apr-util/dest-16092005/include/apr-1 -g -O2 
-DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -I 
/opt/jdk1.4/include -I /opt/jdk1.4/include/ -c jk_worker.c -o jk_worker.lo
/usr/local/gump/public/workspace/apr/dest-16092005/build-

Re: Bug or Feature inside mod_jk loadbalancer algo?

2005-09-16 Thread Mladen Turk 

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]