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

2005-02-19 Thread mturk 
mturk   2005/02/19 00:12:30

  Modified:jk/native/common jk_lb_worker.c jk_shm.h jk_status.c
  Log:
  Add worker is_busy runtime status flag. When we can not obtain a free
  endpoint, mark the worker as busy rather then in error, so that recovery
  is not needed.
  
  Revision  ChangesPath
  1.63  +44 -25jakarta-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.62
  retrieving revision 1.63
  diff -u -r1.62 -r1.63
  --- jk_lb_worker.c17 Feb 2005 13:48:47 -  1.62
  +++ jk_lb_worker.c19 Feb 2005 08:12:29 -  1.63
  @@ -42,6 +42,9 @@
   #define WAIT_BEFORE_RECOVER (60*1)
   #define WORKER_RECOVER_TIME (recover_time)
   
  +#define JK_WORKER_IN_ERROR(w) ((w)-in_error_state  !(w)-is_disabled  
!(w)-is_busy)
  +#define JK_WORKER_USABLE(w)   (!(w)-in_error_state  !(w)-is_disabled  
!(w)-is_busy)
  +
   struct lb_endpoint
   {
   jk_endpoint_t *e;
  @@ -183,6 +186,7 @@
   w-s-name);
   w-s-in_recovering  = JK_TRUE;
   w-s-in_error_state = JK_FALSE;
  +w-s-is_busy = JK_FALSE;
   }
   
   JK_TRACE_EXIT(l);
  @@ -225,8 +229,7 @@
   /* Take into calculation only the workers that are
* not in error state or not disabled.
*/
  -if (!p-lb_workers[i].s-in_error_state 
  -!p-lb_workers[i].s-is_disabled) {
  +if (JK_WORKER_USABLE(p-lb_workers[i].s)) {
   if (p-lbmethod == JK_LB_BYREQUESTS) {
   p-lb_workers[i].s-lb_value += 
p-lb_workers[i].s-lb_factor;
   total_factor += p-lb_workers[i].s-lb_factor;
  @@ -269,15 +272,13 @@
* The worker might still be unusable, but we try
* anyway.
*/
  -if (p-lb_workers[i].s-in_error_state 
  -!p-lb_workers[i].s-is_disabled) {
  +if (JK_WORKER_IN_ERROR(p-lb_workers[i].s)) {
   retry_worker(p-lb_workers[i], p-s-recover_wait_time, l);
   }
   /* Take into calculation only the workers that are
* not in error state or not disabled.
*/
  -if (!p-lb_workers[i].s-in_error_state 
  -!p-lb_workers[i].s-is_disabled) {
  +if (JK_WORKER_USABLE(p-lb_workers[i].s)) {
   p-lb_workers[i].s-lb_value += p-lb_workers[i].s-lb_factor;
   total_factor += p-lb_workers[i].s-lb_factor;
   if (!candidate || p-lb_workers[i].s-lb_value  
candidate-s-lb_value)
  @@ -309,15 +310,13 @@
* The worker might still be unusable, but we try
* anyway.
*/
  -if (p-lb_workers[i].s-in_error_state 
  -!p-lb_workers[i].s-is_disabled) {
  +if (JK_WORKER_IN_ERROR(p-lb_workers[i].s)) {
   retry_worker(p-lb_workers[i], p-s-recover_wait_time, l);
   }
   /* Take into calculation only the workers that are
* not in error state or not disabled.
*/
  -if (!p-lb_workers[i].s-in_error_state 
  -!p-lb_workers[i].s-is_disabled) {
  +if (JK_WORKER_USABLE(p-lb_workers[i].s)) {
   mytraffic = 
(p-lb_workers[i].s-transferred/p-lb_workers[i].s-lb_factor) +
   
(p-lb_workers[i].s-readed/p-lb_workers[i].s-lb_factor);
   if (!candidate || mytraffic  curmin) {
  @@ -346,9 +345,9 @@
   return rc;
   }
   
  -static worker_record_t *find_session_route(lb_worker_t *p, 
  -   const char *name,
  -   jk_logger_t *l)
  +static worker_record_t *find_bysession_route(lb_worker_t *p, 
  + const char *name,
  + jk_logger_t *l)
   {
   unsigned int i;
   int total_factor = 0;
  @@ -361,13 +360,12 @@
   candidate = find_best_bydomain(p, name, l);
   }
   if (candidate) {
  -if (candidate-s-in_error_state  !candidate-s-is_disabled) {
  +if (JK_WORKER_IN_ERROR(candidate-s)) {
   retry_worker(candidate, p-s-recover_wait_time, l);
   }
   if (candidate-s-in_error_state) {
  -/* We have a worker that is unusable.
  - * It can be in error or disabled, but in case
  - * it has a redirection set use that redirection worker.
  +/* We have a worker that is error state.
  + * If it has a redirection set use that redirection worker.
* This enables to safely remove the member from the
* balancer. Of course you will need a some kind of
* session replication between those two remote.
  @@ -384,8 +382,7 @@
   }
   if (candidate  !uses_domain) {
   for (i = 0; i

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

2005-02-19 Thread mturk 
mturk   2005/02/19 01:13:35

  Modified:jk/native/common jk_ajp_common.c jk_connect.c
  Log:
  Use alternative is_socket_connected implementation using
  select with 1 microsecond timeout. It should be both faster and
  usable on netware too.
  
  Revision  ChangesPath
  1.91  +7 -9  
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.90
  retrieving revision 1.91
  diff -u -r1.90 -r1.91
  --- jk_ajp_common.c   18 Feb 2005 08:27:21 -  1.90
  +++ jk_ajp_common.c   19 Feb 2005 09:13:35 -  1.91
  @@ -847,10 +847,9 @@
   if (ae-worker-cache_timeout  0 || ae-worker-recycle_timeout 
 0)
   ae-last_access = time(NULL);
   if (ae-worker-socket_timeout  0) {
  -int rc = 0;
  -if ((rc = jk_is_socket_connected(ae-sd, 
ae-worker-socket_timeout)) != 1) {
  -jk_log(l, JK_LOG_INFO,
  -Socket is not connected any more (status=%d), 
rc);
  +if (!jk_is_socket_connected(ae-sd, 
ae-worker-socket_timeout)) {
  +jk_log(l, JK_LOG_INFO,
  +   Socket is not connected any more (errno=%d), 
errno);
   jk_close_socket(ae-sd);
   ae-sd = -1;
   JK_TRACE_EXIT(l);
  @@ -1161,10 +1160,9 @@
   while ((ae-sd  0)) {
   err = 0;
   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,
  -   Socket is not connected any more (status=%d), 
rc);
  +if (!jk_is_socket_connected(ae-sd, ae-worker-socket_timeout)) 
{
  +jk_log(l, JK_LOG_INFO,
  +   Socket is not connected any more (errno=%d), errno);
   jk_close_socket(ae-sd);
   ae-sd = -1;
   err++;
  
  
  
  1.43  +48 -2 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.42
  retrieving revision 1.43
  diff -u -r1.42 -r1.43
  --- jk_connect.c  17 Feb 2005 08:26:42 -  1.42
  +++ jk_connect.c  19 Feb 2005 09:13:35 -  1.43
  @@ -194,18 +194,36 @@
  sock_buf);
   }
   
  -#ifdef WIN32
   if (timeout  0) {
  +#ifdef WIN32
   timeout = timeout * 1000;
   setsockopt(sock, SOL_SOCKET, SO_RCVTIMEO,
  (char *) timeout, sizeof(int));
   setsockopt(sock, SOL_SOCKET, SO_SNDTIMEO,
  (char *) timeout, sizeof(int));
  +#else
  +/* TODO: How to set the timeout for other platforms? */
  +#endif
   if (JK_IS_DEBUG_LEVEL(l))
   jk_log(l, JK_LOG_DEBUG,
  timeout %d set for socket=%d,
  timeout, sock);
   }
  +#ifdef SO_NOSIGPIPE
  +/* The preferred method on Mac OS X (10.2 and later) to prevent SIGPIPEs 
when
  + * sending data to a dead peer. Possibly also existing and in use on 
other BSD
  + * systems?
  +*/
  +set = 1;
  +if (setsockopt(sd, SOL_SOCKET, SO_NOSIGPIPE, (const char *)set,
  +   sizeof(int))) {
  +JK_GET_SOCKET_ERRNO();
  +jk_log(l, JK_LOG_ERROR,
  +failed setting SO_NOSIGPIPE with errno=%d, errno);
  +jk_close_socket(sock);
  +JK_TRACE_EXIT(l);
  +return -1;
  +}
   #endif
   /* Tries to connect to Tomcat (continues trying while error is EINTR) */
   do {
  @@ -405,6 +423,32 @@
   return 0;
   }
   
  +#if 1
  +int jk_is_socket_connected(int sd, int timeout)
  +{
  +fd_set fd;
  +struct timeval tv;
  + 
  +FD_ZERO(fd);
  +FD_SET(sd, fd);
  +
  +/* Wait one microsecond */
  +tv.tv_sec  = 0;
  +tv.tv_usec = 1;
  +
  +/* If we get a timeout, then we are still connected */
  +if (select(1, fd, NULL, NULL, tv) == 0)
  +return 1;
  +else {
  +#if defined(WIN32) || (defined(NETWARE)  defined(__NOVELL_LIBC__))
  +errno = WSAGetLastError() - WSABASEERR;
  +#endif
  +return 0;
  +}
  +}
  +
  +#else
  +
   #if defined(WIN32) || (defined(NETWARE)  defined(__NOVELL_LIBC__))
   #define EWOULDBLOCK (WSAEWOULDBLOCK - WSABASEERR)
   #endif
  @@ -434,3 +478,5 @@
   else
   return rc;
   }
  +
  +#endif
  
  
  

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

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

2005-02-19 Thread NormW 
Greetings,
Will see... :-)
N.
[EMAIL PROTECTED] wrote:
mturk   2005/02/19 01:13:35
  Modified:jk/native/common jk_ajp_common.c jk_connect.c
  Log:
  Use alternative is_socket_connected implementation using
  select with 1 microsecond timeout. It should be both faster and
  usable on netware too.
  
  Revision  ChangesPath
  1.91  +7 -9  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.90
  retrieving revision 1.91
  diff -u -r1.90 -r1.91
  --- jk_ajp_common.c	18 Feb 2005 08:27:21 -	1.90
  +++ jk_ajp_common.c	19 Feb 2005 09:13:35 -	1.91
  @@ -847,10 +847,9 @@
   if (ae-worker-cache_timeout  0 || ae-worker-recycle_timeout  0)
   ae-last_access = time(NULL);
   if (ae-worker-socket_timeout  0) {
  -int rc = 0;
  -if ((rc = jk_is_socket_connected(ae-sd, ae-worker-socket_timeout)) != 1) {
  -jk_log(l, JK_LOG_INFO,
  -Socket is not connected any more (status=%d), rc);
  +if (!jk_is_socket_connected(ae-sd, ae-worker-socket_timeout)) {
  +jk_log(l, JK_LOG_INFO,
  +   Socket is not connected any more (errno=%d), errno);
   jk_close_socket(ae-sd);
   ae-sd = -1;
   JK_TRACE_EXIT(l);
  @@ -1161,10 +1160,9 @@
   while ((ae-sd  0)) {
   err = 0;
   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,
  -   Socket is not connected any more (status=%d), rc);
  +if (!jk_is_socket_connected(ae-sd, ae-worker-socket_timeout)) {
  +jk_log(l, JK_LOG_INFO,
  +   Socket is not connected any more (errno=%d), errno);
   jk_close_socket(ae-sd);
   ae-sd = -1;
   err++;
  
  
  
  1.43  +48 -2 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.42
  retrieving revision 1.43
  diff -u -r1.42 -r1.43
  --- jk_connect.c	17 Feb 2005 08:26:42 -	1.42
  +++ jk_connect.c	19 Feb 2005 09:13:35 -	1.43
  @@ -194,18 +194,36 @@
  sock_buf);
   }
   
  -#ifdef WIN32
   if (timeout  0) {
  +#ifdef WIN32
   timeout = timeout * 1000;
   setsockopt(sock, SOL_SOCKET, SO_RCVTIMEO,
  (char *) timeout, sizeof(int));
   setsockopt(sock, SOL_SOCKET, SO_SNDTIMEO,
  (char *) timeout, sizeof(int));
  +#else
  +/* TODO: How to set the timeout for other platforms? */
  +#endif
   if (JK_IS_DEBUG_LEVEL(l))
   jk_log(l, JK_LOG_DEBUG,
  timeout %d set for socket=%d,
  timeout, sock);
   }
  +#ifdef SO_NOSIGPIPE
  +/* The preferred method on Mac OS X (10.2 and later) to prevent SIGPIPEs when
  + * sending data to a dead peer. Possibly also existing and in use on other BSD
  + * systems?
  +*/
  +set = 1;
  +if (setsockopt(sd, SOL_SOCKET, SO_NOSIGPIPE, (const char *)set,
  +   sizeof(int))) {
  +JK_GET_SOCKET_ERRNO();
  +jk_log(l, JK_LOG_ERROR,
  +failed setting SO_NOSIGPIPE with errno=%d, errno);
  +jk_close_socket(sock);
  +JK_TRACE_EXIT(l);
  +return -1;
  +}
   #endif
   /* Tries to connect to Tomcat (continues trying while error is EINTR) */
   do {
  @@ -405,6 +423,32 @@
   return 0;
   }
   
  +#if 1
  +int jk_is_socket_connected(int sd, int timeout)
  +{
  +fd_set fd;
  +struct timeval tv;
  + 
  +FD_ZERO(fd);
  +FD_SET(sd, fd);
  +
  +/* Wait one microsecond */
  +tv.tv_sec  = 0;
  +tv.tv_usec = 1;
  +
  +/* If we get a timeout, then we are still connected */
  +if (select(1, fd, NULL, NULL, tv) == 0)
  +return 1;
  +else {
  +#if defined(WIN32) || (defined(NETWARE)  defined(__NOVELL_LIBC__))
  +errno = WSAGetLastError() - WSABASEERR;
  +#endif
  +return 0;
  +}
  +}
  +
  +#else
  +
   #if defined(WIN32) || (defined(NETWARE)  defined(__NOVELL_LIBC__))
   #define EWOULDBLOCK (WSAEWOULDBLOCK - WSABASEERR)
   #endif
  @@ -434,3 +478,5 @@
   else
   return rc;
   }
  +
  +#endif
  
  
  

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

DO NOT REPLY [Bug 33650] New: - Jasper performance for multiple files processing

2005-02-19 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=33650.
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=33650

   Summary: Jasper performance for multiple files processing
   Product: Tomcat 5
   Version: 5.0.30
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: Jasper
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


Jasper performance is abysmal when using jspc to precompiles jsps, or more 
especially to generate the java files.

I have a webapp with 450 jsps, jasper generates the java files in 12 minutes. 
In comparison, javac compilation for those 450 generated java files is 
performed in 1 minute.

Profiling and debugging the code, it appears clearly that most of the time is 
spent doing the same parsing for static include directives over and over.

Typically a page includes an init page which itself includes 2 init pages.
page.jsp - init.jsp - { init-a.jsp, init-b.jsp, ... }

For each and every page, the parser always go down the tree without caching 
includes and parse init.jsp, and so on. So basically the init.jsp is parsed 
450 times.

The Mark object is also pretty inefficient as it generates bazillions of 
objects which are not so lightweight (via Mark.mark()).

-- 
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-connectors/jk/native/common jk_ajp_common.c jk_connect.c

2005-02-19 Thread NormW 
Good evening,
Can confirm a clean build for 2.1 and 2.0.53 Apache. Time is short now 
but will test them for basic ops in the morning. I assume these still 
need the socket_timeout at zero?
Regards,
Norm

-
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-19 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 25 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-19022005/build/libtool 
--silent --mode=compile gcc 
-I/usr/local/gump/public/workspace/apache-httpd/dest-19022005/include -g -O2 -g 
-O2 -pthread -DHAVE_APR 
-I/usr/local/gump/public/workspace/apr/dest-19022005/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-19022005/build/libtool: 
/usr/local/gump/public/workspace/apache-httpd/dest-19022005/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 2119022005, brutus:brutus-public:2119022005
Gump E-mail Identifier (unique within run) #16.

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

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

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

2005-02-19 Thread Mladen Turk 
NormW wrote:
Good evening,
Can confirm a clean build for 2.1 and 2.0.53 Apache. Time is short now 
but will test them for basic ops in the morning. I assume these still 
need the socket_timeout at zero?
Well, new is_socket_connected implementation should be available
for netware too (that was the purpose after all).
Tell me if it works when you set the socket_timeout to a positive value.
Regards,
Mladen.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

2005-02-19 Thread NormW 
Hi again...
Mladen Turk wrote:
NormW wrote:
Good evening,
Can confirm a clean build for 2.1 and 2.0.53 Apache. Time is short now 
but will test them for basic ops in the morning. I assume these still 
need the socket_timeout at zero?
Well, new is_socket_connected implementation should be available
for netware too (that was the purpose after all).
Tell me if it works when you set the socket_timeout to a positive value.
Okay - there is time enough to try in the morning and there will be a 
message shortly thereafter...
Regards,
Mladen.
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: mod_jk release policy - was: JK 1.2.9-dev test results

2005-02-19 Thread Remy Maucherat 
William A. Rowe, Jr. wrote:
It definately seems like j-t-c should be a first candidate
for svn conversion.  The other jakarta-tomcat repositories
are considerabily more complex.
But it would be good to have line endings straightened out
beforehand.
I find svn quite confusing to work with. Especially, the possibility of 
browsing a revision tree seems unusable (due to the fact that revisions 
are global, tortoise cannot make a graph in less than 4 hours :( ), and 
it's an important tool for me.

Unfortunately, this means I'll have to veto a move to svn for the time 
being, until I figure out how to use it.

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

DO NOT REPLY [Bug 33650] - Jasper performance for multiple files processing

2005-02-19 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=33650.
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=33650


[EMAIL PROTECTED] changed:

   What|Removed |Added

Version|5.0.30  |5.5.7




--- Additional Comments From [EMAIL PROTECTED]  2005-02-19 11:53 ---
Ok. Does this mean you have done some optimizations already (patches) ?
Do you have test cases ? (JSPs which are particularly slow to compile)

Note: This will looked at in 5.0.x (better to have a slow source generation than
a *broken* source generation).

-- 
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_service.h jk_util.h

2005-02-19 Thread mturk 
mturk   2005/02/19 02:54:49

  Modified:jk/native/common jk_service.h jk_util.h
  Log:
  Move init service proto to correct header.
  
  Revision  ChangesPath
  1.30  +5 -2  jakarta-tomcat-connectors/jk/native/common/jk_service.h
  
  Index: jk_service.h
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_service.h,v
  retrieving revision 1.29
  retrieving revision 1.30
  diff -u -r1.29 -r1.30
  --- jk_service.h  16 Feb 2005 15:09:21 -  1.29
  +++ jk_service.h  19 Feb 2005 10:54:49 -  1.30
  @@ -27,10 +27,10 @@
   #ifndef JK_SERVICE_H
   #define JK_SERVICE_H
   
  -#include jk_map.h
   #include jk_global.h
   #include jk_logger.h
   #include jk_pool.h
  +#include jk_map.h
   #include jk_uri_worker_map.h
   #include jk_msg_buff.h
   
  @@ -430,6 +430,9 @@
 const char *name,
 jk_logger_t *l);
   
  +void jk_init_ws_service(jk_ws_service_t *s);
  +
  +
   #ifdef __cplusplus
   }
   #endif  /* __cplusplus */
  
  
  
  1.29  +1 -3  jakarta-tomcat-connectors/jk/native/common/jk_util.h
  
  Index: jk_util.h
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_util.h,v
  retrieving revision 1.28
  retrieving revision 1.29
  diff -u -r1.28 -r1.29
  --- jk_util.h 17 Feb 2005 07:07:51 -  1.28
  +++ jk_util.h 19 Feb 2005 10:54:49 -  1.29
  @@ -137,8 +137,6 @@
   
   void jk_append_libpath(jk_pool_t *p, const char *libpath);
   
  -void jk_init_ws_service(jk_ws_service_t *s);
  -
   void jk_set_worker_def_cache_size(int sz);
   
   int jk_get_worker_def_cache_size(int protocol);
  
  
  

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

Logging (was: Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm DataSourceRealm.java JAASCallbackHandler.java JAASMemoryLoginModule.java JDBCRealm.java JNDIRealm.java RealmBase.java UserDatabaseRealm.java)

2005-02-19 Thread Remy Maucherat 
Jan Luehe wrote:
Remy,
Remy Maucherat wrote:
Jan Luehe wrote:
It's a little risky. We should use the container logger only while the 
classloader is initialized.

It's probably far from perfect ;)
Then how about RealmBase.authenticate()?
RealmBase.authenticate(String username, String credentials)
uses Container.getLogger(), whereas the other RealmBase.authenticate()
methods use LogFactory.getLog(). Shouldn't this be consistent?
This is where my confusion has stemmed from.
Well, yes, it's a problem. It's simple: as soon as the container is 
started, all the container logging should go to container.getLogger(), 
as it used to in Tomcat 4.x.

That was my idea.
If you agree, I can help make the inconsistent cases consistent.
Sure.
In parallel, I want to start a commons component about a j.u.logging 
implementation keyed per classloader (as seen in bug 33143; it may be 
expanded a little later to allow per classloader configuration).

I'm looking for committers for the proposal :)
Sounds interesting!
Actually, it's not a very interesting project ;)
The support for j.u.logging is bad at the moment, as there is no (to my 
knowledge) implementation of j.u.logging which can realistically be used 
in a server like Tomcat. I hope the core (log manager + rotatable 
logger) can fit inside a JAR smaller than c-l-api.

Before moving to commons (svn is scaring me ;) ), I think I should start 
putting the code together in j-t-c/juli (as mentioned, juli means Java 
Util Logging Implementation). Is that ok ? (and is the name ok ?)

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

DO NOT REPLY [Bug 33650] - Jasper performance for multiple files processing

2005-02-19 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=33650.
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=33650





--- Additional Comments From [EMAIL PROTECTED]  2005-02-19 12:09 ---
I'm currently hacking the jasper code to try to understand it as i'm not very 
familiar with the code and need to understand relations between objects and 
particulary how nodes are attached to each other, how dependant files are 
added and resolved, etc... it is a bit of obscure right now.

I'm not sure yet what would be the best place to cache those include: 
ParserController, Parser, .. and I think I need to make those Node classes 
mutable to get control over the parent and reset/set it easily.

I guess that for anyone familiar with the code, the view is pretty clear, mine 
is not at the moment.

My current testcase is the liferay portal sources (www.liferay.com), it needs 
a bit of doc to setup so it's not convenient for an independant testcase.

(NB: If I reported against 5.5.7 it is a mistake and is indeed 5.0.x)

-- 
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 33650] - Jasper performance for multiple files processing

2005-02-19 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=33650.
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=33650





--- Additional Comments From [EMAIL PROTECTED]  2005-02-19 13:47 ---
I made the mistake. As I said, this will not be addressed (as in -1 = veto) in
5.0.x.

-- 
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 33650] - Jasper performance for multiple files processing

2005-02-19 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=33650.
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=33650





--- Additional Comments From [EMAIL PROTECTED]  2005-02-19 14:00 ---
Ah ok, did not really understood it that way since I consider it is 'better to 
have a slow source generation than a *broken* source generation' in any 
situation and not just in 5.0.x :). Thus the qualification as 'enhancement'.

Nonetheless, I'm still trying to understand the code. I have made little 
progress as I realized I needed to delta the dependencies that are added 
through the Compiler instance if I want to cache the includeDirective 
fragment. I still need to find how are the taglibs evaluated to generate the 
java code.

At this time it looks like I could dream sort of a 10x improvement if this 
sort of caching can be done.


-- 
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 33650] - Jasper performance for multiple files processing

2005-02-19 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=33650.
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=33650





--- Additional Comments From [EMAIL PROTECTED]  2005-02-19 14:20 ---
My comment was indeed missing two words.

BTW, regardless of what your profiler says, I don't think you can get 10x.
However, now that the runtime performance is good, I'm interested in optimizing
compile times. One part has been done already by replacing the compiler by one
which decreses I/O (although the main benefit was to get compilation on the JRE
instead of the JDK).

-- 
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 33650] - Jasper performance for multiple files processing

2005-02-19 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=33650.
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=33650





--- Additional Comments From [EMAIL PROTECTED]  2005-02-19 14:47 ---
The compilation process is an external compilation process with ant javac 
task. I'm not using the internal one as for compilation within jspc it is 
often inappropriate and it is not flexible enough for file selection, 
classpath, and jvm settings.

I'm using this because many people tend to name jsp include with .jsp 
extensions and it will f* up blind attempt to compile from Jasper as they will 
be generated to java and it is invalid code by essence.

Workaround process is usually.
1. jspc (.jsp - .java)
2. delete generated static includes based on text content selectors (looking 
for unevaluated taglibs syntax for example)
3. javac everything

I'm myself always recommending people to name their includes as jspf (or .inc) 
extensions as it is:
- visually more convenient
- Jasper does not choke on it
- JSP editors will still understand the syntax (except for .inc)

I would really like to enhance this Ant jspc task but this is in my mile long 
todo list.

As for the speed up, I cannot see any reason why it should be 10x slower than 
java compilation (2-3s for a single jsp-java is huge). but really, all I'm 
missing is the taglibs evaluation and the process apparently should be able to 
fly

NB: For I/O it should not cost much to wrap BufferedOutputStream over the 
FileOutputStream. (I did not check if there was any change on this in cvs as I 
playing with 5.0.30 sources) but really it is peanuts compared to the zillions 
of I/O from constant loading and parsing of includes and tlds.

-- 
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 33650] - Jasper performance for multiple files processing

2005-02-19 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=33650.
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=33650





--- Additional Comments From [EMAIL PROTECTED]  2005-02-19 17:01 ---
FYI, putting a simple hashmap to cache the TLDs TreeNode to avoid the DOM 
parsing of TLDs in TagLibraryInfoImpl for each and every JSP brings the timing 
to 8 minutes instead of 12 on my 'testcase'. A 30% improvement.

-- 
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 33650] - Jasper performance for multiple files processing

2005-02-19 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=33650.
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=33650





--- Additional Comments From [EMAIL PROTECTED]  2005-02-19 17:09 ---
You still need to play nice with regular Jasper mode, when compilation occurs
on access. I would complain if there are memory leaks, and/or abusive memory
usage ;)

If code generation times go down significantly, and since JDT is used to compile
(fast and does very little I/O), I would assume it would encourage many people
to not bother with precompilation (hence the need to avoid leaks and huge memory
usage).

-- 
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 33650] - Jasper performance for multiple files processing

2005-02-19 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=33650.
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=33650





--- Additional Comments From [EMAIL PROTECTED]  2005-02-19 17:11 ---
(In reply to comment #7)
 FYI, putting a simple hashmap to cache the TLDs TreeNode to avoid the DOM 
 parsing of TLDs in TagLibraryInfoImpl for each and every JSP brings the 
 timing 
 to 8 minutes instead of 12 on my 'testcase'. A 30% improvement.

Nice improvement.

-- 
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: Logging (was: Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm DataSourceRealm.java JAASCallbackHandler.java JAASMemoryLoginModule.java JDBCRealm.java JNDIRealm.java RealmBase.java UserDatabaseRealm.java)

2005-02-19 Thread Bill Barker 
- Original Message - 
From: Remy Maucherat [EMAIL PROTECTED]
To: Tomcat Developers List tomcat-dev@jakarta.apache.org
Sent: Saturday, February 19, 2005 2:55 AM
Subject: Logging (was: Re: cvs commit: 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm 
DataSourceRealm.java JAASCallbackHandler.java JAASMemoryLoginModule.java 
JDBCRealm.java JNDIRealm.java RealmBase.java UserDatabaseRealm.java)


Jan Luehe wrote:
Remy,
Remy Maucherat wrote:
Jan Luehe wrote:
It's a little risky. We should use the container logger only while the 
classloader is initialized.

It's probably far from perfect ;)
Then how about RealmBase.authenticate()?
RealmBase.authenticate(String username, String credentials)
uses Container.getLogger(), whereas the other RealmBase.authenticate()
methods use LogFactory.getLog(). Shouldn't this be consistent?
This is where my confusion has stemmed from.
Well, yes, it's a problem. It's simple: as soon as the container is 
started, all the container logging should go to container.getLogger(), as 
it used to in Tomcat 4.x.

That was my idea.
Another option is to use something like:
 log = LogFactory.getLog(container.logName()+.RealmBase);
The output will usually go to the container log, but it allows you to only 
set the Realm to log as debug.


If you agree, I can help make the inconsistent cases consistent.
Sure.
In parallel, I want to start a commons component about a j.u.logging 
implementation keyed per classloader (as seen in bug 33143; it may be 
expanded a little later to allow per classloader configuration).

I'm looking for committers for the proposal :)
Sounds interesting!
Actually, it's not a very interesting project ;)
The support for j.u.logging is bad at the moment, as there is no (to my 
knowledge) implementation of j.u.logging which can realistically be used in 
a server like Tomcat. I hope the core (log manager + rotatable logger) can 
fit inside a JAR smaller than c-l-api.

Before moving to commons (svn is scaring me ;) ), I think I should start 
putting the code together in j-t-c/juli (as mentioned, juli means Java Util 
Logging Implementation). Is that ok ? (and is the name ok ?)
Welcome to j-t-c, Juli.
Rémy
-
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]

DO NOT REPLY [Bug 33650] - Jasper performance for multiple files processing

2005-02-19 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=33650.
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=33650





--- Additional Comments From [EMAIL PROTECTED]  2005-02-19 18:04 ---
 You still need to play nice with regular Jasper mode, when compilation
 occurs on access. I would complain if there are memory leaks, and/or abusive
 memory usage ;)

I think the cache needs to be enabled only in command line mode (batch 
compile). Otherwise it does not make much sense and it complicate things when 
you are development mode.

 I would assume it would encourage many people to not bother with
 precompilation 

It is totally different.

Pre-compiling your jsp is mostly a way to check that there is no syntax or 
configuration problems with your taglibs or jsp. You don't care much with a 
petstore webapp with 10 jsps that you can check manually at deployment time, 
but with hundred of thems, it is not something you can afford.

Assuming you have some QA dept or some automated robot to go through all your 
webpages, that's also useless to deliver something that does not even compile. 
So it's mostly a development thing and must be part of your process, and it 
should be part of the daily build as well of course. 

So if we can cut down this check from 12 to 1min, believe me I think some 
people would love it.

-- 
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.5.8 tagged, cut, uploaded...

2005-02-19 Thread Yoav Shapira 
... per the usual routine.  I'll give the mirrors some time to synch before I
make the official release announcement.

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

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

2005-02-19 Thread NormW 
Good morning,
AFAICT this is working fine with a socket timeout of 15. Neither 
/server-info/ or /status/ show the setting in use, but 15 is what's in 
the properties file and /server-info/ says that's the file in use.

Regards,
Norm
Mladen Turk wrote:
NormW wrote:
Good evening,
Can confirm a clean build for 2.1 and 2.0.53 Apache. Time is short now 
but will test them for basic ops in the morning. I assume these still 
need the socket_timeout at zero?

Well, new is_socket_connected implementation should be available
for netware too (that was the purpose after all).
Tell me if it works when you set the socket_timeout to a positive value.
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: Logging

2005-02-19 Thread Remy Maucherat 
Bill Barker wrote:
Jan Luehe wrote:
Remy,
Remy Maucherat wrote:
Jan Luehe wrote:
It's a little risky. We should use the container logger only while 
the classloader is initialized.

It's probably far from perfect ;)
Then how about RealmBase.authenticate()?
RealmBase.authenticate(String username, String credentials)
uses Container.getLogger(), whereas the other RealmBase.authenticate()
methods use LogFactory.getLog(). Shouldn't this be consistent?
This is where my confusion has stemmed from.
Well, yes, it's a problem. It's simple: as soon as the container is 
started, all the container logging should go to container.getLogger(), 
as it used to in Tomcat 4.x.

That was my idea.
Another option is to use something like:
 log = LogFactory.getLog(container.logName()+.RealmBase);
The output will usually go to the container log, but it allows you to 
only set the Realm to log as debug.
That seems like a good idea.
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

ThreadDeath with tomcat 5.5.7 and bouncycastle

2005-02-19 Thread Adam Jenkins 
Hi All,

I'm getting a really odd error when I try to init a ciphers (or any
other artifact for that matter) using BC as the provider in tomcat 5.5.7
(struts application).

The call is simply 

final Cipher rsaCipher = Cipher.getInstance(RSA/ECB/PKCS1Padding,
BC);

and I get the following:

java.lang.ThreadDeath
at
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1221)
at
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1181)
at java.security.Provider
$Service.getImplClass(Provider.java:1116)
at java.security.Provider
$Service.newInstance(Provider.java:1074)
at javax.crypto.Cipher.getInstance(DashoA12275)
at javax.crypto.Cipher.getInstance(DashoA12275)

The bouncy castle libraries are included in the classpath, and are being
initialized correctly in the servlet init with the call:

Security.addProvider( new BouncyCastleProvider());

JVM Details:
java version 1.5.0-rc
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-rc-b63)
Java HotSpot(TM) Client VM (build 1.5.0-rc-b63, mixed mode)

uname -r:
2.6.8-gentoo-r10

Anyone have any ideas?

Cheers
Adam


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

Re: ThreadDeath with tomcat 5.5.7 and bouncycastle

2005-02-19 Thread Adam Jenkins 
FYI

This seems to relate to tomcat bug 26372.

On Sun, 2005-02-20 at 09:00 +1100, Adam Jenkins wrote:
 Hi All,
 
 I'm getting a really odd error when I try to init a ciphers (or any
 other artifact for that matter) using BC as the provider in tomcat 5.5.7
 (struts application).
 
 The call is simply 
 
 final Cipher rsaCipher = Cipher.getInstance(RSA/ECB/PKCS1Padding,
 BC);
 
 and I get the following:
 
 java.lang.ThreadDeath
 at
 org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1221)
 at
 org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1181)
 at java.security.Provider
 $Service.getImplClass(Provider.java:1116)
 at java.security.Provider
 $Service.newInstance(Provider.java:1074)
 at javax.crypto.Cipher.getInstance(DashoA12275)
 at javax.crypto.Cipher.getInstance(DashoA12275)
 
 The bouncy castle libraries are included in the classpath, and are being
 initialized correctly in the servlet init with the call:
 
 Security.addProvider( new BouncyCastleProvider());
 
 JVM Details:
 java version 1.5.0-rc
 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-rc-b63)
 Java HotSpot(TM) Client VM (build 1.5.0-rc-b63, mixed mode)
 
 uname -r:
 2.6.8-gentoo-r10
 
 Anyone have any ideas?
 
 Cheers
 Adam
 
 
 -
 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]