cvs commit: jakarta-tomcat-connectors/jk/native/common jk_connect.c

2005-02-17 Thread mturk
mturk   2005/02/17 00:10:41

  Modified:jk/native/common jk_connect.c
  Log:
  Use provided socket_buffer size instead 8K default if set.
  
  Revision  ChangesPath
  1.41  +8 -4  jakarta-tomcat-connectors/jk/native/common/jk_connect.c
  
  Index: jk_connect.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_connect.c,v
  retrieving revision 1.40
  retrieving revision 1.41
  diff -u -r1.40 -r1.41
  --- jk_connect.c  17 Feb 2005 07:09:27 -  1.40
  +++ jk_connect.c  17 Feb 2005 08:10:40 -  1.41
  @@ -165,8 +165,8 @@
  socket SO_KEEPALIVE set to On);
   }
   
  -if (sock_buf) {
  -set =  DEF_BUFFER_SZ;
  +if (sock_buf  0) {
  +set = sock_buf;
   /* Set socket send buffer size */
   if (setsockopt(sock, SOL_SOCKET, SO_SNDBUF, (const char *)set,
   sizeof(set))) {
  @@ -177,7 +177,7 @@
   JK_TRACE_EXIT(l);
   return -1;
   }
  -set =  DEF_BUFFER_SZ;
  +set = sock_buf;
   /* Set socket receive buffer size */
   if (setsockopt(sock, SOL_SOCKET, SO_RCVBUF, (const char *)set,
   sizeof(set))) {
  @@ -188,6 +188,10 @@
   JK_TRACE_EXIT(l);
   return -1;
   }
  +if (JK_IS_DEBUG_LEVEL(l))
  +jk_log(l, JK_LOG_DEBUG,
  +   socket SO_SNDBUF and  SO_RCVBUF set to d,
  +   sock_buf);
   }
   
   #ifdef WIN32
  
  
  

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



cvs commit: jakarta-tomcat-connectors/jk/native/common jk_connect.c

2005-02-17 Thread mturk
mturk   2005/02/17 00:26:42

  Modified:jk/native/common jk_connect.c
  Log:
  Remove the CRLFs. Again.
  
  Revision  ChangesPath
  1.42  +14 -14jakarta-tomcat-connectors/jk/native/common/jk_connect.c
  
  Index: jk_connect.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_connect.c,v
  retrieving revision 1.41
  retrieving revision 1.42
  diff -u -r1.41 -r1.42
  --- jk_connect.c  17 Feb 2005 08:10:40 -  1.41
  +++ jk_connect.c  17 Feb 2005 08:26:42 -  1.42
  @@ -71,7 +71,7 @@
   #ifdef HAVE_APR
   apr_sockaddr_t *remote_sa, *temp_sa;
   char *remote_ipaddr;
  -
  +
   if (!jk_apr_pool) {
   if (apr_pool_create(jk_apr_pool, NULL) != APR_SUCCESS)
   return JK_FALSE;
  @@ -197,9 +197,9 @@
   #ifdef WIN32
   if (timeout  0) {
   timeout = timeout * 1000;
  -setsockopt(sock, SOL_SOCKET, SO_RCVTIMEO, 
  +setsockopt(sock, SOL_SOCKET, SO_RCVTIMEO,
  (char *) timeout, sizeof(int));
  -setsockopt(sock, SOL_SOCKET, SO_SNDTIMEO, 
  +setsockopt(sock, SOL_SOCKET, SO_SNDTIMEO,
  (char *) timeout, sizeof(int));
   if (JK_IS_DEBUG_LEVEL(l))
   jk_log(l, JK_LOG_DEBUG,
  @@ -214,13 +214,13 @@
  trying to connect socket %d to %s, sock,
  jk_dump_hinfo(addr, buf));
   
  -/* Need more infos for BSD 4.4 and Unix 98 defines, for now only 
  +/* Need more infos for BSD 4.4 and Unix 98 defines, for now only
   iSeries when Unix98 is required at compil time */
   #if (_XOPEN_SOURCE = 520)  defined(AS400)
   ((struct sockaddr *)addr)-sa_len = sizeof(struct sockaddr_in);
   #endif
   ret = connect(sock, (struct sockaddr *)addr,
  -  sizeof(struct sockaddr_in));
  +  sizeof(struct sockaddr_in));
   #if defined(WIN32) || (defined(NETWARE)  defined(__NOVELL_LIBC__))
   if (ret == SOCKET_ERROR) {
   errno = WSAGetLastError() - WSABASEERR;
  @@ -318,10 +318,10 @@
   if (rd == SOCKET_ERROR)
   errno = WSAGetLastError() - WSABASEERR;
   #else
  -rd = read(sd, (char *)b + rdlen, len - rdlen); 
  +rd = read(sd, (char *)b + rdlen, len - rdlen);
   #endif
   } while (rd == -1  errno == EINTR);
  -
  +
   if (rd == -1)
   return (errno  0) ? -errno : errno;
   else if (rd == 0)
  @@ -403,7 +403,7 @@
   }
   #endif /* WIN32 */
   return 0;
  -} 
  +}
   
   #if defined(WIN32) || (defined(NETWARE)  defined(__NOVELL_LIBC__))
   #define EWOULDBLOCK (WSAEWOULDBLOCK - WSABASEERR)
  @@ -411,8 +411,8 @@
   
   int jk_is_socket_connected(int sd, int timeout)
   {
  -unsigned char test_buffer[1]; 

  -int  rc;
  +unsigned char test_buffer[1];
  +int  rc;
   /* Set socket to nonblocking */
   if ((rc = sononblock(sd)) != 0)
   return (errno  0) ? -errno : errno;
  @@ -423,11 +423,11 @@
   /* Reset socket timeouts if the new timeout differs from the old timeout 
*/
   if (timeout  0) {
   /* Timeouts are in msec, represented as int */
  -setsockopt(sd, SOL_SOCKET, SO_RCVTIMEO, 
  +setsockopt(sd, SOL_SOCKET, SO_RCVTIMEO,
   (char *) timeout, sizeof(int));
  -setsockopt(sd, SOL_SOCKET, SO_SNDTIMEO, 
  +setsockopt(sd, SOL_SOCKET, SO_SNDTIMEO,
   (char *) timeout, sizeof(int));
  -} 
  +}
   #endif
   if (rc == EWOULDBLOCK || rc == -1)
   return 1;
  
  
  

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



cvs commit: jakarta-tomcat-connectors/jk/native/common jk_lb_worker.c

2005-02-17 Thread mturk
mturk   2005/02/17 00:28:41

  Modified:jk/native/common jk_lb_worker.c
  Log:
  Small performance tune for balancers having single worker.
  There is no need to find best worker if there is only one.
  Single worker is used for workers that need full management.
  
  Revision  ChangesPath
  1.58  +20 -2 jakarta-tomcat-connectors/jk/native/common/jk_lb_worker.c
  
  Index: jk_lb_worker.c
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_lb_worker.c,v
  retrieving revision 1.57
  retrieving revision 1.58
  diff -u -r1.57 -r1.58
  --- jk_lb_worker.c17 Feb 2005 07:16:32 -  1.57
  +++ jk_lb_worker.c17 Feb 2005 08:28:41 -  1.58
  @@ -410,7 +410,25 @@
   int r;
   
   JK_TRACE_ENTER(l);
  -if (p-s-sticky_session) {
  +if (p-num_of_workers == 1) {
  +/* No need to find the best worker
  + * if there is a single one
  + */
  +if (p-lb_workers[0].s-in_error_state 
  +!p-lb_workers[0].s-is_disabled) {
  +retry_worker(p-lb_workers[0], p-s-recover_wait_time, l);
  +}
  +if (!p-lb_workers[0].s-in_error_state) {
  +p-lb_workers[0].r = (p-lb_workers[0].s-name[0]);
  +JK_TRACE_EXIT(l);
  +return p-lb_workers[0];
  +}
  +else {
  +JK_TRACE_EXIT(l);
  +return NULL;
  +}
  +}
  +else if (p-s-sticky_session) {
   sessionid = get_sessionid(s);
   }
   JK_ENTER_CS((p-cs), r);
  
  
  

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



cvs commit: jakarta-tomcat-connectors/jk/native/common jk_mt.h

2005-02-17 Thread mturk
mturk   2005/02/17 00:48:14

  Modified:jk/native/common jk_mt.h
  Log:
  If JK_PREFORK is defined  we can exclude all thread locking code
  for prefork servers like apache1 on unixes, etc...
  
  Revision  ChangesPath
  1.17  +10 -2 jakarta-tomcat-connectors/jk/native/common/jk_mt.h
  
  Index: jk_mt.h
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_mt.h,v
  retrieving revision 1.16
  retrieving revision 1.17
  diff -u -r1.16 -r1.17
  --- jk_mt.h   14 Feb 2005 09:45:31 -  1.16
  +++ jk_mt.h   17 Feb 2005 08:48:14 -  1.17
  @@ -37,11 +37,19 @@
* _REENTRANT define.
*/
   #if defined (WIN32) || defined(_REENTRANT) || (defined(NETWARE)  
defined(__NOVELL_LIBC__))
  +#ifdef JK_PREFORK 
  +#define _MT_CODE 0
  +#else
  +#define _MT_CODE 1
  +#endif
  +#else
  +#define _MT_CODE 0
  +#endif
   
   /*
* Marks execution under MT compilation
*/
  -#define _MT_CODE
  +#if _MT_CODE
   #ifdef WIN32
   #include windows.h
   
  
  
  

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



cvs commit: jakarta-tomcat-connectors/jk/native/apache-1.3 Makefile.apxs.in Makefile.in

2005-02-17 Thread mturk
mturk   2005/02/17 00:53:29

  Modified:jk/native/apache-1.3 Makefile.apxs.in Makefile.in
  Log:
  Apache1.3.x is prefork. Add JK_PREFORK define to exclude all
  thread locking code.
  
  Revision  ChangesPath
  1.4   +1 -1  
jakarta-tomcat-connectors/jk/native/apache-1.3/Makefile.apxs.in
  
  Index: Makefile.apxs.in
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/native/apache-1.3/Makefile.apxs.in,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- Makefile.apxs.in  21 Jun 2002 15:22:48 -  1.3
  +++ Makefile.apxs.in  17 Feb 2005 08:53:29 -  1.4
  @@ -7,7 +7,7 @@
   [EMAIL PROTECTED]@
   
   JK=../common/
  -JK_INCL=-DUSE_APACHE_MD5 -I ${JK}
  +JK_INCL=-DUSE_APACHE_MD5 -DJK_PREFORK -I ${JK}
   JAVA_INCL=-I ${JAVA_HOME}/include -I ${JAVA_HOME}/include/${OS}
   JAVA_LIB=-L ${JAVA_HOME}/jre/lib/${ARCH} -L 
${JAVA_HOME}/lib/${ARCH}/native_threads
   
  
  
  
  1.12  +1 -1  
jakarta-tomcat-connectors/jk/native/apache-1.3/Makefile.in
  
  Index: Makefile.in
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/native/apache-1.3/Makefile.in,v
  retrieving revision 1.11
  retrieving revision 1.12
  diff -u -r1.11 -r1.12
  --- Makefile.in   20 Jan 2005 07:14:11 -  1.11
  +++ Makefile.in   17 Feb 2005 08:53:29 -  1.12
  @@ -25,7 +25,7 @@
   APACHE_FILES = Makefile.tmpl Makefile.libdir libjk.module
   
   JK=../common/
  -JK_INCL=-DUSE_APACHE_MD5 -I ${top_srcdir}/common
  +JK_INCL=-DUSE_APACHE_MD5 -DJK_PREFORK -I ${top_srcdir}/common
   JAVA_INCL=-I ${JAVA_HOME}/include -I ${JAVA_HOME}/include/${OS}
   JAVA_LIB=-L ${JAVA_HOME}/jre/lib/${ARCH} -L 
${JAVA_HOME}/lib/${ARCH}/native_threads
   [EMAIL PROTECTED]@ @APXSCFLAGS@ @APXSCPPFLAGS@ -I${top_srcdir}/common
  
  
  

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



cvs commit: jakarta-tomcat-connectors/jk/native/apache-1.3 Makefile.apxs.in Makefile.in

2005-02-17 Thread mturk
mturk   2005/02/17 01:11:31

  Modified:jk/native/apache-1.3 Makefile.apxs.in Makefile.in
  Log:
  Revert -DJ_PREFORK define. It can be used simply by
  'CFLAGS=-DJK_PREFORK  ./configure ...'
  
  Revision  ChangesPath
  1.5   +1 -1  
jakarta-tomcat-connectors/jk/native/apache-1.3/Makefile.apxs.in
  
  Index: Makefile.apxs.in
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/native/apache-1.3/Makefile.apxs.in,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- Makefile.apxs.in  17 Feb 2005 08:53:29 -  1.4
  +++ Makefile.apxs.in  17 Feb 2005 09:11:31 -  1.5
  @@ -7,7 +7,7 @@
   [EMAIL PROTECTED]@
   
   JK=../common/
  -JK_INCL=-DUSE_APACHE_MD5 -DJK_PREFORK -I ${JK}
  +JK_INCL=-DUSE_APACHE_MD5 -I ${JK}
   JAVA_INCL=-I ${JAVA_HOME}/include -I ${JAVA_HOME}/include/${OS}
   JAVA_LIB=-L ${JAVA_HOME}/jre/lib/${ARCH} -L 
${JAVA_HOME}/lib/${ARCH}/native_threads
   
  
  
  
  1.13  +1 -1  
jakarta-tomcat-connectors/jk/native/apache-1.3/Makefile.in
  
  Index: Makefile.in
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/native/apache-1.3/Makefile.in,v
  retrieving revision 1.12
  retrieving revision 1.13
  diff -u -r1.12 -r1.13
  --- Makefile.in   17 Feb 2005 08:53:29 -  1.12
  +++ Makefile.in   17 Feb 2005 09:11:31 -  1.13
  @@ -25,7 +25,7 @@
   APACHE_FILES = Makefile.tmpl Makefile.libdir libjk.module
   
   JK=../common/
  -JK_INCL=-DUSE_APACHE_MD5 -DJK_PREFORK -I ${top_srcdir}/common
  +JK_INCL=-DUSE_APACHE_MD5 -I ${top_srcdir}/common
   JAVA_INCL=-I ${JAVA_HOME}/include -I ${JAVA_HOME}/include/${OS}
   JAVA_LIB=-L ${JAVA_HOME}/jre/lib/${ARCH} -L 
${JAVA_HOME}/lib/${ARCH}/native_threads
   [EMAIL PROTECTED]@ @APXSCFLAGS@ @APXSCPPFLAGS@ -I${top_srcdir}/common
  
  
  

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



cvs commit: jakarta-tomcat-connectors/jk/native/common jk_lb_worker.c jk_status.c

2005-02-17 Thread mturk
mturk   2005/02/17 01:12:24

  Modified:jk/native/common jk_lb_worker.c jk_status.c
  Log:
  Remove unused variables. No functional change.
  
  Revision  ChangesPath
  1.59  +1 -3  jakarta-tomcat-connectors/jk/native/common/jk_lb_worker.c
  
  Index: jk_lb_worker.c
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_lb_worker.c,v
  retrieving revision 1.58
  retrieving revision 1.59
  diff -u -r1.58 -r1.59
  --- jk_lb_worker.c17 Feb 2005 08:28:41 -  1.58
  +++ jk_lb_worker.c17 Feb 2005 09:12:24 -  1.59
  @@ -406,7 +406,6 @@
   {
   worker_record_t *rc = NULL;
   char *sessionid = NULL;
  -int domain_id = -1;
   int r;
   
   JK_TRACE_ENTER(l);
  @@ -672,7 +671,6 @@
 worker_names,
 num_of_workers)  num_of_workers) {
   unsigned int i = 0;
  -unsigned int j = 0;
   
   p-lb_workers = jk_pool_alloc(p-p,
 num_of_workers *
  
  
  
  1.16  +1 -5  jakarta-tomcat-connectors/jk/native/common/jk_status.c
  
  Index: jk_status.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_status.c,v
  retrieving revision 1.15
  retrieving revision 1.16
  diff -u -r1.15 -r1.16
  --- jk_status.c   16 Feb 2005 11:24:39 -  1.15
  +++ jk_status.c   17 Feb 2005 09:12:24 -  1.16
  @@ -392,7 +392,6 @@
   jk_puts(s, /tablebr /\n);
   if (selected = 0) {
   worker_record_t *wr = (lb-lb_workers[selected]);
  -ajp_worker_t *a = (ajp_worker_t *)wr-w-worker_private;
   jk_putv(s, hr /h3Edit worker settings for ,
   wr-s-name, /h3\n, NULL);
   jk_putv(s, form method=\GET\ action=\,
  @@ -635,9 +634,6 @@
   JK_TRACE_ENTER(l);
   
   if (pThis  pThis-worker_private) {
  -status_worker_t *p = pThis-worker_private;
  -
  -
   JK_TRACE_EXIT(l);
   return JK_TRUE;
   }
  
  
  

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



Progress with Jk-dev

2005-02-17 Thread NormW
Greetings All,
Have the mod_jk 1.2.9-dev up and running on NetWare 6 and AP 2.1.3 but 
doing much beyond a single worker is a little awkward. I can access the 
Tomcat html manager web app without visible issues.

When I access the /admin/ app a few 'odd' things happen..like some icons 
aren't displayed until a refresh... and if you try to go to 'lower' 
contexts within the left 'menu', the left pane changes to 'Service 
Temporarily Unavailable', while the right pane shows the requested data.

Beyond that, the status page displays without issue, although some data 
alignment under their headings would be 'nice'...

The current build includes but the 11 most recent patches.
Happy developing,
Norm
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Progress with Jk-dev

2005-02-17 Thread Mladen Turk
NormW wrote:
Greetings All,
Have the mod_jk 1.2.9-dev up and running on NetWare 6 and AP 2.1.3 but 
doing much beyond a single worker is a little awkward. I can access the 
Tomcat html manager web app without visible issues.
1. Did you include the latest jk_ajp_common.c (Revision: 1.85).
   There was a bug in previous patch, causing endpoint corruption.
2. Can you check if the _MT_CODE is compiled in.
   I'm not sure what '(defined(NETWARE)  defined(__NOVELL_LIBC__))'
   inside jk_mt.h actually means. Does it have pthreads.h included?
   It won't work without some thread locking.
Also why would one wish to build on 2.1.3?
You have mod_proxy_ajp for that already in the core :).
Regards,
Mladen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


[GUMP@brutus]: Project jakarta-tomcat-jk-native (in module jakarta-tomcat-connectors) failed

2005-02-17 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 21 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://brutus.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://brutus.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: 
Command Line: make 
[Working Directory: 
/usr/local/gump/public/workspace/jakarta-tomcat-connectors/jk/native]
-
Making all in common
make[1]: Entering directory 
`/home/gump/workspaces2/public/workspace/jakarta-tomcat-connectors/jk/native/common'
/bin/sh 
/usr/local/gump/public/workspace/apache-httpd/dest-17022005/build/libtool 
--silent --mode=compile gcc 
-I/usr/local/gump/public/workspace/apache-httpd/dest-17022005/include -g -O2 -g 
-O2 -pthread -DHAVE_APR 
-I/usr/local/gump/public/workspace/apr/dest-17022005/include/apr-1 -g -O2 
-DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE 
-I/home/gump/workspaces2/public/workspace/apache-httpd/srclib/pcre -I 
/opt/jdk1.4/include -I /opt/jdk1.4/include/ -c jk_ajp12_worker.c 
/usr/local/gump/public/workspace/apache-httpd/dest-17022005/build/libtool: 
/usr/local/gump/public/workspace/apache-httpd/dest-17022005/build/libtool: No 
such file or directory
make[1]: *** [jk_ajp12_worker.lo] Error 127
make[1]: Leaving directory 
`/home/gump/workspaces2/public/workspace/jakarta-tomcat-connectors/jk/native/common'
make: *** [all-recursive] Error 1
-

To subscribe to this information via syndicated feeds:
- RSS: 
http://brutus.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native/rss.xml
- Atom: 
http://brutus.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native/atom.xml

== Gump Tracking Only ===
Produced by Gump version 2.2.
Gump Run 2717022005, brutus:brutus-public:2717022005
Gump E-mail Identifier (unique within run) #12.

--
Apache Gump
http://gump.apache.org/ [Instance: brutus]

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



Re: Progress with Jk-dev

2005-02-17 Thread NormW
Greetings again...
Mladen Turk wrote:
NormW wrote:
1. Did you include the latest jk_ajp_common.c (Revision: 1.85). There
was a bug in previous patch, causing endpoint corruption. 2. Can you
check if the _MT_CODE is compiled in. I'm not sure what
'(defined(NETWARE)  defined(__NOVELL_LIBC__))' inside jk_mt.h
actually means. Does it have pthreads.h included? It won't work
without some thread locking.
The defined NETWARE applies to AP 1.3 and 2.x but _NOVELL_LIBC_ is the 
method for identifying AP2 AFAIK.
The Novell LibC NDK includes pthread.h, so expect it is using it.

Just built the mod_jk using the last 8 or so patches, and without 
changing any settings now get 'internal server error' for both /admin/ 
and /manager/html/...
Also why would one wish to build on 2.1.3? You have mod_proxy_ajp for
that already in the core :).
Kill multiple stones with a single bird. I rarely get time to do more 
than build 2.1 so this tries both, and its design is the future soon we 
hope...  :-)
Regards, Mladen
Regards,
Norm
-
 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: Progress with Jk-dev

2005-02-17 Thread Mladen Turk
NormW wrote:
The defined NETWARE applies to AP 1.3 and 2.x but _NOVELL_LIBC_ is the 
method for identifying AP2 AFAIK.
The Novell LibC NDK includes pthread.h, so expect it is using it.

Can you be sure it is included?
Add some #pragma before #include pthread.h

Just built the mod_jk using the last 8 or so patches, and without 
changing any settings now get 'internal server error' for both /admin/ 
and /manager/html/...

Great. Could you set the JkLogLevel to 'trace'.
Open a clean log and hit the /admin.
That's all that I need. Can you post that log?
Netware is the only platfrom I don't have, so it's hard
to debug :).
Regards,
Mladen.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


DO NOT REPLY [Bug 25095] - The code generated by jsp:plugin is not suitable for XHTML

2005-02-17 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=25095.
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=25095


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |




--- Additional Comments From [EMAIL PROTECTED]  2005-02-17 11:16 ---
1. That is correct, JSP spec does not require to support XHTML, but id doesn't
forbid that either. I don't think it is reasonable to abandon other relevant
(for web develoers at least) specifications just because JSP does not require to
support those. Since valid XHTML is usually valid HTML I think that no one would
lose anything if the suggested changes were implemented. But of course, that is
your decision.
2. As you can see from the original bug report the generated HTML is not really
valid either (the tags are nested improperly). I hope you agree that this
deserves to be fixed (that's why I've reopened this bug).
3. Another thing I'd like to mention (although a bit off topic) that
EMBED/NOEMBED is anachronism, which may be needed only for very old browsers,
which are most likely to be installed on very old PCs with very old OS and very
old JRE (if any) so there is a big chance that the applet wouldn't run there
anyway. And I believe that web developer must be able to choose whether to
support ancient browsers or to adhere to the standards, otherwise it would
render jsp:plugin useless, which is what seems to be happening since no one 
cares.

-- 
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 33589] - stop a context without interrupting its running threads

2005-02-17 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33589.
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=33589





--- Additional Comments From [EMAIL PROTECTED]  2005-02-17 11:47 ---
I agree : you are free to refuse any new feature.

I read your comment but I thought that, instead of implementing a wait in the
destroy of all my servlets, it would be better to solve this within the
application server.

use of the pause operation on the connectors : what do you mean ? (I find
nothing in the docs :-( 
I use apache with mod_jk for load_balance and failover but I don't know the
pause operation...Do you have a doc link for this ?


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



cvs commit: jakarta-tomcat-connectors/jk/native/common jk_lb_worker.c

2005-02-17 Thread mturk
mturk   2005/02/17 04:29:00

  Modified:jk/native/common jk_lb_worker.c
  Log:
  Change some log messages. No functional change.
  
  Revision  ChangesPath
  1.60  +5 -2  jakarta-tomcat-connectors/jk/native/common/jk_lb_worker.c
  
  Index: jk_lb_worker.c
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_lb_worker.c,v
  retrieving revision 1.59
  retrieving revision 1.60
  diff -u -r1.59 -r1.60
  --- jk_lb_worker.c17 Feb 2005 09:12:24 -  1.59
  +++ jk_lb_worker.c17 Feb 2005 12:29:00 -  1.60
  @@ -433,7 +433,7 @@
   JK_ENTER_CS((p-cs), r);
   if (!r) {
  jk_log(l, JK_LOG_ERROR,
  -  getting thread lock errno=%d,
  +  locking thread with errno=%d,
 errno);
   JK_TRACE_EXIT(l);
   return NULL;
  @@ -766,6 +766,9 @@
   
   JK_INIT_CS((p-cs), i);
   if (i == JK_FALSE) {
  +jk_log(log, JK_LOG_ERROR,
  +   creating thread lock errno=%d,
  +   errno);
   JK_TRACE_EXIT(log);
   return JK_FALSE;
   }
  
  
  

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



cvs commit: jakarta-tomcat-connectors/jk/native/common jk_ajp_common.c

2005-02-17 Thread mturk
mturk   2005/02/17 04:32:16

  Modified:jk/native/common jk_ajp_common.c
  Log:
  Create separate function for creating the entire endpoint cache.
  It is just a way to make the code more readable.
  
  Revision  ChangesPath
  1.86  +62 -49
jakarta-tomcat-connectors/jk/native/common/jk_ajp_common.c
  
  Index: jk_ajp_common.c
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_ajp_common.c,v
  retrieving revision 1.85
  retrieving revision 1.86
  diff -u -r1.85 -r1.86
  --- jk_ajp_common.c   17 Feb 2005 07:14:19 -  1.85
  +++ jk_ajp_common.c   17 Feb 2005 12:32:16 -  1.86
  @@ -1780,21 +1780,45 @@
   return JK_FALSE;
   }
   
  -static ajp_endpoint_t *ajp_create_endpoint(jk_worker_t *w, int proto, time_t 
now)
  +static int ajp_create_endpoint_cache(ajp_worker_t *p, int proto, jk_logger_t 
*l)
   {
  -ajp_endpoint_t *ae = (ajp_endpoint_t *)calloc(1, sizeof(ajp_endpoint_t));
  -if (ae) {
  -ae-sd = -1;
  -ae-reuse = JK_FALSE;
  -ae-last_access = now;
  -jk_open_pool(ae-pool, ae-buf, sizeof(ae-buf));
  -ae-worker = w-worker_private;
  -ae-endpoint.endpoint_private = ae;
  -ae-proto = proto;
  -ae-endpoint.service = ajp_service;
  -ae-endpoint.done = ajp_done;
  +unsigned int i;
  +time_t now = time(NULL);
  +
  +JK_TRACE_ENTER(l);
  +p-ep_cache = (ajp_endpoint_t **)calloc(1, sizeof(ajp_endpoint_t *) *
  +p-ep_cache_sz);
  +if (!p-ep_cache) {
  +JK_TRACE_EXIT(l);
  +return JK_FALSE;
   }
  -return ae;
  +if (JK_IS_DEBUG_LEVEL(l))
  +jk_log(l, JK_LOG_DEBUG,
  +setting connection cache size to %d,
  +p-ep_cache_sz);
  +for (i = 0; i  p-ep_cache_sz; i++) {
  +p-ep_cache[i] = (ajp_endpoint_t *)calloc(1, 
sizeof(ajp_endpoint_t));
  +if (!p-ep_cache[i]) {
  +jk_log(l, JK_LOG_ERROR,
  +creating endpont cache slot %d errno=%d,
  +i, errno);
  +JK_TRACE_EXIT(l);
  +return JK_FALSE;
  +}
  +p-ep_cache[i]-sd = -1;
  +p-ep_cache[i]-reuse = JK_FALSE;
  +p-ep_cache[i]-last_access = now;
  +jk_open_pool((p-ep_cache[i]-pool), p-ep_cache[i]-buf,
  + sizeof(p-ep_cache[i]-buf));
  +p-ep_cache[i]-worker = p;
  +p-ep_cache[i]-endpoint.endpoint_private = p-ep_cache[i];
  +p-ep_cache[i]-proto = proto;
  +p-ep_cache[i]-endpoint.service = ajp_service;
  +p-ep_cache[i]-endpoint.done= ajp_done;
  +}
  +
  +JK_TRACE_EXIT(l);
  +return JK_TRUE;
   }
   
   int ajp_init(jk_worker_t *pThis,
  @@ -1903,40 +1927,16 @@
   
   p-secret = jk_get_worker_secret(props, p-name);
   p-ep_mincache_sz = 1;
  -p-ep_cache = (ajp_endpoint_t **)calloc(1, sizeof(ajp_endpoint_t *) *
  -p-ep_cache_sz);
  -if (p-ep_cache) {
  -unsigned int i;
  -time_t now = time(NULL);
  -
  -if (JK_IS_DEBUG_LEVEL(l))
  -jk_log(l, JK_LOG_DEBUG,
  -setting connection cache size to %d,
  -p-ep_cache_sz);
  -/* Initialize cache slots */
  -for (i = 0; i  p-ep_cache_sz; i++) {
  -p-ep_cache[i] = ajp_create_endpoint(pThis, proto, now);
  -if (!p-ep_cache[i]) {
  -jk_log(l, JK_LOG_ERROR,
  -creating endpont cache slot %d errno=%d,
  -i, errno);
  -JK_TRACE_EXIT(l);
  -return JK_FALSE;
  -}
  -jk_log(l, JK_LOG_DEBUG,
  -Initialized endpont cache slot %d %#lx:%#lx,
  -i, p-ep_cache[i], (p-ep_cache[i]-pool));
  -}
  -JK_INIT_CS((p-cs), i);
  -if (i == JK_FALSE) {
  -jk_log(l, JK_LOG_ERROR,
  -   creating thread lock errno=%d,
  -   errno);
  -JK_TRACE_EXIT(l);
  -return JK_FALSE;
  -}
  +/* Initialize cache slots */
  +JK_INIT_CS((p-cs), rc);
  +if (!rc) {
  +jk_log(l, JK_LOG_ERROR,
  +   creating thread lock errno=%d,
  +   errno);
  +JK_TRACE_EXIT(l);
  +return JK_FALSE;
   }
  -else {
  +if (!ajp_create_endpoint_cache(p, proto, l)) {
   jk_log(l, JK_LOG_ERROR,
  allocating ep_cache of size %d,
  p-ep_cache_sz);
  @@ -2046,8 +2046,12 @@
   if 

cvs commit: jakarta-tomcat-connectors/jk/native/common jk_ajp_common.c

2005-02-17 Thread mturk
mturk   2005/02/17 04:40:55

  Modified:jk/native/common jk_ajp_common.c
  Log:
  Close socket outside critical section. Closing sockets can take a while,
  so no need to lock all the threads.
  
  Revision  ChangesPath
  1.87  +11 -4 
jakarta-tomcat-connectors/jk/native/common/jk_ajp_common.c
  
  Index: jk_ajp_common.c
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_ajp_common.c,v
  retrieving revision 1.86
  retrieving revision 1.87
  diff -u -r1.86 -r1.87
  --- jk_ajp_common.c   17 Feb 2005 12:32:16 -  1.86
  +++ jk_ajp_common.c   17 Feb 2005 12:40:54 -  1.87
  @@ -724,12 +724,12 @@
   {
   int rc;
   ajp_worker_t *aw = ae-worker;
  +int sock = ae-sd;
   
   JK_ENTER_CS(aw-cs, rc);
   if (rc) {
   unsigned int i;
   /* Close existing endpoint socket */
  -jk_close_socket(ae-sd);
   ae-sd = -1;
   for (i = 0; i  aw-ep_cache_sz; i++) {
   /* Find cache slot with usable socket */
  @@ -741,6 +741,7 @@
   }
   JK_LEAVE_CS(aw-cs, rc);
   }
  +jk_close_socket(sock);
   }
   
   /*
  @@ -2002,8 +2003,12 @@
   
   JK_ENTER_CS(w-cs, rc);
   if (rc) {
  -int i;
  -
  +int i, sock = -1;
  +
  +if (p-sd  0  !p-reuse) {
  +sock  = p-sd;
  +p-sd = -1;
  +}
   for(i = w-ep_cache_sz - 1; i = 0; i--) {
   if (w-ep_cache[i] == NULL) {
   w-ep_cache[i] = p;
  @@ -2013,6 +2018,8 @@
   }
   *e = NULL;
   JK_LEAVE_CS(w-cs, rc);
  +if (sock = 0)
  +jk_close_socket(sock);
   if (i = 0) {
   if (JK_IS_DEBUG_LEVEL(l))
   jk_log(l, JK_LOG_DEBUG,
  
  
  

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



JK 1.2.9-dev test results

2005-02-17 Thread Mladen Turk
Hi,
Henri said that he noticed current dev version
of mod_jk being quite faster then previous (1.2.8).
Although it was not the primary intention to
be faster, I think no one will object :).
So here are some benchmark results from my side:
JK 1.2.8 single thread
Requests per second:784.31 [#/sec] (mean)
JK 1.2.9-dev single thread
Requests per second:798.01 [#/sec] (mean)
JK 1.2.9-dev 10 concurrent threads
Requests per second:918.22 [#/sec] (mean)
JK 1.2.9-dev 10 concurrent threads with socket_timeout
Requests per second:910.38 [#/sec] (mean)
So. Is this a speedup or not ;)?
Interesting is that new socket_timeout implementation
does not slow down that much. After all it sets the
socket to nonblocking mode before each request, checks if
the socket is still connected and then sets to blocking mode again.
Compared to cping/cpong prepost, the system is almost twice
as faster. Of course it will not detect hanged tomcat,
only if tomcat broke down or some other network problem
happened.
Cheers,
Mladen.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


cvs commit: jakarta-tomcat-connectors/jk/native/common jk_ajp_common.c

2005-02-17 Thread mturk
mturk   2005/02/17 05:25:36

  Modified:jk/native/common jk_ajp_common.c
  Log:
  Check if socket is connected before prepost cping/cpong.
  If the socket is not connected it will fail anyhow.
  
  Revision  ChangesPath
  1.88  +14 -10
jakarta-tomcat-connectors/jk/native/common/jk_ajp_common.c
  
  Index: jk_ajp_common.c
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_ajp_common.c,v
  retrieving revision 1.87
  retrieving revision 1.88
  diff -u -r1.87 -r1.88
  --- jk_ajp_common.c   17 Feb 2005 12:40:54 -  1.87
  +++ jk_ajp_common.c   17 Feb 2005 13:25:36 -  1.88
  @@ -843,8 +843,9 @@
  connected sd = %d to %s,
  ae-sd, jk_dump_hinfo(ae-worker-worker_inet_addr, 
buf));
   
  -/* set last_access */
  -ae-last_access = time(NULL);
  +/* set last_access only if needed */
  +if (ae-worker-cache_timeout  0 || ae-worker-recycle_timeout 
 0)
  +ae-last_access = time(NULL);
   if (ae-worker-socket_timeout) {
   int rc = 0;
   if ((rc = jk_is_socket_connected(ae-sd, 
ae-worker-socket_timeout)) != 1) {
  @@ -1159,13 +1160,7 @@
*/
   while ((ae-sd  0)) {
   err = 0;
  -/* handle cping/cpong before request if timeout is set */
  -if (ae-worker-prepost_timeout != 0) {
  -if (ajp_handle_cping_cpong(ae, ae-worker-prepost_timeout, l) ==
  -JK_FALSE)
  -err++;
  -}
  -else if (ae-worker-socket_timeout) {
  +if (ae-worker-socket_timeout) {
   int rc = 0;
   if ((rc = jk_is_socket_connected(ae-sd, 
ae-worker-socket_timeout)) != 1) {
   jk_log(l, JK_LOG_INFO,
  @@ -1175,6 +1170,15 @@
   err++;
   }
   }
  +else if (ae-worker-prepost_timeout != 0  !err) {
  +/* handle cping/cpong if prepost_timeout is set
  + * If the socket is disconnected no need to handle
  + * the cping/cpong
  + */
  +if (ajp_handle_cping_cpong(ae, ae-worker-prepost_timeout, l) ==
  +JK_FALSE)
  +err++;
  +}
   
   /* If we got an error or can't send data, then try to get a pooled
* connection and try again.  If we are succesful, break out of this
  
  
  

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



cvs commit: jakarta-tomcat-connectors/jk/native/common jk_ajp_common.c

2005-02-17 Thread mturk
mturk   2005/02/17 05:29:19

  Modified:jk/native/common jk_ajp_common.c
  Log:
  Make sure that both network detection and cping/cpong can occur.
  
  Revision  ChangesPath
  1.89  +2 -2  
jakarta-tomcat-connectors/jk/native/common/jk_ajp_common.c
  
  Index: jk_ajp_common.c
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_ajp_common.c,v
  retrieving revision 1.88
  retrieving revision 1.89
  diff -u -r1.88 -r1.89
  --- jk_ajp_common.c   17 Feb 2005 13:25:36 -  1.88
  +++ jk_ajp_common.c   17 Feb 2005 13:29:19 -  1.89
  @@ -1170,7 +1170,7 @@
   err++;
   }
   }
  -else if (ae-worker-prepost_timeout != 0  !err) {
  +if (ae-worker-prepost_timeout != 0  !err) {
   /* handle cping/cpong if prepost_timeout is set
* If the socket is disconnected no need to handle
* the cping/cpong
  
  
  

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



cvs commit: jakarta-tomcat-connectors/jk/native/common jk_lb_worker.c jk_status.c

2005-02-17 Thread mturk
mturk   2005/02/17 05:41:04

  Modified:jk/native/common jk_lb_worker.c jk_status.c
  Log:
  Display the number of workers currently serving requests.
  
  Revision  ChangesPath
  1.61  +6 -2  jakarta-tomcat-connectors/jk/native/common/jk_lb_worker.c
  
  Index: jk_lb_worker.c
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_lb_worker.c,v
  retrieving revision 1.60
  retrieving revision 1.61
  diff -u -r1.60 -r1.61
  --- jk_lb_worker.c17 Feb 2005 12:29:00 -  1.60
  +++ jk_lb_worker.c17 Feb 2005 13:41:04 -  1.61
  @@ -547,12 +547,16 @@
   /* Reset endpoint read and write sizes for
* this request.
*/
  -end-rd = end-wr = 0;
  +end-rd = end-wr = 0;
  +/* Increment the number of workers serving request */
  +p-worker-s-busy++;
   service_ok = end-service(end, s, l, is_service_error);
   /* Update partial reads and writes if any */
   rec-s-readed += end-rd;
   rec-s-transferred += end-wr;
   end-done(end, l);
  +/* Decrement the busy worker count */
  +p-worker-s-busy--;
   if (service_ok) {
   rec-s-in_error_state = JK_FALSE;
   rec-s-in_recovering = JK_FALSE;
  
  
  
  1.17  +3 -2  jakarta-tomcat-connectors/jk/native/common/jk_status.c
  
  Index: jk_status.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_status.c,v
  retrieving revision 1.16
  retrieving revision 1.17
  diff -u -r1.16 -r1.17
  --- jk_status.c   17 Feb 2005 09:12:24 -  1.16
  +++ jk_status.c   17 Feb 2005 13:41:04 -  1.17
  @@ -356,7 +356,7 @@
   jk_puts(s, table border=\0\tr
   thName/ththType/ththHost/ththAddr/th
   
thStat/ththF/ththV/ththAcc/ththErr/th
  -thWr/ththRd/ththRR/ththCd/th/tr\n);
  +
thWr/ththRd/ththBusy/ththRR/ththCd/th/tr\n);
   for (j = 0; j  lb-num_of_workers; j++) {
   worker_record_t *wr = (lb-lb_workers[j]);
   ajp_worker_t *a = (ajp_worker_t *)wr-w-worker_private;
  @@ -384,6 +384,7 @@
   /td, NULL);
   jk_putv(s, td, status_strfsize(wr-s-readed, buf),
   /tdtd, NULL);
  +jk_printf(s, td%u/td, wr-s-busy);
   jk_puts(s, wr-s-redirect);
   jk_puts(s, /tdtd\n);
   jk_puts(s, wr-s-domain);
  
  
  

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



cvs commit: jakarta-tomcat-connectors/jk/native/common jk_lb_worker.c

2005-02-17 Thread mturk
mturk   2005/02/17 05:48:47

  Modified:jk/native/common jk_lb_worker.c
  Log:
  Update number of used endpoinds for each elected worker.
  
  Revision  ChangesPath
  1.62  +3 -1  jakarta-tomcat-connectors/jk/native/common/jk_lb_worker.c
  
  Index: jk_lb_worker.c
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_lb_worker.c,v
  retrieving revision 1.61
  retrieving revision 1.62
  diff -u -r1.61 -r1.62
  --- jk_lb_worker.c17 Feb 2005 13:41:04 -  1.61
  +++ jk_lb_worker.c17 Feb 2005 13:48:47 -  1.62
  @@ -550,12 +550,14 @@
   end-rd = end-wr = 0;
   /* Increment the number of workers serving request */
   p-worker-s-busy++;
  +rec-s-busy++;
   service_ok = end-service(end, s, l, is_service_error);
   /* Update partial reads and writes if any */
   rec-s-readed += end-rd;
   rec-s-transferred += end-wr;
   end-done(end, l);
   /* Decrement the busy worker count */
  +rec-s-busy--;
   p-worker-s-busy--;
   if (service_ok) {
   rec-s-in_error_state = JK_FALSE;
  
  
  

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



DO NOT REPLY [Bug 33621] New: - java.lang.IllegalStateException with tomcat 5.5.4

2005-02-17 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33621.
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=33621

   Summary: java.lang.IllegalStateException with tomcat 5.5.4
   Product: Tomcat 5
   Version: 5.5.4
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: normal
  Priority: P2
 Component: Unknown
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


java.lang.IllegalStateException: getAttribute: Session already invalidated
at org.apache.catalina.session.StandardSession.getAttribute
(StandardSession.java:984)
at org.apache.catalina.session.StandardSessionFacade.getAttribute
(StandardSessionFacade.java:109)
at gnu.beanfactory.SessionScope.get(Unknown Source)
at gnu.beanfactory.BeanFactory.findInstance(Unknown Source)
at gnu.beanfactory.BeanFactory.getObjectInstance(Unknown Source)
at gnu.beanfactory.BeanFactory.getObjectInstance(Unknown Source)
at gnu.beanfactory.BeanContext.lookup(Unknown Source)
at gnu.beanfactory.BeanContext.lookup(Unknown Source)
at org.apache.jsp.include.nav_jsp.checkAccess
(org.apache.jsp.include.nav_jsp:62)
at org.apache.jsp.include.nav_jsp._jspService
(org.apache.jsp.include.nav_jsp:1601)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:99)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at org.apache.jasper.servlet.JspServletWrapper.service
(JspServletWrapper.java:325)
at org.apache.jasper.servlet.JspServlet.serviceJspFile
(JspServlet.java:295)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:245)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
(ApplicationFilterChain.java:237)
at org.apache.catalina.core.ApplicationFilterChain.doFilter
(ApplicationFilterChain.java:157)
at org.apache.catalina.core.StandardWrapperValve.invoke
(StandardWrapperValve.java:214)
at org.apache.catalina.core.StandardContextValve.invoke
(StandardContextValve.java:178)
at org.apache.catalina.core.StandardHostValve.invoke
(StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke
(ErrorReportValve.java:105)
at org.apache.catalina.valves.AccessLogValve.invoke
(AccessLogValve.java:526)
at org.apache.catalina.core.StandardEngineValve.invoke
(StandardEngineValve.java:107)
at org.apache.catalina.connector.CoyoteAdapter.service
(CoyoteAdapter.java:148)
at org.apache.jk.server.JkCoyoteHandler.invoke
(JkCoyoteHandler.java:300)
at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:383)
at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:743)
at org.apache.jk.common.ChannelSocket.processConnection
(ChannelSocket.java:675)
at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:866)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run
(ThreadPool.java:684)
at java.lang.Thread.run(Thread.java:595)

-- 
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 33621] - java.lang.IllegalStateException with tomcat 5.5.4

2005-02-17 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33621.
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=33621


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID




--- Additional Comments From [EMAIL PROTECTED]  2005-02-17 15:29 ---
Please post more information to your original tomcat-user question

http://marc.theaimsgroup.com/?l=tomcat-userm=110862079820045w=2

http://jakarta.apache.org/tomcat/faq/misc.html#illegalstate

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



cvs commit: jakarta-tomcat-connectors/jk/native/netscape jk_nsapi_plugin.c

2005-02-17 Thread mturk
mturk   2005/02/17 07:03:15

  Modified:jk/native/apache-1.3 mod_jk.c
   jk/native/apache-2.0 mod_jk.c
   jk/native/common jk_shm.c jk_shm.h
   jk/native/iis jk_isapi_plugin.c
   jk/native/netscape jk_nsapi_plugin.c
  Log:
  Add option to set shared memory size. In general the 1MB shuld
  be more then enoug. But if some has more then 2700 workers and
  uri mappings that might be the limiting factor.
  
  Revision  ChangesPath
  1.70  +25 -2 jakarta-tomcat-connectors/jk/native/apache-1.3/mod_jk.c
  
  Index: mod_jk.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/apache-1.3/mod_jk.c,v
  retrieving revision 1.69
  retrieving revision 1.70
  diff -u -r1.69 -r1.70
  --- mod_jk.c  16 Feb 2005 15:09:20 -  1.69
  +++ mod_jk.c  17 Feb 2005 15:03:15 -  1.70
  @@ -173,6 +173,7 @@
   static jk_logger_t *main_log = NULL;
   static jk_worker_env_t worker_env;
   static char *jk_shm_file = NULL;
  +static size_t jk_shm_size = JK_SHM_DEF_SIZE;
   
   static int JK_METHOD ws_start_response(jk_ws_service_t *s,
  int status,
  @@ -853,6 +854,26 @@
   }
   
   /*
  + * JkShmSize Directive Handling
  + *
  + * JkShmSize size in kilobytes
  + */
  +
  +static const char *jk_set_shm_size(cmd_parms * cmd,
  +   void *dummy, const char *shm_size)
  +{
  +int sz = 0;
  +/* we need an absolute path */
  +sz = atoi(shm_size) * 1024;
  +if (sz  JK_SHM_DEF_SIZE)
  +sz = JK_SHM_DEF_SIZE;
  +else
  +sz = JK_SHM_ALIGN(sz);
  +jk_shm_size = (size_t)sz;
  +return NULL;
  +}
  +
  +/*
* JkLogLevel Directive Handling
*
* JkLogLevel debug/info/request/error/emerg
  @@ -1534,6 +1555,8 @@
Full path to the Jakarta mod_jk module log file},
   {JkShmFile, jk_set_shm_file, NULL, RSRC_CONF, TAKE1,
Full path to the Jakarta mod_jk module shared memory file},
  +{JkShmSize, jk_set_shm_size, NULL, RSRC_CONF, TAKE1,
  + Size of the shared memory file in KBytes},
   {JkLogLevel, jk_set_log_level, NULL, RSRC_CONF, TAKE1,
The Jakarta mod_jk module log level, can be debug, info, request, 
error, or emerg},
   {JkLogStampFormat, jk_set_log_fmt, NULL, RSRC_CONF, TAKE1,
  @@ -1909,7 +1932,7 @@
   }
   }
   
  -if ((rc = jk_shm_open(jk_shm_file, conf-log)) == 0) {
  +if ((rc = jk_shm_open(jk_shm_file, jk_shm_size, conf-log)) == 0) {
   if (JK_IS_DEBUG_LEVEL(conf-log))
   jk_log(conf-log, JK_LOG_DEBUG, Initialized shm:%s,
  jk_shm_name(), rc);
  
  
  
  1.127 +27 -3 jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c
  
  Index: mod_jk.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c,v
  retrieving revision 1.126
  retrieving revision 1.127
  diff -u -r1.126 -r1.127
  --- mod_jk.c  16 Feb 2005 15:09:20 -  1.126
  +++ mod_jk.c  17 Feb 2005 15:03:15 -  1.127
  @@ -190,6 +190,7 @@
   static jk_worker_env_t worker_env;
   static apr_global_mutex_t *jk_log_lock = NULL;
   static char *jk_shm_file = NULL;
  +static size_t jk_shm_size = JK_SHM_DEF_SIZE;
   
   static int JK_METHOD ws_start_response(jk_ws_service_t *s,
  int status,
  @@ -886,6 +887,26 @@
   }
   
   /*
  + * JkShmSize Directive Handling
  + *
  + * JkShmSize size in kilobytes
  + */
  +
  +static const char *jk_set_shm_size(cmd_parms * cmd,
  +   void *dummy, const char *shm_size)
  +{
  +int sz = 0;
  +/* we need an absolute path */
  +sz = atoi(shm_size) * 1024;
  +if (sz  JK_SHM_DEF_SIZE)
  +sz = JK_SHM_DEF_SIZE;
  +else
  +sz = JK_SHM_ALIGN(sz);
  +jk_shm_size = (size_t)sz;
  +return NULL;
  +}
  +
  +/*
* JkLogLevel Directive Handling
*
* JkLogLevel debug/info/error/emerg
  @@ -1580,6 +1601,9 @@
   AP_INIT_TAKE1(JkShmFile, jk_set_shm_file, NULL, RSRC_CONF,
 Full path to the Jakarta Tomcat module shared memory 
file),
   
  +AP_INIT_TAKE1(JkShmSize, jk_set_shm_size, NULL, RSRC_CONF,
  +  Size of the shared memory file in KBytes),
  +
   AP_INIT_TAKE1(JkLogLevel, jk_set_log_level, NULL, RSRC_CONF,
 The Jakarta Tomcat module log level, can be debug, 
 info, error or emerg),
  @@ -2239,7 +2263,7 @@
   
   JK_TRACE_ENTER(conf-log);
   
  -if ((rc = jk_shm_attach(jk_shm_file, conf-log)) == 0) {
  +if ((rc = jk_shm_attach(jk_shm_file, jk_shm_size, conf-log)) == 0) {
   if (JK_IS_DEBUG_LEVEL(conf-log))
   jk_log(conf-log, JK_LOG_DEBUG, Attached shm:%s,
  jk_shm_name());
  @@ -2273,7 +2297,7 @@
   /* jk_map_t 

Re: JK 1.2.9-dev test results

2005-02-17 Thread Henri Gomez
Good works Mladen.

I found jk a bit faster and it's good to see that we could speed it up a little.

The next step could be to use larger AJP packets (4k too small)

On Thu, 17 Feb 2005 14:11:28 +0100, Mladen Turk [EMAIL PROTECTED] wrote:
 Hi,
 
 Henri said that he noticed current dev version
 of mod_jk being quite faster then previous (1.2.8).
 
 Although it was not the primary intention to
 be faster, I think no one will object :).
 So here are some benchmark results from my side:
 
 JK 1.2.8 single thread
 Requests per second:784.31 [#/sec] (mean)
 
 JK 1.2.9-dev single thread
 Requests per second:798.01 [#/sec] (mean)
 
 JK 1.2.9-dev 10 concurrent threads
 Requests per second:918.22 [#/sec] (mean)
 
 JK 1.2.9-dev 10 concurrent threads with socket_timeout
 Requests per second:910.38 [#/sec] (mean)
 
 So. Is this a speedup or not ;)?
 
 Interesting is that new socket_timeout implementation
 does not slow down that much. After all it sets the
 socket to nonblocking mode before each request, checks if
 the socket is still connected and then sets to blocking mode again.
 Compared to cping/cpong prepost, the system is almost twice
 as faster. Of course it will not detect hanged tomcat,
 only if tomcat broke down or some other network problem
 happened.
 
 Cheers,
 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: JK 1.2.9-dev test results

2005-02-17 Thread Mladen Turk
Henri Gomez wrote:
Good works Mladen.
I found jk a bit faster and it's good to see that we could speed it up a little.
The next step could be to use larger AJP packets (4k too small)
Sure ;).
For 100K file the speed is the same, as expected.
On large files we are measuring the network throughput
not the speed of the jk itself.
Anyhow what is more important then speed is the fact
that endpoint cache is working as expected on threaded
servers.
BTW, what do you think of deprecating the JNI connector.
Since it can be (theoretically) used only on windows and netware,
I wonder if it make sense to continue the support.
Regards,
Mladen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


DO NOT REPLY [Bug 33623] New: - Tomcat 5.5.7 could not be started on Redhat Enterprise V3.0 linux

2005-02-17 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33623.
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=33623

   Summary: Tomcat 5.5.7 could not be started on Redhat Enterprise
V3.0 linux
   Product: Tomcat 5
   Version: 5.5.7
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: normal
  Priority: P2
 Component: Catalina
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


Hi there,

I found the tomcat 5.5.7 (also 5.5.6) binary could not be started on Redhat 
Enterprise V3.0. The logs refered as the following:

java.lang.NoClassDefFoundError: org/apache/tomcat/util/digester/Rule
   at java.lang.Class.getDeclaredConstructors0(Native Method)
   at java.lang.Class.privateGetDeclaredConstructors(Class.java:1610)
   at java.lang.Class.getConstructor0(Class.java:1922)
   at java.lang.Class.newInstance0(Class.java:278)
   at java.lang.Class.newInstance(Class.java:261)
   at org.apache.catalina.startup.Bootstrap.init(Bootstrap.java:201)
   at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:386)

But it ran OK for tomcat 5.5.4 on the same machine. What is the problem for the 
above error messages?

Thanks in advance!

Sueder

-- 
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 33623] - Tomcat 5.5.7 could not be started on Redhat Enterprise V3.0 linux

2005-02-17 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33623.
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=33623


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID




--- Additional Comments From [EMAIL PROTECTED]  2005-02-17 17:24 ---
Please use tomcat-user to debug this. Bugzilla is not a support forum

-- 
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 33143] - [PATCH] Java 1.4 loggers per context

2005-02-17 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33143.
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=33143





--- Additional Comments From [EMAIL PROTECTED]  2005-02-17 18:30 ---
I think I will try Commons to experiment with svn. svn first experience is
rough, since it has all sorts of folders all over the place, and I have no idea
how to import code ;) It's going to be fun :)

Anyway, I will propose a new component named commons-juli, which will contain as
its initial code:
- the replacement log manager
- a bare bones rotatable file logger
Those two will make a bare bones container friendly mini-JAR. We can then either
ship that to provide decent java.util.logging defaults, or give instructions on
how to install.

I expect additional loggers to start appearing, but I'll keep a bare bones JAR
containing only the basics.

BTW, juli stands for Java Util Logging Implementation. I thought it was cute.

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



cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core StandardContext.java

2005-02-17 Thread luehe
luehe   2005/02/17 09:55:24

  Modified:catalina/src/share/org/apache/catalina/core
StandardContext.java
  Log:
  Removed potential WebappClassLoader leak.
  
  Consider the following example scenario:
  
  - Servlet class references RequestDispatcher.
  
  - Servlet is loaded. Any of the symbols referenced will be
resolved lazily.
  
  - Servlet is invoked. Thread's context classloader has been set to the
servlet's WebappClassLoader.
  
  - org.apache.catalina.core.ApplicationDispatcher is loaded, and its
static log variable is initialized as follows:
  
  private static Log log = LogFactory.getLog(ApplicationDispatcher.class);
  
  - LogFactory.getLog() causes the context classloader (which corresponds
to the WebappClassLoader) to be cached in its static factories
Hashtable, as follows:
  
  if (classLoader != null  factory != null)
  factories.put(classLoader, factory);
  
  Right now, this classloader is never removed from this Hashtable when the
  webapp is stopped.
  
  Depending on number of deployed webapps and their servlets' execution
  paths, different Catalina classes will be loaded on different servlet
  invocation threads, and the classes' log initialization will cause
  the threads' context classloaders to be cached in LogFactory and never
  released from it.
  
  This patch should fix the issue.
  
  Let me know if you see any problems.
  
  Revision  ChangesPath
  1.163 +4 -1  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardContext.java
  
  Index: StandardContext.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
  retrieving revision 1.162
  retrieving revision 1.163
  diff -u -r1.162 -r1.163
  --- StandardContext.java  9 Feb 2005 12:20:40 -   1.162
  +++ StandardContext.java  17 Feb 2005 17:55:24 -  1.163
  @@ -4236,6 +4236,9 @@
   // Mark this application as unavailable while we shut down
   setAvailable(false);
   
  +// Remove our classloader from LogFactory's 'factories' cache
  +LogFactory.release(getLoader().getClassLoader());
  +
   // Binding thread
   ClassLoader oldCCL = bindThread();
   
  
  
  

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



DO NOT REPLY [Bug 33159] - ant deploy task should cause a failure in target when encountering a failure

2005-02-17 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33159.
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=33159





--- Additional Comments From [EMAIL PROTECTED]  2005-02-17 19:07 ---
(In reply to comment #2)
 Does it fail properly if you don't do foreach, i.e. just try a simple deploy? 
  
 I think foreach/parallel explicitly does not fail overall execution if one 
 path/list fails.

Hi Yoav,

Here's some followup. I have tried a few simple deploys (while trying to cause a
failure) and even with foreach/parallel out of the equation, deploy would not
show deterministic results. Sometimes I would get a BUILD SUCCESSFUL and
sometimes a BUILD FAILED even though the message in all the cases was as 
follows:

   [deploy] FAIL - Encountered exception java.io.IOException:
java.lang.IllegalStateException: Context path /sws is already in use

Seeing the above message paired up with the BUILD SUCCESSFUL is a little
disconcerting.

Doing some more followup on the foreach/parallel, I have a simple ant file which
shows that the foreach/parallel combination is not to blame:

?xml version=1.0?
project name=ant-contrib parallel task default=parallel

property name=lib.dir value=${user.home}/libfiles.java/
!-- Ant-Contrib --
property name=ant-contrib.ver value=0.6/
property name=ant-contrib.dir
location=${lib.dir}/ant-contrib-${ant-contrib.ver}/

taskdef resource=net/sf/antcontrib/antcontrib.properties
classpath=${ant-contrib.dir}/lib/ant-contrib-${ant-contrib.ver}.jar/

target name=parallel
foreach target=foo param=arg
parallel=true
list=1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20
inheritall=true/
/target

target name=foo
echo message=--${arg}--/
if
equals arg1=${arg} arg2=3/
then
fail message=Failing for argument ${arg}/
/then
/if
/target

/project

I will attach it to the bugreport as well.

Any more ideas on how to further investigate the deploy task?

-- 
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 33159] - ant deploy task should cause a failure in target when encountering a failure

2005-02-17 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33159.
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=33159





--- Additional Comments From [EMAIL PROTECTED]  2005-02-17 19:08 ---
Created an attachment (id=14306)
 -- (http://issues.apache.org/bugzilla/attachment.cgi?id=14306action=view)
ant file which shows that foreach/parallel target behaves okay


-- 
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: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core StandardContext.java

2005-02-17 Thread Remy Maucherat
[EMAIL PROTECTED] wrote:
luehe   2005/02/17 09:55:24
  Modified:catalina/src/share/org/apache/catalina/core
StandardContext.java
  Log:
  Removed potential WebappClassLoader leak.
  
  Consider the following example scenario:
  
  - Servlet class references RequestDispatcher.
  
  - Servlet is loaded. Any of the symbols referenced will be
resolved lazily.
  
  - Servlet is invoked. Thread's context classloader has been set to the
servlet's WebappClassLoader.
  
  - org.apache.catalina.core.ApplicationDispatcher is loaded, and its
static log variable is initialized as follows:
  
  private static Log log = LogFactory.getLog(ApplicationDispatcher.class);
  
  - LogFactory.getLog() causes the context classloader (which corresponds
to the WebappClassLoader) to be cached in its static factories
Hashtable, as follows:
  
  if (classLoader != null  factory != null)
  factories.put(classLoader, factory);
  
  Right now, this classloader is never removed from this Hashtable when the
  webapp is stopped.
  
  Depending on number of deployed webapps and their servlets' execution
  paths, different Catalina classes will be loaded on different servlet
  invocation threads, and the classes' log initialization will cause
  the threads' context classloaders to be cached in LogFactory and never
  released from it.
  
  This patch should fix the issue.
  
  Let me know if you see any problems.
There's the same code (and more) in WebappClassLoader.stop():
// Clear the classloader reference in common-logging
org.apache.commons.logging.LogFactory.release(this);
// Clear the classloader reference in the VM's bean introspector
java.beans.Introspector.flushCaches();
IMO, it's the right place to do this kind of cleaning up in the 
classloader, since it's CL related.

So -0 for this.
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core StandardContext.java

2005-02-17 Thread luehe
luehe   2005/02/17 10:25:51

  Modified:catalina/src/share/org/apache/catalina/core
StandardContext.java
  Log:
  Removed previous patch, since it is already being addressed in
  WebappClassLoader.stop(). Thanks Remy!
  
  Revision  ChangesPath
  1.164 +1 -4  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardContext.java
  
  Index: StandardContext.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
  retrieving revision 1.163
  retrieving revision 1.164
  diff -u -r1.163 -r1.164
  --- StandardContext.java  17 Feb 2005 17:55:24 -  1.163
  +++ StandardContext.java  17 Feb 2005 18:25:51 -  1.164
  @@ -4236,9 +4236,6 @@
   // Mark this application as unavailable while we shut down
   setAvailable(false);
   
  -// Remove our classloader from LogFactory's 'factories' cache
  -LogFactory.release(getLoader().getClassLoader());
  -
   // Binding thread
   ClassLoader oldCCL = bindThread();
   
  
  
  

-
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/core StandardContext.java

2005-02-17 Thread Jan Luehe


Remy Maucherat wrote:
 [EMAIL PROTECTED] wrote:
 

  This patch should fix the issue.
  
  Let me know if you see any problems.
 
 
 There's the same code (and more) in WebappClassLoader.stop():
 
  // Clear the classloader reference in common-logging
  org.apache.commons.logging.LogFactory.release(this);
  // Clear the classloader reference in the VM's bean introspector
  java.beans.Introspector.flushCaches();
 
 IMO, it's the right place to do this kind of cleaning up in the 
 classloader, since it's CL related.

You're absolutely right. You had fixed this in TC long time ago
(revision 1.20). This commit did slip through the cracks, so our
internal version was still suffering from this leak.

Thanks!

Jan



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



mod_jk release policy - was: JK 1.2.9-dev test results

2005-02-17 Thread Rainer Jung
Hi,
first: thanks a lot to Mladen for adding all the beautiful features [and 
removing CRLF :) ]. Big leap forward!

I think that until Monday we were still in the progress of adding 
features, and fixing bugs. 1.2.8 changed a lot internally, but most was 
functionally compatible to 1.2.6. Release 1.2.9 still supported all 
features of 1.2.6.

Now we are in the discussion of dropping features (and we even did drop 
some like locality support) and I have the impresssion there should be a 
separate discussion thread about the future of mod_jk:

Do we need to reflect the incompatible changes by shifting to 1.3? By 
this I mean: will we still need to maintain bugs in the parallel 1.2 tree?

Stated differently:
Which features can be dropped without further maintenance for older 
releases?

Usually one would deprecate by first announcing deprecation but still 
supporting for some time to allow migration. Then after e.g. 6 months 
one could drop the functionality totally.

People have just been told few months ago, that mod_jk2 is no longer 
supported and that they should move to mod_jk. Mladen helps them by 
reimplementing valuable mod_jk2 features inside mod_jk, but we should 
not kick out long-time mod_jk users by dropping features without having 
a visible discussion on that item.

Regards,
Rainer
Mladen Turk wrote:
Henri Gomez wrote:
Good works Mladen.
I found jk a bit faster and it's good to see that we could speed it up 
a little.

The next step could be to use larger AJP packets (4k too small)
Sure ;).
For 100K file the speed is the same, as expected.
On large files we are measuring the network throughput
not the speed of the jk itself.
Anyhow what is more important then speed is the fact
that endpoint cache is working as expected on threaded
servers.
BTW, what do you think of deprecating the JNI connector.
Since it can be (theoretically) used only on windows and netware,
I wonder if it make sense to continue the support.
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: JK 1.2.9-dev test results

2005-02-17 Thread Bill Barker

- Original Message -
From: Mladen Turk [EMAIL PROTECTED]
To: Tomcat Developers List tomcat-dev@jakarta.apache.org
Sent: Thursday, February 17, 2005 7:27 AM
Subject: Re: JK 1.2.9-dev test results


 Henri Gomez wrote:
  Good works Mladen.
 
  I found jk a bit faster and it's good to see that we could speed it up a
little.
 
  The next step could be to use larger AJP packets (4k too small)
 

 Sure ;).

 For 100K file the speed is the same, as expected.
 On large files we are measuring the network throughput
 not the speed of the jk itself.

 Anyhow what is more important then speed is the fact
 that endpoint cache is working as expected on threaded
 servers.

 BTW, what do you think of deprecating the JNI connector.
 Since it can be (theoretically) used only on windows and netware,
 I wonder if it make sense to continue the support.


Not only that, but the mod_jk version can only be used by TC 3.3.x.  I don't
think that it was ever really supported, so deprecating it is just a
formality.

 Regards,
 Mladen

 -
 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: mod_jk release policy - was: JK 1.2.9-dev test results

2005-02-17 Thread Mladen Turk
Rainer Jung wrote:
Hi,
first: thanks a lot to Mladen for adding all the beautiful features [and 
removing CRLF :) ]. Big leap forward!

Still, I cope with those on a daily basis.
I think that until Monday we were still in the progress of adding 
features, and fixing bugs. 1.2.8 changed a lot internally, but most was 
functionally compatible to 1.2.6. Release 1.2.9 still supported all 
features of 1.2.6.
 
Something similar I already explained discussing with guys interested
on Netware platform.
Something need to be done, and the obvious solution was not to reinvent
the wheel, but rather use all the code and knowledge about the subject
already present.
To be able to use some new features like dynamic config, some things
has to be changed internally, but nothing was touched in the protocol
level, only how that protocol is managed.
So I don't see the point of forking 1.3. Both config and core features
are the same. Of course some advanced configuration properties where
changes, lot new added, but from the outside its still old mod_jk.
Further more adding shared memory and dynamic config I see as a final
design change for mod_jk.
Now we are in the discussion of dropping features (and we even did drop 
some like locality support) and I have the impresssion there should be a 
separate discussion thread about the future of mod_jk:


Other thing is 'deprecating' certain thing.
By that I don't mean deleting them or something like that, but rather
marking them as 'no more developed'.
The reason is for that is pure fact. For example we have lotus domino
connector that works only for domino5. Think that later versions don't
even have compatible api. I'm not aware anyone in the
world used jk to connect domino with tomcat (at least never saw
bugzilla entry on that). So it is deprecated by that fact.
The same applies to JNI. Who uses that?
Regarding locality, you mean local_worker and local_worker_only flags?
IMHO that was one of the fuzziest things about jk that no one ever
understood, not to mention that this never worked actually.
Take for example the current documentation about local_worker:
If local_worker is set to True it is marked as local worker. If in 
minimum one worker is marked as local worker, lb_worker is in local 
worker mode. All local workers are moved to the beginning of the 
internal worker list in lb_worker during validation.

Now what that means to the actual user? I reeded that zillion times
and never understood.
Also further more:
We need a graceful shut down of a node for maintenance. The balancer in 
front asks a special port on each node periodically. If we want to 
remove a node from the cluster, we switch off this port.

WTF !? How? Which port? How to switch of this port?
What counts the most is that you where unable to mark the node for
shutdown, and not to accept new connections without session id.
I suppose that was the purpose for those two directives, but I was
never able to setup the jk in that direction.
So locality is not deprecated. Quite opposite, now it works, just
the local_worker_only is changed to sticky_session_force.
IMHO this is more clearer and descriptive directive then previous one.
New things like 'domain' (present from 1.2.8) and 'redirect' are just
extra cookies to be able to finer tune the cluster topology.
Regards,
Mladen.

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


Tomcat roadmap

2005-02-17 Thread Sam Ewing
J2EE 5.0 releases in the second half of 2005. Will
this be implemented by Tomcat 5.5 too, or will this
result ina new version - say Tomcat 6 (for Servlet
2.4/JSP 2.1?).

I was writing an article on this area, and was curious
about the roadmap..

Thanks,

Sam




__ 
Do you Yahoo!? 
Yahoo! Mail - You care about security. So do we. 
http://promotions.yahoo.com/new_mail

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



RE: Tomcat roadmap

2005-02-17 Thread Yoav Shapira
Hi,
Tomcat is not a full J2EE container, only a Servlet and JSP container.
Accordingly, J2EE spec releases don't matter per-se.  They only matter if
they contain new Servlet or JSP spec releases in them.

Tomcat 6 will implement the next version of the JSP and Servlet specs,
whenever those come out.

Yoav

 -Original Message-
 From: Sam Ewing [mailto:[EMAIL PROTECTED]
 Sent: Thursday, February 17, 2005 7:46 PM
 To: tomcat-dev@jakarta.apache.org
 Subject: Tomcat roadmap
 
 J2EE 5.0 releases in the second half of 2005. Will
 this be implemented by Tomcat 5.5 too, or will this
 result ina new version - say Tomcat 6 (for Servlet
 2.4/JSP 2.1?).
 
 I was writing an article on this area, and was curious
 about the roadmap..
 
 Thanks,
 
 Sam
 
 
 
 
 __
 Do you Yahoo!?
 Yahoo! Mail - You care about security. So do we.
 http://promotions.yahoo.com/new_mail
 
 -
 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 33143] - [PATCH] Java 1.4 loggers per context

2005-02-17 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33143.
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=33143





--- Additional Comments From [EMAIL PROTECTED]  2005-02-18 02:20 ---
(In reply to comment #29)
 Anyway, I will propose a new component named commons-juli, which will contain 
 as
 its initial code:
 - the replacement log manager
 - a bare bones rotatable file logger
 Those two will make a bare bones container friendly mini-JAR. We can then 
 either
 ship that to provide decent java.util.logging defaults, or give instructions 
 on
 how to install.

Cool, that sounds great. Sorry about the lack of comments in the code. Let me 
know if you need me to 
clarify anything. Much of the code is re-implementing stuff from the standard 
LogManager, which 
unfortunately wasn't written with easy subclassing in mind.


-- 
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: Tomcat roadmap

2005-02-17 Thread Jess Holle
A related question would be when will the JDT embedded in Tomcat 5.5 
support Java 5 language compilation.

--
Jess Holle
Yoav Shapira wrote:
Hi,
Tomcat is not a full J2EE container, only a Servlet and JSP container.
Accordingly, J2EE spec releases don't matter per-se.  They only matter if
they contain new Servlet or JSP spec releases in them.
Tomcat 6 will implement the next version of the JSP and Servlet specs,
whenever those come out.
Yoav
 

-Original Message-
From: Sam Ewing [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 17, 2005 7:46 PM
To: tomcat-dev@jakarta.apache.org
Subject: Tomcat roadmap
J2EE 5.0 releases in the second half of 2005. Will
this be implemented by Tomcat 5.5 too, or will this
result ina new version - say Tomcat 6 (for Servlet
2.4/JSP 2.1?).
I was writing an article on this area, and was curious
about the roadmap..
Thanks,
Sam

__
Do you Yahoo!?
Yahoo! Mail - You care about security. So do we.
http://promotions.yahoo.com/new_mail
-
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: Tomcat roadmap

2005-02-17 Thread Sam Ewing
Thanks Yoav,

JSP 2.1 specifications are currently in Early Draft
Review phase. Will these be implemented as a 'Tomcat
6' release?

I don't see a JCP for the next servlet specification
anywhere in the picture, so if there is new Tomcat
version (Tomcat 6?), would this be for Servlet 2.4/JSP
2.1? Is there any timeline for this?

Thanks again,

- Sam

Hi,
Tomcat is not a full J2EE container, only a Servlet
and JSP container.
Accordingly, J2EE spec releases don't matter per-se. 
They only matter if
they contain new Servlet or JSP spec releases in
them.

Tomcat 6 will implement the next version of the JSP
and Servlet specs,
whenever those come out.

Yoav

  

-Original Message-
From: Sam Ewing [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 17, 2005 7:46 PM
To: tomcat-dev@jakarta.apache.org
Subject: Tomcat roadmap

J2EE 5.0 releases in the second half of 2005. Will
this be implemented by Tomcat 5.5 too, or will this
result ina new version - say Tomcat 6 (for
Servlet
2.4/JSP 2.1?).

I was writing an article on this area, and was
curious
about the roadmap..

Thanks,

Sam



__ 
Do you Yahoo!? 
The all-new My Yahoo! - Get yours free! 
http://my.yahoo.com 
 


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



Config Query for Mod_Jk...

2005-02-17 Thread NormW
Greetings All...
Two days ago I had a configuration that was working to TC5, but after 
adding in the patches since then, all I get is 'Internal Server Error' 
which natuarally enough isn't a great deal of help.

The /status/ page(s) show fine.
My workers.properties looks like:

worker.list=lb1,status
worker.worker1.type=ajp13
worker.worker1.port=9009
worker.worker1.host=localhost
worker.worker2.type=ajp13
worker.worker2.port=9009
worker.worker2.host=10.202.65.190
worker.lb1.type=lb
worker.lb1.balanced_workers=worker1,worker2
worker.status.type=status
-
and the httpd.conf settings look like:
-
JkShmFile SYS:/Apache21/conf/shm.file
JkWorkersFile SYS:/Apache21/conf/workers.properties
JkLogFile SYS:/Apache21/logs/mod_jk21.log
JkLogLeveldebug
JkMount /status/*   status
JkMount /*.jsp  lb1
JkMount /servlet/*  lb1
JkMount /admin  lb1
JkMount /admin/*lb1
JkMount /managerlb1
JkMount /manager/*  lb1
-
Anything radically wrong with this before I start poking in the code and 
the Tomcat?

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


Re: Config Query for Mod_Jk...

2005-02-17 Thread Mladen Turk
NormW wrote:
Greetings All...
Two days ago I had a configuration that was working to TC5, but after 
adding in the patches since then, all I get is 'Internal Server Error' 
which natuarally enough isn't a great deal of help.

Hi, as said before:
Clear the mod_jk.log.
Set:
JkLogLevel trace
start apache
GET /admin/
stop apache
Post the mod_jk.log
Without that I really can not help.
Both linux and win32 have no such problems.
Regards,
Mladen.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Config Query for Mod_Jk...

2005-02-17 Thread NormW
Good evening...
From this I assume:
1) The current config is okay,
2) You didn't get the trace I sent last night.
Will do another; apologies for the hassles.
Norm
Mladen Turk wrote:
NormW wrote:
Greetings All...
Two days ago I had a configuration that was working to TC5, but after 
adding in the patches since then, all I get is 'Internal Server Error' 
which natuarally enough isn't a great deal of help.

Hi, as said before:
Clear the mod_jk.log.
Set:
JkLogLevel trace
start apache
GET /admin/
stop apache
Post the mod_jk.log
Without that I really can not help.
Both linux and win32 have no such problems.
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: Config Query for Mod_Jk...

2005-02-17 Thread Mladen Turk
NormW wrote:
Good evening...
 From this I assume:
1) The current config is okay,
Only not sure why you need /*.jsp and /servlet/*.
It's a bad practice. You should map only deployed
applications, but OK.
2) You didn't get the trace I sent last night.
Think that dev list has a limit on attachments.
Just cc to my email address.
Regards,
Mladen.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]