cvs commit: jakarta-tomcat-connectors/jk/tools/reports tomcat_trend.pl

[glenn]

glenn   2002/12/30 20:19:31

  Modified:jk/tools/reports tomcat_trend.pl
  Log:
  Update for mod_jk log changes
  
  Revision  ChangesPath
  1.3   +5 -4  jakarta-tomcat-connectors/jk/tools/reports/tomcat_trend.pl
  
  Index: tomcat_trend.pl
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/tools/reports/tomcat_trend.pl,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- tomcat_trend.pl   16 Dec 2002 13:55:46 -  1.2
  +++ tomcat_trend.pl   31 Dec 2002 04:19:31 -  1.3
  @@ -127,6 +127,7 @@
   foreach( @logs ) {
  $logfile = $_;
  chomp($logfile);
  +   next if ( $logfile =~ /\.(bz2|gz|zip)$/ );
  @head = `head -1 $logfile`;
  ($mon, $day, $time, $year) = (split /\s+/,$head[0])[1..4];
  ($hour, $min, $sec) = split /:/,$time;
  @@ -228,7 +229,7 @@
if( $line =~ /\d\)\]: / ) {
   # Handle a mod_jk error
   # print "mod_jk error! " . scalar(localtime($logtime)) . " $line\n";
  -if( $line =~ /jk_tcp_socket_recvfull failed/ ) {
  +if( $line =~ /(jk_tcp_socket_recvfull failed|ERROR: Receiving from 
tomcat failed)/ ) {
  $Global{tomcat_full}++;
  $Interval{tomcat_full}++;
   } elsif( $line =~ /(ajp_process_callback - write failed|ERROR sending 
data to client. Connection aborted or network problems)/ ) {
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

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

[glenn]

glenn   2002/12/30 19:57:34

  Modified:catalina/src/share/org/apache/catalina/core
ApplicationFilterConfig.java
  Log:
  Wrap ServletFilter init with swallow output
  
  Revision  ChangesPath
  1.8   +19 -6 
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/ApplicationFilterConfig.java
  
  Index: ApplicationFilterConfig.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/ApplicationFilterConfig.java,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- ApplicationFilterConfig.java  22 Jul 2001 20:25:08 -  1.7
  +++ ApplicationFilterConfig.java  31 Dec 2002 03:57:34 -  1.8
  @@ -76,7 +76,7 @@
   import org.apache.catalina.Context;
   import org.apache.catalina.deploy.FilterDef;
   import org.apache.catalina.util.Enumerator;
  -
  +import org.apache.tomcat.util.log.SystemLogHandler;
   
   /**
* Implementation of a javax.servlet.FilterConfig useful in
  @@ -251,7 +251,20 @@
   // Instantiate a new instance of this filter and return it
   Class clazz = classLoader.loadClass(filterClass);
   this.filter = (Filter) clazz.newInstance();
  -filter.init(this);
  +if (context instanceof StandardContext &&
  +((StandardContext)context).getSwallowOutput()) {
  +try {
  +SystemLogHandler.startCapture();
  +filter.init(this);
  +} finally {
  +String log = SystemLogHandler.stopCapture();
  +if (log != null && log.length() > 0) {
  +getServletContext().log(log);
  +}
  +}
  +} else {
  +filter.init(this);
  +}
   return (this.filter);
   
   }
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

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

[glenn]

glenn   2002/12/30 19:57:20

  Modified:catalina/src/share/org/apache/catalina/core
ApplicationFilterConfig.java
  Log:
  Wrap ServletFilter init with swallow output
  
  Revision  ChangesPath
  1.4   +20 -5 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationFilterConfig.java
  
  Index: ApplicationFilterConfig.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationFilterConfig.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- ApplicationFilterConfig.java  16 Oct 2002 15:42:09 -  1.3
  +++ ApplicationFilterConfig.java  31 Dec 2002 03:57:19 -  1.4
  @@ -77,6 +77,8 @@
   import org.apache.catalina.deploy.FilterDef;
   import org.apache.catalina.util.Enumerator;
   import org.apache.catalina.security.SecurityUtil;
  +import org.apache.tomcat.util.log.SystemLogHandler;
  +
   
   /**
* Implementation of a javax.servlet.FilterConfig useful in
  @@ -253,7 +255,20 @@
   // Instantiate a new instance of this filter and return it
   Class clazz = classLoader.loadClass(filterClass);
   this.filter = (Filter) clazz.newInstance();
  -filter.init(this);
  +if (context instanceof StandardContext &&
  +((StandardContext)context).getSwallowOutput()) {
  +try {
  +SystemLogHandler.startCapture();
  +filter.init(this);
  +} finally {
  +String log = SystemLogHandler.stopCapture();
  +if (log != null && log.length() > 0) {
  +getServletContext().log(log);
  +}
  +}
  +} else {
  +filter.init(this);
  +}
   return (this.filter);
   
   }
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session ManagerBase.java

[billbarker]

billbarker2002/12/30 19:48:08

  Modified:catalina/src/share/org/apache/catalina/session
ManagerBase.java
  Log:
  Port patch from Tomcat 4.
  
  Revision  ChangesPath
  1.9   +16 -9 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/ManagerBase.java
  
  Index: ManagerBase.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/ManagerBase.java,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- ManagerBase.java  30 Dec 2002 02:40:04 -  1.8
  +++ ManagerBase.java  31 Dec 2002 03:48:08 -  1.9
  @@ -633,16 +633,23 @@
   session.setMaxInactiveInterval(this.maxInactiveInterval);
   String sessionId = generateSessionId();
   
  -synchronized (sessions) {
  -while (sessions.get(sessionId) != null)// Guarantee uniqueness
  -sessionId = generateSessionId();
  -}
  -
   String jvmRoute = getJvmRoute();
   // @todo Move appending of jvmRoute generateSessionId()???
   if (jvmRoute != null) {
   sessionId += '.' + jvmRoute;
  +session.setId(sessionId);
   }
  +synchronized (sessions) {
  +while (sessions.get(sessionId) != null){ // Guarantee uniqueness
  +sessionId = generateSessionId();
  +// @todo Move appending of jvmRoute generateSessionId()???
  +if (jvmRoute != null) {
  +sessionId += '.' + jvmRoute;
  +session.setId(sessionId);
  +}
  +}
  +}
  +
   session.setId(sessionId);
   
   return (session);
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session ManagerBase.java

[billbarker]

billbarker2002/12/30 19:45:48

  Modified:catalina/src/share/org/apache/catalina/session
ManagerBase.java
  Log:
  Make certain that the jvmRoute is attached to the session before comparing for 
uniqueness.
  
  Submitted by: Glenn Olander [EMAIL PROTECTED]
  
  Revision  ChangesPath
  1.16  +15 -9 
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/ManagerBase.java
  
  Index: ManagerBase.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/ManagerBase.java,v
  retrieving revision 1.15
  retrieving revision 1.16
  diff -u -r1.15 -r1.16
  --- ManagerBase.java  30 Dec 2002 02:36:26 -  1.15
  +++ ManagerBase.java  31 Dec 2002 03:45:48 -  1.16
  @@ -580,17 +580,23 @@
   session.setMaxInactiveInterval(this.maxInactiveInterval);
   String sessionId = generateSessionId();
   
  -synchronized (sessions) {
  -while (sessions.get(sessionId) != null)// Guarantee uniqueness
  -sessionId = generateSessionId();
  -}
  -
   String jvmRoute = getJvmRoute();
   // @todo Move appending of jvmRoute generateSessionId()???
   if (jvmRoute != null) {
   sessionId += '.' + jvmRoute;
   session.setId(sessionId);
   }
  +synchronized (sessions) {
  +while (sessions.get(sessionId) != null){ // Guarantee uniqueness
  +sessionId = generateSessionId();
  +// @todo Move appending of jvmRoute generateSessionId()???
  +if (jvmRoute != null) {
  +sessionId += '.' + jvmRoute;
  +session.setId(sessionId);
  +}
  +}
  +}
  +
   session.setId(sessionId);
   
   return (session);
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

two system running at the sam time

[perl is]

Hello,

Does anyone know how the two system running at the
same time -- http://sameaddress:8080 and 
http://sameaddress:2999 using same tomcat-apache web
server?

ex:  system1 using port 8080, system2 using port 2999,

Am I right to modify the server.xml file?











Thank you very much.

Ping
12/30/02

__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [PATCH] Re: ThreadPool

[Costin Manolache]

Remy Maucherat wrote:

> BTW, can't Linux 2.5/2.6 handle thousands of threads without any problem
> ? I remember reading an iterview of Ingo who said JVM performance and
> thread handling should be way better in 2.6.
> The idea is that there's nothing wrong with designing with threads in
> mind (I think that's good design), but the problem is that it doesn't
> quite work too well with most current OSes.

I'm pretty sure most OSes and apps will have problems with thousands of 
threads ( especially if a many are in RUN state ). They did a lot 
of changes in the linux scheduler - so hopefully thread handling improved
too.

I'm not very sure "normal" one request/thread will scale well for
1000s of concurent requests. That's an area where NIO would help
( select ). 

Squid ( and few other servers ) uses a single thread plus select plus
some tricks to deal with extremely high load. 



>> I agree.  We could pretty easily provide JMX-based operations for
>> everything that manager does (so that they're accessible from a JMX-based
>> client), and have the manager webapp itself just be wrappers around those
>> same MBean operations (for easy integration into non-JMX clients that can
>> perform HTTP requests).
> 
> I added (theorical) support for MC4J in 5.0 some time ago, BTW. The only
> problem is that there's a version clash with MX4J (Tomcat has to use an
> API which changed between MX4J 1.1 and 1.1.1 to start the JRMP
> connector, and MC4J only works with MX4J 1.1 at the moment).
> After hacking to get it to work, in order to test the feature, I noticed
> the start/stop/reload operations weren't declared on the model MBeans.

I added a reload for Context in the model mbean some time ago, and it
seemed to work.

For "remote" jmx - yes, MX4J RMI should work ( I was able to use it ),
but it's very tricky.

I think adding some simple operations in the ManagerServlet would be 
a good idea - just a get/set for a single attribute and a simple 
no-param method invocation would cover a lot of use cases.
And we can easily implement an JMX-over-http on top of this.


Costin




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [PATCH] Re: ThreadPool

[Lacoste (Frisurf)]

> BTW, can't Linux 2.5/2.6 handle thousands of threads without any problem 
> ? I remember reading an iterview of Ingo who said JVM performance and 
> thread handling should be way better in 2.6.

You're right, and Java should be one to benefit well from it.
But if the kernel period freeze lasts as long as the last one, we won't
have 2.6.0 before 10 months, and give it another 4-5 months before it
gets used in mainline distrib (last Debian uses 2.2 by default if I am
correct :))



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [PATCH] Re: ThreadPool

[Craig R. McClanahan]

On Mon, 30 Dec 2002, Costin Manolache wrote:

> Date: Mon, 30 Dec 2002 13:02:09 -0800
> From: Costin Manolache <[EMAIL PROTECTED]>
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Re: [PATCH] Re: ThreadPool
>
> Craig R. McClanahan wrote:
>
>
> > I like using the custom Ant tasks included with Tomcat 4.1 for
> > manipulation via manager, so that I can create a "reload" target.  If you
> > don't use Ant, it's just as easy to leave a browser window open to:
>
> I don't know if you looked at the JMX ant tasks in modeler.
>

I saw the commits, but not the code yet.  It's on my list of stuff to look
at.

> If we add some "simple remote JMX" feature in Manager - and implement
> the client side in the modeler ant tasks - it should be possible to
> control every aspect of tomcat from ant.
>
>

Sounds like a reasonable way to do things.

> Costin

Craig


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [PATCH] Re: ThreadPool

[Remy Maucherat]

Costin Manolache wrote:

Craig R. McClanahan wrote:




I like using the custom Ant tasks included with Tomcat 4.1 for
manipulation via manager, so that I can create a "reload" target.  If you
don't use Ant, it's just as easy to leave a browser window open to:



I don't know if you looked at the JMX ant tasks in modeler.

If we add some "simple remote JMX" feature in Manager - and implement
the client side in the modeler ant tasks - it should be possible to
control every aspect of tomcat from ant.


I think the client part should just use JRMP to talk to MX4J (or one of 
the others it provides).
Ok, I'm being lazy here; I just don't feel like inventing our own custom 
protocol when one already exists ;-)

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [PATCH] Re: ThreadPool

[Remy Maucherat]

Craig R. McClanahan wrote:


On Mon, 30 Dec 2002, Costin Manolache wrote:


I agree.

Is 'reloadabl' disabled by default ?



Yes ... at least in HEAD of 4.1 and 5.0.  I'm pretty sure it's always been
that way.


Yes, it's disabled by default.

BTW, can't Linux 2.5/2.6 handle thousands of threads without any problem 
? I remember reading an iterview of Ingo who said JVM performance and 
thread handling should be way better in 2.6.
The idea is that there's nothing wrong with designing with threads in 
mind (I think that's good design), but the problem is that it doesn't 
quite work too well with most current OSes.

BTW - another way to do reload-on-demand is using JMX ( the html interface
provided by either jmx-ri or mx4j - or any other jmx adaptor ). It may be
a good idea to make the manager webapp more powerfull - i.e. support generic
( simple ) get/set operations via JMX.




I agree.  We could pretty easily provide JMX-based operations for
everything that manager does (so that they're accessible from a JMX-based
client), and have the manager webapp itself just be wrappers around those
same MBean operations (for easy integration into non-JMX clients that can
perform HTTP requests).


I added (theorical) support for MC4J in 5.0 some time ago, BTW. The only 
problem is that there's a version clash with MX4J (Tomcat has to use an 
API which changed between MX4J 1.1 and 1.1.1 to start the JRMP 
connector, and MC4J only works with MX4J 1.1 at the moment).
After hacking to get it to work, in order to test the feature, I noticed 
the start/stop/reload operations weren't declared on the model MBeans.

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [PATCH] Re: ThreadPool

[Costin Manolache]

Craig R. McClanahan wrote:


> I like using the custom Ant tasks included with Tomcat 4.1 for
> manipulation via manager, so that I can create a "reload" target.  If you
> don't use Ant, it's just as easy to leave a browser window open to:

I don't know if you looked at the JMX ant tasks in modeler.

If we add some "simple remote JMX" feature in Manager - and implement
the client side in the modeler ant tasks - it should be possible to
control every aspect of tomcat from ant.


Costin



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [PATCH] Re: ThreadPool

[Craig R. McClanahan]

On Mon, 30 Dec 2002, Costin Manolache wrote:

>
> >> As for someone stoping the check for class modification at run time using
> >> an admin interface - what's wrong with that ?
> >
> > I don't see a problem with that, but I've stopped using "reloadable" at
> > all for my development -- reload-on-demand (via the manager webapp) is a
> > much more effective strategy IMHO.  And "reloadable" shouldn't be used on
> > a production server anyway.
>
> I agree.
>
> Is 'reloadabl' disabled by default ?

Yes ... at least in HEAD of 4.1 and 5.0.  I'm pretty sure it's always been
that way.

> Should we deprecate it ?
>

Or perhaps (in 5.0) convert it to an installable module rather than a core
feature?

> BTW - another way to do reload-on-demand is using JMX ( the html interface
> provided by either jmx-ri or mx4j - or any other jmx adaptor ). It may be
> a good idea to make the manager webapp more powerfull - i.e. support generic
> ( simple ) get/set operations via JMX.
>

I agree.  We could pretty easily provide JMX-based operations for
everything that manager does (so that they're accessible from a JMX-based
client), and have the manager webapp itself just be wrappers around those
same MBean operations (for easy integration into non-JMX clients that can
perform HTTP requests).

>
> Costin
>

Craig


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [PATCH] Re: ThreadPool

[Costin Manolache]

Craig R. McClanahan wrote:


>> It would actually be a pretty good solution IMO. A single thread checking
>> the files for modification in all contexts is better ( again IMO ) than
>> one thread per context. Same for checking sessions.
>>
>> The coding is a bit trickier ( and there are some issues related with DOS
>> and security ), but it may be worth it.
>>
> 
> A single thread checking for modified files is probably ok (although it
> will slow down the effective reload rate for individual apps), but I'd be
> particularly careful about trying to combine the session timeout
> processing of multiple webapps into one thread.  The problem is that
> application-level event handlers are called from this thread, and you
> really don't want an accidentally or maliciously coded webapp to start
> sleeping in one of these event handlers and thereby disable session
> timeout service for the entire Tomcat JVM.
> 
> It's possible that some way to time out the timeout event hander :-) could
> deal with this, but it will require some care.

I know - executing the even handlers can't be done on the expiration
thread.

The problem I'm trying to solve is scaling tomcat with the number of 
webapps. ( well, I'm not actually coding anything right now - there are 
more important issues :-)

A hosting site with 100s of apps ( some very infrequently used !) would
benefit a lot from having a single thread doing the checks for expiration.
A thread pool can be used to process the event handlers - with some 
safeguards to prevent DOS ( event handlers hunging the expiration thread).
It's not very difficult - let the thread pool grow to the max number of 
apps, and make sure a each context gets at most one thread for events. If
all apps behave, you'll have few threads doing the expiration and one doing
the check.

Regarding the delay - yes, it may be faster to have 100 threads doing 
nothing but expiration ( or modification ) check, one per context. However
it may be better to have 100 threads doing request processing and keep 
a single thread doing session maintainance. Java GC is done in a single 
thread too.

Anyway - I don't think this is a very urgent problem to solve.

>> As for someone stoping the check for class modification at run time using
>> an admin interface - what's wrong with that ?
> 
> I don't see a problem with that, but I've stopped using "reloadable" at
> all for my development -- reload-on-demand (via the manager webapp) is a
> much more effective strategy IMHO.  And "reloadable" shouldn't be used on
> a production server anyway.

I agree.

Is 'reloadabl' disabled by default ? Should we deprecate it ?

BTW - another way to do reload-on-demand is using JMX ( the html interface
provided by either jmx-ri or mx4j - or any other jmx adaptor ). It may be 
a good idea to make the manager webapp more powerfull - i.e. support generic 
( simple ) get/set operations via JMX. 


Costin
  




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Questions related to a port of the IIS-connector to Domino I plan to provide

[Costin Manolache]

Mladen Turk wrote:


> Seems that Domino 6 is using its own JVM (think that the one (IBM 1.3.1)
> comes with installation) and you have collision problem cause you are
> loading another JVM in the process.
> 
> There could be a problem with that if Domino already loads JVM, cause
> you can load JVM only once per process.  We'll need to change some calls
> to JNI to attach to already created JVM. I'll try to do that (for JK2).

Even if Domino hasn't loaded the IBM VM, it may have settings that would
load some of its jars.

I was able to run jk using IBM JDK1.3 on linux - it should work on windows
as well.

Having 2 VMs is very likely to cause problems :-)

( sorry, I can't help too much - I'm not very familiar with IIS and windows 
:-)

Costin 



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [PATCH] Re: ThreadPool

[Craig R. McClanahan]

On Mon, 30 Dec 2002, Joseph Shraibman wrote:

> Date: Mon, 30 Dec 2002 14:00:57 -0500
> From: Joseph Shraibman <[EMAIL PROTECTED]>
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> To: Tomcat Developers List <[EMAIL PROTECTED]>
> Subject: Re: [PATCH] Re: ThreadPool
>
> Craig R. McClanahan wrote:
> >
>
> >
> > I don't see a problem with that, but I've stopped using "reloadable" at
> > all for my development -- reload-on-demand (via the manager webapp) is a
> > much more effective strategy IMHO.  And "reloadable" shouldn't be used on
> > a production server anyway.
> >
> Is there a way to do that from the admin app as well?  If there is I
> haven't found it.
>

No, there's not, although in principle it would be possible to do this.

I like using the custom Ant tasks included with Tomcat 4.1 for
manipulation via manager, so that I can create a "reload" target.  If you
don't use Ant, it's just as easy to leave a browser window open to:

  http://localhost:8080/manager/reload?path=/myapp

and just click "Reload" whenever you want.  The first time you do this
it'll ask you to log on (via BASIC authentication) -- after that, it's
just a single click away.

Craig


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Duplicate session IDs?

[Bill Barker]

Good catch!
I'll apply the patch (if somebody doesn't beat me to it).

- Original Message -
From: "Glenn Olander" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Monday, December 30, 2002 8:05 AM
Subject: Re: Duplicate session IDs?


> fyi, the version he checked in contains a bug. It should append jvmRoute
> within
> the loop. It should look like this:
>
>String sessionId = generateSessionId();
>String jvmRoute = getJvmRoute();
>// @todo Move appending of jvmRoute generateSessionId()???
>if (jvmRoute != null) {
>sessionId += '.' + jvmRoute;
>}
>synchronized (sessions) {
>while (sessions.get(sessionId) != null){// Guarantee
> uniqueness
>sessionId = generateSessionId();
>if (jvmRoute != null) {
>sessionId += '.' + jvmRoute;
>}
>}
>}
>session.setId(sessionId);
>
>return (session);
>
> Remy Maucherat wrote:
>
> >Glenn Olander wrote:
> >
> >
> > I can also report that I've seen this happen when the system is
> > under load. We had a
> > user log in and gain access to another user's session. I'm sure
> > you can understand that
> > makes it a very serious bug for security-sensitive applications,
> > perhaps even deserving
> > some kind of security alert announcement.
> >
> > Tim's patch is robust and seems like a good candidate for
> > inclusion in the source
> > at the earliest opportunity since it ensures that no duplicate
> > session id's will be
> > commisioned (and ManagerBase already uses SecureRandom).
> >
> > Bill enabled the (ugly but very safe) code for getting rid of
> > duplicates. That will be in 4.1.x, at least for now.
>
>
>
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:

>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [PATCH] Re: ThreadPool

[Joseph Shraibman]

Craig R. McClanahan wrote:






I don't see a problem with that, but I've stopped using "reloadable" at
all for my development -- reload-on-demand (via the manager webapp) is a
much more effective strategy IMHO.  And "reloadable" shouldn't be used on
a production server anyway.


Is there a way to do that from the admin app as well?  If there is I haven't found it.


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

apache http server

[ravi appala]

Can anyone tell me, Tomcat works both HTTP and APP
server? do i need to download apache HTTPserver
seperately inorder to make Tomcat work as both APP and
HTTP server?

Thanks,
ravi

=
Thanks,
RAVI KUMAR APPALA

__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Questions related to a port of the IIS-connector to Domino I plan to provide

[Mladen Turk]

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]] 
> Sent: Monday, December 30, 2002 3:15 PM
> To: Tomcat Developers List
> Subject: RE: Questions related to a port of the IIS-connector 
> to Domino I plan to provide
> 
> 
> > Good, so if there is DSAPI, there shuld't be problems :).
> I think so and I am making progress, but hope someone can
> help me further with questions 2 and 3 :)
>

I'll try to be as much help as I could. I'm interested in JK2/Domino
implementation too.

 
> >
> > Looks to me like that you are using the wrong JVM.
> >
> The strange thing is, that this only happens when using 
> Domino 6 and not when using Domino 5 with the same JVM path 
> and DSAPI filter. I extracted the relevant code from 
> 'jk_jni_worker.c' and found the mentioned "JNI_CreateJavaVM" 
> call to be the problem. I tried it with JDK/JRE 1.3.1_06 and 
> JDK/JRE 1.4.1_01 and got the same results :( Can there be any 
> class-path or system-path related issues, which might be 
> handled different from Domino 5 to 6? Any other ideas or hints?
> 

Seems that Domino 6 is using its own JVM (think that the one (IBM 1.3.1)
comes with installation) and you have collision problem cause you are
loading another JVM in the process.

There could be a problem with that if Domino already loads JVM, cause
you can load JVM only once per process.  We'll need to change some calls
to JNI to attach to already created JVM. I'll try to do that (for JK2).

Do you have some tools (like Process Explorer from SysInternals?) so you
can tell if the JVM is already loaded and what is the version.

MT.


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [PATCH] Re: ThreadPool

[Craig R. McClanahan]

On Sun, 29 Dec 2002, Costin Manolache wrote:

>
> Michael wrote:
>
> >   Costin Manolache wrote:

[snips]

> >> IMO MonitorRunnable, the session expiration thread ( one per ctx )
> >> and the reloading thread ( one per ctx again )
> >
> > What classes are you referring to specifically? StandardManager &
> > WebappLoader?
>
> Yes, they add 2 threads per webapp. Which may limit the scalability with
> the number of deployed webapps ( 100 contexts -> 200 threads ).
>
> >> should all go away and
> >> be replaced by a single mechanism. Maybe the JMX timer ?
> >
> > I'd hate to think what would happen if someone stopped the timer
> > service. Also, using the event-driven approach to trigger maintenance
> > activities in foreground threads would be quirky coding, and may not
> > even be appropriate in classes that don't always have executing code.
>
> It would actually be a pretty good solution IMO. A single thread checking
> the files for modification in all contexts is better ( again IMO ) than
> one thread per context. Same for checking sessions.
>
> The coding is a bit trickier ( and there are some issues related with DOS
> and security ), but it may be worth it.
>

A single thread checking for modified files is probably ok (although it
will slow down the effective reload rate for individual apps), but I'd be
particularly careful about trying to combine the session timeout
processing of multiple webapps into one thread.  The problem is that
application-level event handlers are called from this thread, and you
really don't want an accidentally or maliciously coded webapp to start
sleeping in one of these event handlers and thereby disable session
timeout service for the entire Tomcat JVM.

It's possible that some way to time out the timeout event hander :-) could
deal with this, but it will require some care.

> As for someone stoping the check for class modification at run time using
> an admin interface - what's wrong with that ?

I don't see a problem with that, but I've stopped using "reloadable" at
all for my development -- reload-on-demand (via the manager webapp) is a
much more effective strategy IMHO.  And "reloadable" shouldn't be used on
a production server anyway.

Craig


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Duplicate session IDs?

[Eric Rescorla]

"Bill Barker" <[EMAIL PROTECTED]> writes:
> As far as I can tell, ManagerBase could really use your expertise on this.
> The current algorithm is really bad :-(
Ok. I've read the current code, which, as you say, is rather complicated.
As far as I can tell, here's how it works:

INITIALIZATION
(1) Generate an entropy value E which is the ManagerBase instance toString()ed.
(2) Get the current time T using system.getCurrentTimeMillis()
(3) Mix E and T using XOR, wrapping E appropriately if it's longer
T. [0]. Call the output S
(4) Generate a new SecureRandom() and seed it using setSeed(S)
If this fails, a new Random() is generated and seeded using
setSeed(S). [1]


SESSION ID GENERATION
(1) Fill a 16-byte buffer with Random data from the random generator.
(2) Digest the buffer (likely with MD5).
(3) Hexify the value [2]


SESSION CREATION
(1) Generate a session ID.
(2) If it already exists, go to (1).



So, what's wrong with this code:
(1) It's over-complicated. There's no need to hash the output
of SecureRandom()--especially when you look at SecureRandom
and see that it's hashes on the inside. :)
(2) The entropy source isn't very good. There are really two sources
of entropy, the initial time value and the toString() value
of ManagerBase.

The time value can generally be determined to within a few
minutes. So, if we say 10 minutes, then there is 16 bits of
entropy there.

I haven't tested it, but the toString() value is probably an
object handle of some kind. On FreeBSD with JDK 1.3, it looks
to be the class name followed by a 32-bit ID. Since the class
name is known, there are only 32 bits of entropy at best
(assuming that the IDs aren't predictable).

So, at best there are 48 bits of entropy. Not heartwarming.
An attacker can presumably exhaustively search the entire
RNG seed space with an effort of 2^48 ops.

That said, this algorithm shouldn't repeat. No matter how crappy the
seed is, cryptographically secure PRNGs (which SecureRandom supposedly
is) generate white output. If you're seeing repeats with this
algorithm, then something is very wrong. One possibility is that
you're actually falling back to Random, which, as I mentioned above,
the code allows for. It's possible you'd see more collisions with
such a PRNG, though they should still be pretty rare.

-Ekr


[0] Note that I haven't verified this algorithm.
[1] I don't know how often this happens.
[2] I haven't verified this code either.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Duplicate session IDs?

[Tim Funk]

This looks true by the looks of:
http://cvs.apache.org/viewcvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/ManagerBase.java?rev=1.15&content-type=text/vnd.viewcvs-markup

The while loop is looking for one session ID, and if JVM route is set, a 
different session ID is saved. (Since jvmRoute is attached AFTER dup check)

What is missing is the addition of jvmRoute to generateSessionId()

Attached is a patch against the HEAD of ManagerBase.java.

My original patch also provided a "debug" message and diff against 
LocalStrings.properties to log that a dup sessionId was created. I would 
be curious if that piece of code would ever be run. Personally - I doubt 
it. But we'd have proof that a duplicate sessionID was created with the 
debug message. If your want that patch instead - I can provide that on 
demand.



-Tim


Glenn Olander wrote:
fyi, the version he checked in contains a bug. It should append jvmRoute 
within
the loop. It should look like this:

  String sessionId = generateSessionId();
  String jvmRoute = getJvmRoute();
  // @todo Move appending of jvmRoute generateSessionId()???
  if (jvmRoute != null) {
  sessionId += '.' + jvmRoute;
  }
  synchronized (sessions) {
  while (sessions.get(sessionId) != null){// Guarantee 
uniqueness
  sessionId = generateSessionId();
  if (jvmRoute != null) {
  sessionId += '.' + jvmRoute;
  }
  }
  }
  session.setId(sessionId);

  return (session);
 
Index: ManagerBase.java
===
RCS file: 
/home/cvspublic/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/ManagerBase.java,v
retrieving revision 1.15
diff -r1.15 ManagerBase.java
138,139c138,139
< 
< 
---
> 
> 
293,294c293,294
< 
< 
---
> 
> 
588,593d587
< String jvmRoute = getJvmRoute();
< // @todo Move appending of jvmRoute generateSessionId()???
< if (jvmRoute != null) {
< sessionId += '.' + jvmRoute;
< session.setId(sessionId);
< }
693a688,693
> 
> String jvmRoute = getJvmRoute();
> if (jvmRoute != null) {
> result.append('.').append(jvmRoute);
> }
> 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 15406] - error-page responses are sent with wrong status code!

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15406

error-page responses are sent with wrong status code!





--- Additional Comments From [EMAIL PROTECTED]  2002-12-30 16:16 ---
Created an attachment (id=4297)
here is a patch against cvs head from 2002-12-30

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Duplicate session IDs?

[Glenn Olander]

fyi, the version he checked in contains a bug. It should append jvmRoute 
within
the loop. It should look like this:

  String sessionId = generateSessionId();
  String jvmRoute = getJvmRoute();
  // @todo Move appending of jvmRoute generateSessionId()???
  if (jvmRoute != null) {
  sessionId += '.' + jvmRoute;
  }
  synchronized (sessions) {
  while (sessions.get(sessionId) != null){// Guarantee 
uniqueness
  sessionId = generateSessionId();
  if (jvmRoute != null) {
  sessionId += '.' + jvmRoute;
  }
  }
  }
  session.setId(sessionId);

  return (session);

Remy Maucherat wrote:

Glenn Olander wrote:
 

I can also report that I've seen this happen when the system is
under load. We had a
user log in and gain access to another user's session. I'm sure
you can understand that
makes it a very serious bug for security-sensitive applications,
perhaps even deserving
some kind of security alert announcement.

Tim's patch is robust and seems like a good candidate for
inclusion in the source
at the earliest opportunity since it ensures that no duplicate
session id's will be
commisioned (and ManagerBase already uses SecureRandom).

Bill enabled the (ugly but very safe) code for getting rid of 
duplicates. That will be in 4.1.x, at least for now.



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-4.0 RELEASE-NOTES-4.1.txt

[glenn]

glenn   2002/12/30 08:06:09

  Modified:.RELEASE-NOTES-4.1.txt
  Log:
  Update release notes
  
  Revision  ChangesPath
  1.42  +5 -1  jakarta-tomcat-4.0/RELEASE-NOTES-4.1.txt
  
  Index: RELEASE-NOTES-4.1.txt
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/RELEASE-NOTES-4.1.txt,v
  retrieving revision 1.41
  retrieving revision 1.42
  diff -u -r1.41 -r1.42
  --- RELEASE-NOTES-4.1.txt 28 Dec 2002 02:20:43 -  1.41
  +++ RELEASE-NOTES-4.1.txt 30 Dec 2002 16:06:09 -  1.42
  @@ -718,6 +718,10 @@
JK 2 CoyoteHandler:
Fix NPE occurring in SSL mode.
   
  +[4.1.19] #10383
  + Ajp13
  + Fix hanging Ajp13Processor and web server request when invalid Cookie sent.
  + An HTTP status code 400 - Bad Request is now returned.
   
   
   Jasper Bug Fixes:
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 10383] - Specially crafted GET request causes the answering httpd process and the answering AJP13 processor to hang indefinitely

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10383

Specially crafted GET request causes the answering httpd process and the answering 
AJP13 processor to hang indefinitely

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 10383] - Specially crafted GET request causes the answering httpd process and the answering AJP13 processor to hang indefinitely

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10383

Specially crafted GET request causes the answering httpd process and the answering 
AJP13 processor to hang indefinitely

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2002-12-30 16:02 ---
I have just committed a patch that will return an HTTP status code of
400 - Bad Request when this happens.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4 Ajp13Processor.java

[glenn]

glenn   2002/12/30 08:00:32

  Modified:jk/java/org/apache/ajp/tomcat4 Ajp13Processor.java
  Log:
  Fix bug 10383 and remove stack trace from client abort type of exception
  
  Revision  ChangesPath
  1.10  +24 -7 
jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4/Ajp13Processor.java
  
  Index: Ajp13Processor.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4/Ajp13Processor.java,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- Ajp13Processor.java   7 Jun 2002 18:54:21 -   1.9
  +++ Ajp13Processor.java   30 Dec 2002 16:00:32 -  1.10
  @@ -441,9 +441,15 @@
   try {
   // set flag
   handlingRequest.set(true);
  -
  +
  +boolean bad_request = false;
  +
   // set up request
  -request.setAjpRequest(ajpRequest);
  +try {
  +request.setAjpRequest(ajpRequest);
  +} catch (IllegalArgumentException e) {
  +bad_request = true;
  +}
   request.setResponse(response);
   request.setStream(input);
   
  @@ -455,7 +461,11 @@
   logger.log("invoking...");
   }
   
  -connector.getContainer().invoke(request, response);
  +if (!bad_request) {
  +connector.getContainer().invoke(request, response);
  +} else {
  +response.sendError(400);
  +}
   
   if (debug > 0) {
   logger.log("done invoking, finishing request/response");
  @@ -468,6 +478,13 @@
   logger.log("finished handling request.");
   }
   
  +} catch (IOException ioe) {
  +// Normally this catches a socket Broken Pipe caused by the
  +// remote client aborting the request. mod_jk will close the
  +// socket on its side and the processor will get a socket EOF
  +// when it next tries to read from mod_jk, then recycle itself
  +// normally. Don't print the stack trace in this case.
  +logger.log("process: IOException " + ioe.getMessage());
   } catch (Throwable e) {
   logger.log("process: invoke", e);
   }
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 10383] - Specially crafted GET request causes the answering httpd process and the answering AJP13 processor to hang indefinitely

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10383

Specially crafted GET request causes the answering httpd process and the answering 
AJP13 processor to hang indefinitely

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |ASSIGNED



--- Additional Comments From [EMAIL PROTECTED]  2002-12-30 15:23 ---
Thanks for the excellent bug report and the patch.  
I have verified that the bug exists.
I am looking into the best way to handle exceptions when processing a request
with Ajp.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Duplicate session IDs?

[Remy Maucherat]

Glenn Olander wrote:

I can also report that I've seen this happen when the system is under 
load. We had a
user log in and gain access to another user's session. I'm sure you can 
understand that
makes it a very serious bug for security-sensitive applications, perhaps 
even deserving
some kind of security alert announcement.

Tim's patch is robust and seems like a good candidate for inclusion in 
the source
at the earliest opportunity since it ensures that no duplicate session 
id's will be
commisioned (and ManagerBase already uses SecureRandom).

Bill enabled the (ugly but very safe) code for getting rid of 
duplicates. That will be in 4.1.x, at least for now.

Experimentation on new and cleaner algorithms should happen in the 5.0.x 
branch first (and then it may be ported, although I'd say it shouldn't 
as the current code gets the job done relatively well and is tested).

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 14008] - Error in taglib iterator (with NESTED variable info)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14008

Error in taglib iterator (with NESTED variable info)

[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|Normal  |Critical
Summary|Error in taglib iterator|Error in taglib iterator
   ||(with NESTED variable info)



--- Additional Comments From [EMAIL PROTECTED]  2002-12-30 15:00 ---
See tc attached (it is war-file).
Running under the tomcat 4.0 it produces correct output, but under tomcat 4.1.x 
1st element is null.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 14008] - Error in taglib iterator

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14008

Error in taglib iterator





--- Additional Comments From [EMAIL PROTECTED]  2002-12-30 14:57 ---
Created an attachment (id=4296)
Test Case for Iteration Tag with NESTED Variable Info

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Duplicate session IDs?

[Glenn Olander]

I can also report that I've seen this happen when the system is under 
load. We had a
user log in and gain access to another user's session. I'm sure you can 
understand that
makes it a very serious bug for security-sensitive applications, perhaps 
even deserving
some kind of security alert announcement.

Tim's patch is robust and seems like a good candidate for inclusion in 
the source
at the earliest opportunity since it ensures that no duplicate session 
id's will be
commisioned (and ManagerBase already uses SecureRandom).


Eric Rescorla wrote:

The standard fix for this is to use a cryptographic pseudo-random
number generator, such as Java's SecureRandom. SecureRandom
automatically seeds itself from allegedly random system data.
the probability that two sufficiently long random numbers
(e.g. 16 bytes) will collide is vanishing. (E.g. with a 16-byte
session ID, you'd have to generate > 2^60 session IDs to have
a reasonable chance of collision.




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Questions related to a port of the IIS-connector to Domino I plan toprovide

[olaf . hahnl]

"Mladen Turk" <[EMAIL PROTECTED]> wrote on 30.12.2002 08:02:13:

> Good, so if there is DSAPI, there shuld't be problems :).
I think so and I am making progress, but hope someone can help me further
with questions 2 and 3 :)

>
> > For the moment I work with 5.0 for the following reasons.
> > Many organizations I work with have and will have Domino 5
> > servers around for quite some time and because I do have a
> > problem with the old jk1 connector with Domino 6. It produces
> > the following two errors during execution of the
> > "JNI_CreateJavaVM" call in jk_jni_worker.c - 'Entry point for
> > procedure " _JVM_GetCPMethodNameUTF@12" in DLL "jvm.dll"
> > could not be found' and afterwards 'Entry point for procedure
> > "_JVM_SupportsCX8@0" in DLL "jvm.dll" could not be found'. I
> > am not sure what causes the errors but I think it Domino 6
> > because with Domino 5 there are no problems at all. Any suggestions?
> >
>
> Looks to me like that you are using the wrong JVM.
>
The strange thing is, that this only happens when using Domino 6 and not
when using Domino 5 with the same JVM path and DSAPI filter. I extracted
the relevant code from 'jk_jni_worker.c' and found the mentioned
"JNI_CreateJavaVM" call to be the problem. I tried it with JDK/JRE 1.3.1_06
and JDK/JRE 1.4.1_01 and got the same results :( Can there be any
class-path or system-path related issues, which might be handled different
from Domino 5 to 6? Any other ideas or hints?

>
> MT.

Olaf



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-connectors/jk/xdocs/jk aphowto.xml

[glenn]

glenn   2002/12/30 06:16:54

  Modified:jk/xdocs/jk aphowto.xml
  Log:
  Update version numbers for apache in docs
  
  Revision  ChangesPath
  1.18  +8 -8  jakarta-tomcat-connectors/jk/xdocs/jk/aphowto.xml
  
  Index: aphowto.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/xdocs/jk/aphowto.xml,v
  retrieving revision 1.17
  retrieving revision 1.18
  diff -u -r1.17 -r1.18
  --- aphowto.xml   26 Nov 2002 16:12:03 -  1.17
  +++ aphowto.xml   30 Dec 2002 14:16:54 -  1.18
  @@ -875,16 +875,16 @@
   
   
   
  - /home/apache20/httpd-2.0.40 is the directory where the httpd-2.0 sources
  + /home/apache20/httpd-2.0.43 is the directory where the httpd-2.0 sources
   are located. 
  -./configure --with-apache=/home/apache20/httpd-2.0.40
  +./configure --with-apache=/home/apache20/httpd-2.0.43
   make
   Install the mod_jk library and other files in
  -/home/apache20/httpd-2.0.40/modules: 
  +/home/apache20/httpd-2.0.43/modules: 
   make install
It is not possible to configure Apache directly because the config.m4 of 
mod_jk must
   be added to the configure of httpd-2.0. 
  -cd /home/apache20/httpd-2.0.40
  +cd /home/apache20/httpd-2.0.43
   sh buildconf
   configure ... --with-mod_jk
   make
  @@ -898,15 +898,15 @@
   
   
   
  - /home/apache/apache_1.3.26 is the directory where the apache-1.3 sources
  + /home/apache/apache_1.3.27 is the directory where the apache-1.3 sources
   are located. 
  -./configure --with-apache=/home/apache/apache_1.3.26
  +./configure --with-apache=/home/apache/apache_1.3.27
   make
   Install the libjk library, mod_jk.c, includes and other files in
  -/home/apache/apache_1.3.26/src/modules/jk: 
  +/home/apache/apache_1.3.27/src/modules/jk: 
   make install
Configure in the Apache sources: 
  -cd /home/apache/apache_1.3.26
  +cd /home/apache/apache_1.3.27
   configure ... --enable-module=dir --disable-shared=dir \
 --activate-module=src/modules/jk/libjk.a \
 --disable-shared=jk
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-connectors/jk/native CHANGES.txt

[glenn]

glenn   2002/12/30 06:10:20

  Modified:jk/native CHANGES.txt
  Log:
  Update changes
  
  Revision  ChangesPath
  1.7   +6 -2  jakarta-tomcat-connectors/jk/native/CHANGES.txt
  
  Index: CHANGES.txt
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/CHANGES.txt,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- CHANGES.txt   16 Dec 2002 14:50:50 -  1.6
  +++ CHANGES.txt   30 Dec 2002 14:10:20 -  1.7
  @@ -1,6 +1,10 @@
   JAKARTA TOMCAT CONNECTORS (JK) CHANGELOG:-*-text-*-
   Last modified at [$Date$]
   
  +Changes with JK 1.2.3:
  +* Add JkAutoAlias to Apache 2.0
  +  [glenn]
  +
   Changes with JK 1.2.2:
   * tomcat_trend.pl updated script to support changed logging of 
 aborted requests
  @@ -28,4 +32,4 @@
 [hgomez]
   * Final patches to make JK iSeries compliant
 [hgomez]
  -  
  \ No newline at end of file
  +  
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 15612] - Tomcat4.1.18's JK2 connector occurs SocketTimeoutException

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15612

Tomcat4.1.18's JK2 connector occurs SocketTimeoutException

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2002-12-30 10:25 ---
Did you notice the JK 2 connector configuration changed in 4.1.16 ? If you use
the config from 4.1.12, it's normal that this happens.



(notice the connectionTimeout value)

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 15612] - Tomcat4.1.18's JK2 connector occurs SocketTimeoutException

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15612

Tomcat4.1.18's JK2 connector occurs SocketTimeoutException





--- Additional Comments From [EMAIL PROTECTED]  2002-12-30 10:21 
---
We see this too using downloaded binary mod_jk2-2.0.43.dll on Windows XP, 
Apache 2.0.43, jakarta-tomcat-4.1.17-LE-jdk14, Sun JDK 1.4.1_01

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Duplicate session IDs?

[Remy Maucherat]

Bill Barker wrote:

"Schnitzer, Jeff" <[EMAIL PROTECTED]> writes:

The standard fix for this is to use a cryptographic pseudo-random
number generator, such as Java's SecureRandom. SecureRandom
automatically seeds itself from allegedly random system data.
the probability that two sufficiently long random numbers
(e.g. 16 bytes) will collide is vanishing. (E.g. with a 16-byte
session ID, you'd have to generate > 2^60 session IDs to have
a reasonable chance of collision.




Nice to have you back Eric :-)

As far as I can tell, ManagerBase could really use your expertise on this.
The current algorithm is really bad :-(


Yes, it would be nice to have a new one for Tomcat 5.

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

(Tiny) help offer

[Christoph Seibert]

Hi there,

I just subscribed to tomcat-dev in order to discuss a nitpick
issue I found in Tomcat 4.1.18.

The intro page you get on starting Tomcat for the first time, that
is the index page of the ROOT webapp, does not have a correct
doctype and is therefore probably invalid HTML, though I must admit
I haven't actually checked this yet with a validator. In addition,
it uses layout tables, purely presentational elements and more
things that (not only) I consider to be bad web design practice.

I won't complain longer about this if (a) nobody else thinks this
is in the least important, or (b) you let me fix this. ;-) I consider
myself to have extensive knowledge in modern, standards-compliant HTML
writing, and would like to put this knowledge to use.

This way, I hope to get involved in the Tomcat project in a small
way. If this goes well, I'd start checking the other example pages
as well.

What do you think?

Ciao,
Christoph

--
--- Christoph Seibert   [EMAIL PROTECTED] ---
-- Farlon Dragon -==(UDIC)==-http://home.pages.de/~seibert/ --
- Who can possibly rule if no one-
- who wants to can be allowed to? - D. Adams, HHGTTG -


--
To unsubscribe, e-mail:   
For additional commands, e-mail: