Re: mod_jk glitches

2005-06-11 Thread Glenn Nielsen
The best way to make sure this bug gets fixed is to file a bug
report.

http://jakarta.apache.org/tomcat/bugreport.html

Regards,

Glenn

On Thu, Jun 09, 2005 at 11:18:28PM -0600, Tom Anderson wrote:
 I should have trusted my instincts and not my math.   A size_t (32  
 bits on most machines) rolls over at 4 GB, not 4 MB... d'oh!   So  
 this falls apart under a decent load, after a day or two in my  
 case.   I guess I'll be going back to the request method.   For me,  
 that should last about 1000 days before rolling over.
 
 I suggest that maybe doubles would be better for the read/write  
 bytes.   Although I still prefer a model that doesn't break at  
 rollover (reset all counters or moving averages for example).
 
 On Jun 9, 2005, at 8:13 PM, Tom Anderson wrote:
 
 At first I thought maybe it was because transferred, readed (sic)  
 and mytraffic are size_t and maybe one of them rolled over.   But  
 that would rollover at 4MB right?
 
--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--

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



Re: JK 1.2.13 TAGGED

2005-05-16 Thread Glenn Nielsen
Builds with Sun CC on Solaris 7/8 with Apache 2.0.54 and runs
with Tomcat 4.1.30.

Glenn

On Mon, May 16, 2005 at 09:57:44AM +0200, Mladen Turk wrote:
 Hi,
 
 JK 1.2.13 has been taggeded as we agreed last week,
 and the tarballs are available at:
 http://www.apache.org/dist/jakarta/tomcat-connectors/jk/source/jk-1.2.13/
 For those that don't have WIN32 compiler there is a set of binaries at:
 http://www.apache.org/dist/jakarta/tomcat-connectors/jk/binaries/win32/
 
 Please test as much as possible since we'll be aiming towards 1.2.14
 stable by simply rettaging if no bugs are present. In case they are, we
 can made few 1.2.14-rc-xx versions, as we done with 1.2.7.
 
 Further more, as agreed, we'll froze the 1.2 branch and only
 do a bug fixing, so please don't add any new features to that branch.
 
 Regards,
 Mladen.
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--

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



Re: [ANN/VOTE] JK 1.2.12 Released

2005-05-09 Thread Glenn Nielsen
Builds and runs on both Solaris 7  8 with Apache 2.0.54.

Glenn

On Sat, May 07, 2005 at 06:23:38PM +0200, Mladen Turk wrote:
 Hi,
 
 JK 1.2.12 has been released.
 This is mostly a bug fix release over JK 1.2.10 and fixes
 wc_close bug found in 1.2.11.  Please see the:
 http://jakarta.apache.org/tomcat/connectors-doc/changelog.html
 for a full list of changes.
 
 
 Sources can be found at:
 http://www.apache.org/dist/jakarta/tomcat-connectors/jk/source/jk-1.2.12/
 
 Binaries can be found at:
 http://www.apache.org/dist/jakarta/tomcat-connectors/jk/binaries/
 For now there is a set of win32 binaries:
 http://www.apache.org/dist/jakarta/tomcat-connectors/jk/binaries/win32/jk-1.2.12/
 and some linux binaries:
 http://www.apache.org/dist/jakarta/tomcat-connectors/jk/binaries/linux/jk-1.2.12/
 
 Feel free to add any other binaries for your favorite platform :)
 
 
 I would also like to make a stability VOTE at once
 (to keep the email noise at minimum).
 The vote will run for a week.
 
 
 [ ] Stable -- good build
 [ ] Alpha -- something serious is wrong: what is it?
 
 
 Regards,
 Mladen.
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--

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



mod_jk configure failover

2005-05-02 Thread Glenn Nielsen
Now that local worker is gone from mod_jk how can you configure
two app servers where you want one to be the primary and the
second one to be used for automatic failover only if the primary
is in an error state?

I tried setting lbfactor=1 on the primary and lbfactor=0 on the
failover worker but mod_jk sets lbfactor=1 if you configure a
value 1.

Thanks,

Glenn

--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--

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



Re: mod_jk configure failover

2005-05-02 Thread Glenn Nielsen
On Mon, May 02, 2005 at 06:17:50PM +0200, Mladen Turk wrote:
 Glenn Nielsen wrote:
 Now that local worker is gone from mod_jk how can you configure
 two app servers where you want one to be the primary and the
 second one to be used for automatic failover only if the primary
 is in an error state?
 
 Use 'disabled' flag for standby worker with 'redirect' to that worker.
 
 worker.w1.disabled=False
 worker.w1.redirect=w2
 
 worker.w2.disabled=True
 
 
 You can even redirect to the 'domain' or group of workers.

Thanks.

This seems to be a roundabout way to setup failover on error
and confuses what disabled=true means.

So let me get this straight, please correct me if I am wrong.
As of 1.2.11:

If disabled=true for a worker that worker can still receive
requests if:
  a) Another real worker has redirect={disabled worker}
  b) A request has a JSESSIONID with the disabled worker jvmroute

If you really want to disable a worker completely you need to use
the new stopped=True property?

Regards,

Glenn

--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--

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



Re: [ANN/VOTE] JK 1.2.11 Released

2005-04-29 Thread Glenn Nielsen
Builds and runs fine on both Solaris 7 and 8.

[X] Stable -- good build

Glenn

On Fri, Apr 29, 2005 at 10:18:50AM +0200, Mladen Turk wrote:
 Hi,
 
 JK 1.2.11 has been released
 This is mostly a bug fix release. Please see the:
 http://jakarta.apache.org/tomcat/connectors-doc/changelog.html
 for a full list of changes.
 
 
 Sources can be found at:
 http://www.apache.org/dist/jakarta/tomcat-connectors/jk/source/jk-1.2.11/
 
 Binaries can be found at:
 http://www.apache.org/dist/jakarta/tomcat-connectors/jk/binaries/
 For now there is a set of win32 binaries:
 http://www.apache.org/dist/jakarta/tomcat-connectors/jk/binaries/win32/jk-1.2.11/
 and some linux binaries:
 http://www.apache.org/dist/jakarta/tomcat-connectors/jk/binaries/linux/jk-1.2.11/
 
 Feel free to add any other binaries for your favorite platform :)
 
 
 I would also like to make a stability VOTE at once
 (to keep the email noise at minimum).
 The vote will run for about 72 hours as usual, perhaps more
 because it's Friday :).
 
 So...
 
 [ ] Stable -- good build
 [ ] Alpha -- something serious is wrong: what is it?
 
 
 
 Regards,
 Mladen.
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--

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



Re: JK Releasing 1.2.11/1.2.12

2005-04-26 Thread Glenn Nielsen
On Tue, Apr 26, 2005 at 12:57:12AM -0500, William A. Rowe, Jr. wrote:
 At 06:38 AM 4/25/2005, Mladen Turk wrote:
 Peter Rossbach wrote:
 that is a very shot time period for testing.
 
 Well, some of the things are really critical, so that's the reason.
 
 I think that 1.2.8/1.2.9 proved that haste creates this churn.
 
 Once 1.2.11 is ready, isn't it sufficient to point users at that
 test version for 2 - 4 weeks, until it truly settles out?  Nothing
 but critical/proven bug fixes between .11 and .12?
 
 If they couldn't get the code I'd agree with the fast turnaround,
 but once 1.2.11 exists, the point is, they can.

We may want to consider use of a 1.3 development branch for new
features. I have noticed that there have been significant new features
added between releases of mod_jk 1.2.

Then users can depend on the 1.2 production branch for a feature
stable backward compatible connector.

Then we can play around in the 1.3 branch with new features rather
than have feature creep in the production branch.

Regards,

Glenn

--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--

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



mod_jk 1.2.10 lb worker method Request|Trace not being configured

2005-04-04 Thread Glenn Nielsen
I tried setting the lb worker method=T (Traffic) and found that it was
not being honored.

A review of the code found that the jk_lb_get_method() function is never
being called to set the lb worker-lbmethod.

Is this feature just not enabled yet?

Regards,

Glenn

--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--

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



Re: [VOTE] Release JK 1.2.9 as stable

2005-03-29 Thread Glenn Nielsen
Builds using Sun CC on both Solaris 7  8, appears to run fine
with Apache 2.0.53. Have not tested load balancing.

Glenn

On Tue, Mar 29, 2005 at 12:55:48PM +0200, Mladen Turk wrote:
 Hi,
 
 There has been some improvements since
 1.2.9 beta version, so I suggest that you test
 the latest source code and binaries.
 
 Sources are at:
 http://www.apache.org/dist/jakarta/tomcat-connectors/jk/source/jk-1.2.9/
 
 binaries (WIN32 for now) can be found at:
 http://www.apache.org/dist/jakarta/tomcat-connectors/jk/binaries/win32/jk-1.2.9/
 (Binary contributions are welcome :).
 
 So,
 
 Vote 1.2.9 as stable:
 [  ] Yes
 [  ] No
 
 Regards,
 Mladen
 
 
 
 
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--

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



Re: Progress with Jk-dev

2005-03-14 Thread Glenn Nielsen
On Thu, Feb 17, 2005 at 08:22:13PM +1100, NormW wrote:
 Greetings All,
 Have the mod_jk 1.2.9-dev up and running on NetWare 6 and AP 2.1.3 but 
 doing much beyond a single worker is a little awkward. I can access the 
 Tomcat html manager web app without visible issues.

When I setup load balanced tomcats I number each manager context path
name in server.xml then setup the apache config so it can route to each
instance of tomcat using the following:

# Manager mounts for load balanced workers
JkMount /manager1/* tomcat1
JkMount /manager2/* tomcat2
JkMount /manager3/* tomcat3

That makes it easier to manage applications via http and apache.

Regards,

Glenn

--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--

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



Re: [VOTE] Propose Jim Jagielski and William A. Rowe as JakartaTomcatConnectors commiters

2005-03-14 Thread Glenn Nielsen
A bit late but hear are my hearty +1's for both Jim and Bill.

Glenn

On Wed, Feb 23, 2005 at 08:56:13PM +0100, Mladen Turk wrote:
 
 So...
 [x] Yes, Jim is really a cool guy.
 [ ] No way.
 
 and..
 [x] Sure, wellcome Bill.
 [ ] I think I know httpd better then him.

--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--

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



Re: tomcat_reports.pl

2005-02-07 Thread Glenn Nielsen
This should really go to the tomcat-dev@jakarta.apache.org list.

I have cc'd the list on this reply.

Comments nested below.

Regards,

Glenn

On Mon, Feb 07, 2005 at 03:24:36PM +0100, Finocchiaro, Michael (TSG PLM BusDev 
EMEA) wrote:
 
Glenn,
 
I saw your name as the author of some Tomcat perl scripts in the jk
source bundle. I am not sure of the correct forum to ask this question
so I am asking you directly. Very simply, what % options are
tomcat_reports.pl and tomcat_trend.pl looking for to create reports? I
have tried lots of different stuff but have not been able to get these
two tools working - and they seem to be the only way to investigate
how Tomcat is handling load. Any hints you can give me?
 
The two error messages I get are (and this is independent of which jk
source bundle I try - same result with 1.2.4, 1.2.6 and 1.2.8) - and
this is having installed GD and ActiveState Perl so that I should have
all the necessary pieces:
 
 
tomcat_reports.pl:
 
$gd not defined at tomcat_reports.pl line 221.

This means the graph plot failed. I have committed a bug fix
so that better error reporting happens when this occurs.

tomcat_trend.pl:
 
Day '' out of range 1..31 at tomcat_trend.pl line 93

This is a bug and has been fixed in CVS.

Both of these bug fixes can be obtained from the HEAD of the
jakarta-tomcat-connectors CVS repository.

 
Thanks,
 
Fino
 
 
 
Michael J Finocchiaro
TSG HPTC EMEA
Senior Consultant
http://[1]www.hp.com
 
   
 
[EMAIL PROTECTED]
+33 1 57 62 83 18 : Phone
+33 6 72 99 16 08 : Mobile
+33 1 42 46 13 54 : Fax
 
 References
 
Visible links
1. http://www.hp.com/
2. mailto:[EMAIL PROTECTED]
 
Hidden links:
3. http://www.hp.com/

Content-Description: Finocchiaro, Michael (HPTC EMEA).vcf

--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--

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



Re: Time for JkMountExclude in jk 1.2.x ?

2004-07-20 Thread Glenn Nielsen
Have you looked at using JkAutoAlias ?

On Tue, Jul 13, 2004 at 12:27:41PM +0200, Henri Gomez wrote:
 Hi to all,
 
 As many I'm puzzled in jk 1.2.x in some case :
 
 VirtualHost *:80
ServerName test101.mysys
DocumentRoot /www/sys101/htdocs
JkMount /* test-101
 /VirtualHost
 
 VirtualHost *:80
ServerName test102.mysys
DocumentRoot /www/sys102/htdocs
JkMount /* test-102
 /VirtualHost
 
 No imagine I want to have /home in test102.mysys mapped
 no more to tomcat but to local directory.
 
 VirtualHost *:80
ServerName test102.mysys
DocumentRoot /www/sys102/htdocs
JkMount /* test-102
 
Alias /home/ /www/sys102/home/
 
 
Directory /www/sys102/home
 Options Indexes MultiViews
 AllowOverride None
 Order allow,deny
 Allow from all
/Directory
 
 /VirtualHost
 
 There is no way to get http://test102.mysys/home goes to 
 /www/sys102/home local directory.
 
 What about adding support for JkMountExclude :
 
 VirtualHost *:80
ServerName test102.mysys
DocumentRoot /www/sys102/htdocs
JkMount /* test-102
JkMountExclude /home/*
 
Alias /home/ /www/sys102/home/
 
 
Directory /www/sys102/home
 Options Indexes MultiViews
 AllowOverride None
 Order allow,deny
 Allow from all
/Directory
 
 /VirtualHost
 
 
 These will prevent JkMount to forward /home/* to tomcat worker
 test-102.
 
 Thanks to comments.
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--

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



Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session JDBCStore.java PersistentManagerBase.java StandardManager.java StandardSession.java StoreBase.java

2004-05-01 Thread Glenn Nielsen
On Sat, May 01, 2004 at 02:26:34PM +0200, Remy Maucherat wrote:
 Glenn Nielsen wrote:
 Remy,
 
 I am sick and tired of your crap. For whatever reason you don't like
 any of my contributions.  You always try to find some way to justify
 a -1 of anything I contribute.  Frankly you are the main reason why
 I rarely contribute to Tomcat any more.  I just got tired of dealing
 with your shit. IMHO your interactions with people on this list and in
 bugzilla hurts the Tomcat community.
 
 I get the message. Frankly, I do not miss your contributions, as I have 
 always considered to be of average quality. You're not the only one who 
 hasn't appreciated working with the other.

Thats your opinion. Others can judge based on the major contributions
I have made. Such as implementing the Java Security Manager and the
major jasaper refactoring I did which boosted performance 25-33%.

 I'd like to point out that:
 - I do listen to feedback, so I have retracted my -1
 - I don't see how you can expect to be well recieved if you make an 
 unnanouced risky patch on a really mature branch after having been away 
 from months

As is normal for any feedback from you on my contributions, you rarely
provide any technical reason, you just make some characterization such as
risky patch without stating any valid technical reason why. Considering
that someone on the list immediately posted a message thanking me for
fixing some problems they were having with Sessions and JDBCStore your
knee-jerk reaction to -1 anything I contribute obviously hurts Tomcat.

 Of course, I will reflect this in light of my involvement with the 
 community. I think this can wait until the new release, which is a few 
 days away.

 And of course I did discusss this patch before I committed it.
 I posted a summary of the patch on Apr 20 which contained the
 same information as my commit message. From anyone else I would
 expect an apology, but not from an egotistical piece of shit like you.
 
 I somehow did miss the original message, so I apologize. Really a bad 
 mistake on my part, and I suggest using [PROPOSAL] to attract more 
 attention, and esp when proposing core changes.

It was posted with [PATCH] on the subject line. Apology accepted.

 Now, as for the rest of the paragraph, I obviously don't want to have to 
 interact with you anymore.

I dont' care what you think of me personally. But when your animosity
towards me impacts Tomcat I had to say something.

Regards,

Glenn

--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--

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



Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session JDBCStore.java PersistentManagerBase.java StandardManager.java StandardSession.java StoreBase.java

2004-05-01 Thread Glenn Nielsen
On Sat, May 01, 2004 at 06:39:15PM +0200, Remy Maucherat wrote:
 Glenn Nielsen wrote:
 I dont' care what you think of me personally. But when your animosity
 towards me impacts Tomcat I had to say something.
 
 I'm sure it fully justifies the egotistical piece of shit like you 
 comment ;)
 Jon is funny at least, but this is just pathetic.

Sometimes you have to jump on the table and rant a bit to grab
peoples attention.

I did go over the line with the statement you quoted above.
Please accept my apology for that one.

Glenn

--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--

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



Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session JDBCStore.java PersistentManagerBase.java StandardManager.java StandardSession.java StoreBase.java

2004-04-30 Thread Glenn Nielsen
On Fri, Apr 30, 2004 at 09:19:30PM +0200, Remy Maucherat wrote:
 [EMAIL PROTECTED] wrote:
 
 glenn   2004/04/30 12:15:26
 
   Modified:catalina/src/share/org/apache/catalina/session
 JDBCStore.java PersistentManagerBase.java
 StandardManager.java StandardSession.java
 StoreBase.java
   Log:
   The JDBCStore required a great deal of unnecessary db
   queries to manage the persisted data. This could severly
   impact its ability to scale to large numbers of sessions.
   
   1. When a JSESSIONID cookie was submitted with a request where
  the Session no longer exists multiple queries of the db occurred
  to try and load a persisted Session from the Store. I was
  seeing four attempts to load from the persistence store
  each request when a Session did not exist for a JSESSIONID.
   
  PersistentManagerBase swapIn() and swapOut() were patched
  to maintain a Hashtable of JSESSIONID's which do not exist
  in the Store so that they don't have to be checked multiple
  times.  Each checkInterval the Hashtable is cleared to
  prevent it from consuming too much memory.
   
   2. The StoreBase.processExpires() method triggers a load of
  each Session persisted to the db each checkInterval to
  perform its test to determine if the Session has expired.
  This incurred alot of overhead on the db, especially
  if there was a large amount of session data. The number
  of queries performed each checkInterval is 1 + number of
  sessions persisted to the db + number of expired sessions
  removed.
   
  The StoreBase.processExpires() method was overridden
  in JDBCStore.  The method in JDBCStore performs a
  query of the db to find only those Sessions which should
  be expired. The number of queries performed here is 1 +
  2 * the number of expired sessions (load then remove
  of expired session).
   
   3. JDBCStore.remove() is being called sometimes with a null
  sessionid String causing an unnecessary synchronization
  and db query.
   
  Added a check for a null sessionid String at top of method.
   
   Problems with expiring sessions have been reported numerous times.
   The basic problem is as follows, starting at time 0 min and with
   a max inactive interval of 30 minutes:
   
   00 min: First request, new session created, LastAccessedTime 0
   02 min: Second request, reuse session, LastAccessedTime 0
   31 min: Third request, reuse session, LastAccessedTime now 2
   33 min: Background manager thread expires session even though
   it has only been two minutes since the remote clients
   last request.
   
   The argument for not changing how this works is based on how
   the Servlet Spec defines Session.getLastAccessedTime().
   
   But I agree with all those who have complained about this
   behaviour that Tomcat session timeouts are buggy.
   
   So I came up with a compromise that still allows the
   HttpSession.getLastAccessedTime() to return the time of the
   previous request for those who are Servlet Spec purists.
   
   But internally sessions are expired when
   current time  last request + max inactive interval.
   
   When we do a major revision we should consider adding
   the StandardSession.getLastUsedTime() method to the
   org.apache.catalina.Session interface.
 
 And of course you don't discuss this before making the change ?
 This is the old branch, so this is clearly not acceptable.
 I have to -1 regardless of the possible merits.
 
 Rémy
 

Remy,

I am sick and tired of your crap. For whatever reason you don't like
any of my contributions.  You always try to find some way to justify
a -1 of anything I contribute.  Frankly you are the main reason why
I rarely contribute to Tomcat any more.  I just got tired of dealing
with your shit. IMHO your interactions with people on this list and in
bugzilla hurts the Tomcat community.

And of course I did discusss this patch before I committed it.
I posted a summary of the patch on Apr 20 which contained the
same information as my commit message. From anyone else I would
expect an apology, but not from an egotistical piece of shit like you.

And for those of you watching from the sidelines this is the first
time on any of the ASF/Tomcat lists I have attacked someone personally.
I have always tried to keep discussions technical rather than get
personal.

My warmest regards,

Glenn

--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--

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

Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session JDBCStore.java PersistentManagerBase.java StandardManager.java StandardSession.java StoreBase.java

2004-04-30 Thread Glenn Nielsen
Thanks for the words of encouragement.

Glenn

On Fri, Apr 30, 2004 at 03:27:00PM -0600, Tom Anderson wrote:
 I'm just a list lurker (so my opinion doesn't count) but I'm really 
 happy to see these fixes.   I have had to override JDBCStore and 
 PersistentManagerBase at my site to make similar fixes so that things 
 work acceptably (yes, I submitted patches but they weren't accepted).   
 Having these fixes in would allow me to upgrade to 4.1.x and get rid of 
 my old overridden classes.
 
 Thanks Glenn!
 ~Tom
 
 On Apr 30, 2004, at 1:15 PM, [EMAIL PROTECTED] wrote:
 
 glenn   2004/04/30 12:15:26
 
   Modified:catalina/src/share/org/apache/catalina/session
 JDBCStore.java PersistentManagerBase.java
 StandardManager.java StandardSession.java
 StoreBase.java
   Log:
   The JDBCStore required a great deal of unnecessary db
   queries to manage the persisted data. This could severly
   impact its ability to scale to large numbers of sessions.
 
   1. When a JSESSIONID cookie was submitted with a request where
  the Session no longer exists multiple queries of the db occurred
  to try and load a persisted Session from the Store. I was
  seeing four attempts to load from the persistence store
  each request when a Session did not exist for a JSESSIONID.
 
  PersistentManagerBase swapIn() and swapOut() were patched
  to maintain a Hashtable of JSESSIONID's which do not exist
  in the Store so that they don't have to be checked multiple
  times.  Each checkInterval the Hashtable is cleared to
  prevent it from consuming too much memory.
 
   2. The StoreBase.processExpires() method triggers a load of
  each Session persisted to the db each checkInterval to
  perform its test to determine if the Session has expired.
  This incurred alot of overhead on the db, especially
  if there was a large amount of session data. The number
  of queries performed each checkInterval is 1 + number of
  sessions persisted to the db + number of expired sessions
  removed.
 
  The StoreBase.processExpires() method was overridden
  in JDBCStore.  The method in JDBCStore performs a
  query of the db to find only those Sessions which should
  be expired. The number of queries performed here is 1 +
  2 * the number of expired sessions (load then remove
  of expired session).
 
   3. JDBCStore.remove() is being called sometimes with a null
  sessionid String causing an unnecessary synchronization
  and db query.
 
  Added a check for a null sessionid String at top of method.
 
   Problems with expiring sessions have been reported numerous times.
   The basic problem is as follows, starting at time 0 min and with
   a max inactive interval of 30 minutes:
 
   00 min: First request, new session created, LastAccessedTime 0
   02 min: Second request, reuse session, LastAccessedTime 0
   31 min: Third request, reuse session, LastAccessedTime now 2
   33 min: Background manager thread expires session even though
   it has only been two minutes since the remote clients
   last request.
 
   The argument for not changing how this works is based on how
   the Servlet Spec defines Session.getLastAccessedTime().
 
   But I agree with all those who have complained about this
   behaviour that Tomcat session timeouts are buggy.
 
   So I came up with a compromise that still allows the
   HttpSession.getLastAccessedTime() to return the time of the
   previous request for those who are Servlet Spec purists.
 
   But internally sessions are expired when
   current time  last request + max inactive interval.
 
   When we do a major revision we should consider adding
   the StandardSession.getLastUsedTime() method to the
   org.apache.catalina.Session interface.
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--

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



Re: wrong timeIdel value in StandardSession

2004-04-27 Thread Glenn Nielsen
The test needs to be updated to test for the correct
behaviour now that the bug is fixed. :-)

BTW, I did post a proposed patch which fixes this bug
and improves performance of the JDBCStore.  No one
has replied.

Regards,

Glenn

On Mon, Apr 26, 2004 at 10:37:08PM -0700, Amy Roh wrote:
 Bill Barker wrote:
 - Original Message - 
 From: Amy Roh [EMAIL PROTECTED]
 To: Tomcat Developers List [EMAIL PROTECTED]
 Sent: Monday, April 26, 2004 6:07 PM
 Subject: wrong timeIdel value in StandardSession
 
 
 
 The following patch causes regression where sessions don't expire when it
 should.  I have a test app that does refresh every 70 sec.  When I set
 timeout to 2 minute - the session *never* expires.
 
 
 
 I see the change to be not so much a regression as a bug-fix :).  Your app
 is accessing the session every 70 sec, so the session is never idle for the
 required 2 min to allow it to expire.
 
 I see on Remy's commit that Ths patch needs to be tested for possible 
 regressions.  The test jsp actually checks if the session expired after 
 timeout and alerts when refreshed.  I am attaching the jsp.
 
 
 
 
 cvs diff -r 1.26 -r 1.27 StandardSession.java
 
 587c587
  int timeIdle = (int) ((timeNow - lastAccessedTime) / 1000L);
 ---
 
int timeIdle = (int) ((timeNow - thisAccessedTime) / 1000L);
 
 
 I have added some debugging statements and found the following.
 
 setMaxInactiveInterval 120
 timeIdle now 0
 timeIdle before 0
 timeIdle now 36
 timeIdle before 36
 timeIdle now 116
 timeIdle before 186
 WOULD HAVE EXPIRED WITH OLD TIMEIDLE
 timeIdle now 70
 timeIdle before 70
 timeIdle now 0
 timeIdle before 70
 timeIdle now 26
 timeIdle before 96
 timeIdle now 70
 timeIdle before 140
 WOULD HAVE EXPIRED WITH OLD TIMEIDLE
 timeIdle now 0
 timeIdle before 70
 timeIdle now 16
 timeIdle before 86
 timeIdle now 70
 timeIdle before 140
 WOULD HAVE EXPIRED WITH OLD TIMEIDLE
 timeIdle now 0
 timeIdle before 70
 timeIdle now 6
 timeIdle before 76
 timeIdle now 66
 timeIdle before 137
 WOULD HAVE EXPIRED WITH OLD TIMEIDLE
 timeIdle now 70
 timeIdle before 140
 WOULD HAVE EXPIRED WITH OLD TIMEIDLE
 timeIdle now 0
 timeIdle before 70
 timeIdle now 56
 timeIdle before 127
 WOULD HAVE EXPIRED WITH OLD TIMEIDLE
 
 Let me know what you think
 
 Thanks,
 Amy
 
 
 
 I propose to revert the patch.
 
 
 I'm -1 on reverting unless you can explain why you think that the previous
 behavior is correct wrt the spec.  And, no, the fact that this bug has been
 in every version of Tomcat back to at least 3.2.x isn't good enough ;-).
 
 
 
 Thanks,
 Amy
 
 
 -
 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]
 


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--

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



[PATCH] HttpSession handling

2004-04-20 Thread Glenn Nielsen
 Peltoniemi
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--
Index: JDBCStore.java
===
RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/JDBCStore.java,v
retrieving revision 1.12
diff -u -r1.12 JDBCStore.java
--- JDBCStore.java  20 Mar 2004 10:57:18 -  1.12
+++ JDBCStore.java  20 Apr 2004 14:30:26 -
@@ -201,6 +201,11 @@
  */
 protected PreparedStatement preparedLoadSql = null;
 
+/**
+ * Variable to hold the codeprocessExpires()/code prepared statement.
+ */
+protected PreparedStatement preparedExpiresSql = null;
+
 // - Properties
 
 /**
@@ -630,6 +635,11 @@
  * @exception IOException if an input/output error occurs
  */
 public void remove(String id) throws IOException {
+
+if (id == null) {
+return;
+}
+
 String removeSql =
 DELETE FROM  + sessionTable +  WHERE  + sessionIdCol +
  = ?  AND  + sessionAppCol +  = ?;
@@ -742,7 +752,7 @@
 preparedSaveSql.setBinaryStream(3, in, size);
 preparedSaveSql.setString(4, session.isValid()?1:0);
 preparedSaveSql.setInt(5, session.getMaxInactiveInterval());
-preparedSaveSql.setLong(6, session.getLastAccessedTime());
+preparedSaveSql.setLong(6, 
((StandardSession)session).getLastUsedTime());
 preparedSaveSql.execute();
 } catch(SQLException e) {
 log(sm.getString(getStoreName()+.SQLException, e));
@@ -769,6 +779,101 @@
 // - Protected Methods
 
 /**
+ * Called by our background reaper thread to check if Sessions
+ * saved in our store are subject of being expired. If so expire
+ * the Session and remove it from the Store.
+ *
+ */
+protected void processExpires() {
+
+if(!started) {
+return;
+}
+
+String expiresSql =
+SELECT  + sessionIdCol +  FROM  + sessionTable +
+ WHERE  + sessionAppCol +  = ? AND ?  ( +
+sessionLastAccessedCol +  + ( + sessionMaxInactiveCol +
+*1000));
+
+ResultSet rst = null;
+String keys[] = null;
+long timeNow = System.currentTimeMillis();
+
+synchronized(this) {
+Connection _conn = getConnection();
+
+if(_conn == null) {
+return;
+}
+
+try {
+if(preparedExpiresSql == null) {
+preparedExpiresSql = _conn.prepareStatement(expiresSql);
+}
+
+preparedExpiresSql.setString(1, getName());
+preparedExpiresSql.setLong(2,timeNow);
+rst = preparedExpiresSql.executeQuery();
+ArrayList tmpkeys = new ArrayList();
+if (rst != null) {
+while(rst.next()) {
+tmpkeys.add(rst.getString(1));
+}
+}
+keys = (String[]) tmpkeys.toArray(new String[tmpkeys.size()]);
+} catch(SQLException e) {
+log(sm.getString(getStoreName()+.SQLException, e));
+keys = new String[0];
+} finally {
+try {
+if(rst != null) {
+rst.close();
+}
+} catch(SQLException e) {
+;
+}
+
+release(_conn);
+}
+}
+
+for (int i = 0; i  keys.length; i++) {
+try {
+StandardSession session = (StandardSession) load(keys[i]);
+if (session == null) {
+continue;
+}
+if (!session.isValid()) {
+continue;
+}
+int maxInactiveInterval = session.getMaxInactiveInterval();
+if (maxInactiveInterval  0) {
+continue;
+}
+int timeIdle = // Truncate, do not round up
+(int) ((timeNow - ((StandardSession)session).getLastUsedTime()) / 
1000L);
+if (timeIdle = maxInactiveInterval) {
+if ( ( (PersistentManagerBase) manager).isLoaded( keys[i] )) {
+// recycle old

Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves RequestFilterValve.java

2004-04-15 Thread Glenn Nielsen
On Wed, Apr 14, 2004 at 03:04:51PM -0500, Jess Holle wrote:
 Jan Luehe wrote:
 
 Sandy McArthur wrote:
 
 Does this mean J2SE 1.3 support is no more?
 
 On Apr 14, 2004, at 1:45 PM, [EMAIL PROTECTED] wrote: \
 
   Log:
   Added support for exception chaining.
   +iae.initCause(e);
 
 If there is a strong desire to maintain BC with J2SE 1.3,
 I'll resort to the JdkCompat mechanism, but both Remy and Jess
 voiced (strongly in the case of Jess) opinions that there was no need
 for it.
 
 Though I strongly feel Java 2 v1.3.1 is too old to bother with it (and 
 that those who are still stuck back on it for some strange reason can 
 stick with older versions of Tomcat as well), I do believe a statement 
 that this and future versions of Tomcat shall require Java 2 v1.4 or 
 higher should accompany the first public release after any change 
 requiring Java 2 v1.4 for basic functionality.

I don't think the minimum JVM requirement should be changed between
minor releases.  What about those who for whatever reason can't
move to java 1.4 yet but need a Tomcat upgrade path for bug fixes, etc.?

Regards,

Glenn

--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--

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



Re: TC evolment

2004-04-01 Thread Glenn Nielsen
On Thu, Apr 01, 2004 at 12:04:35PM +0100, [EMAIL PROTECTED] wrote:
   -Original Message-
   From: Henri Gomez
I think that we need to change the thinking perspective 
   from TC being 
a 'helper' to TC being a 'workhorse'.
Interesting idea Mladen.
   Next idea.
   
   If we drop Apache 2.0 support we need to have jk/jk2 jobs 
   done somewhere  :
   What about Tomcat 5  Coyote as a ajp13 dispatcher with 
   advances and fine tuning rules, which could be updated in 
   real time in via JMX ?
  
  
  Yes something like that, It will allow mod_jk2 lb features and header
  preproc, but in pure Java, and it'll need to expose some kind 
  of the API,
  usable from native code.
  Having that in Java will allow dynamic config either using 
  JMX or some other
  technology.
  Will it use ajp13 as a messaging protocol? I don't know yet.
  
  MT.
 
 Hi All,
 
 Just thought I'd chip in!  Please feel free to ignore me.
 
 I use tomcat exclusively behind apache.  This is for performance reasons
 both as a proxy for slow clients (releasing relatively expensive tomcat
 resources) and as a static content server.
 
 We use apache to control our URL space and serve all sorts of content from
 all sorts of servers.  In many instances tomcat, or jboss or any other app
 server does not have the control over the URL/Request that apache gives us
 without allot of custom coding.  We use mod_rewrite, mod_proxy, php,
 mod_perl, mod_some_auth_module.
 
 I have not benchmarked it but I would be surprised it tomcat was as good as
 apache in an SSL environment.
 
 Just my 2 pence worth, to defend us flat earth people that still use Apache
 (mostly 1.3.x as well) in front of tomcat for lots of quite sensible
 reasons.
 
 I do agree that a lot of tomcats are stand alone and that these can be quite
 usefully setup without apache is a valid one, but not an exclusively so.
 
 Greg
 
 ps I still see an 80/20 rule of 80% static content, 20% dynamic both in
 traffic and war file content.   Not to say the 20% does not involve a lot of
 processing to produce!


I couldn't have said it any better.

As an example.  I run a SOAP server with Tomcat Standalone which uses
HTTPS for the transport.  I recently switched to PureTLS using a JNI
plugin so that OpenSSL libs were used instead of java byte code for
SSL.  The boost in performance was amazing. 10x faster.

Glenn

--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--

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



Re: [Vote] Guenter Knauf as commiter

2004-03-18 Thread Glenn Nielsen
On Thu, Mar 18, 2004 at 10:00:37AM +0100, Henri Gomez wrote:
 
 Well there is now at least 4 persons on this list which track http-dev, 
 Guenter, Mladen, Jean-Frederic and I.

I also track httpd-dev. :-)

--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--

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



Re: [Vote] Guenter Knauf as commiter

2004-03-17 Thread Glenn Nielsen
+1

On Wed, Mar 17, 2004 at 09:41:45AM +0100, Henri Gomez wrote:
 Hi to all,
 
 jk2 2.0.4 seems in a good shape and I'd like to thanks all of
 you commiter, and tomcat-dev members for your feedback, patches
 and time.
 
 I'd like to see Guenter Knauf promoted to commiter since he
 provided us may fine patches on jk2 and help make this release
 happen.
 
 We need more and more people involved in the native side of
 jakarta-tomcat-connectors and Guenter show us these lasts week
 that he's a good candidate.
 
 
 Vote please, he's got of course my +1.
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--

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



Re: jk2 new shmem using APR

2004-03-17 Thread Glenn Nielsen
One thing I forgot to mention is that when using the worker MPM
and mod_jk with Tomcat it helps reduce Tomcat overhead by reducing
the number of Connectors Tomcat requires due to mod_jk being
able to use a cached pool of connectors to Tomcat per process.

This really helped Tomcat scale better.  From requiring 500
Connectors to Tomcat with Apache 1.3 we now rarely need more
than 50 connectors to Tomcat with Apache 2.

Regards,

Glenn

On Wed, Mar 17, 2004 at 08:25:59AM -0800, Paul Rasmussen wrote:
 Thanks a lot for this synopsis Glenn.  Obviously I am also considering whether 
 I should recommmend moving to Apache2 to our team.
 
 - paul r.
 
 In message [EMAIL PROTECTED]you write:
 On Tue, Mar 16, 2004 at 02:48:26PM -, [EMAIL PROTECTED] wrote:
   Greg,
  As an aside our team will be looking at apache2 and tomcat5 sooner rather
  than later as it would appear that more development effort is taking place
  on these platforms.  However balancing lots of apps and infrastructure
  upgrades and testing with day to day support means this will not happen
  soon.
 
 I went through the process of upgrading our servers to Apache2 over
 the last 9 months. These are Sun servers running Solaris and using
 the Apache 2 worker MPM.  There are alot of advantages to upgrading.
 My testing found Apache 2 to require a great deal fewer system resources
 (CPU,memory) when using the worker MPM and be much more scaleable.
 I also like the way filters work. You can now have Tomcat generate HTML
 with SSI which mod_include can then parse. This can help scaling for
 Tomcat.  We use it with Tomcat4 and mod_jk 1.2.5, both are working very
 reliably for us.
 
 I did run into a number of problems at first. Most of them were
 Solaris specific.  And some bugs which caused problems. I ended
 up learning a whole lot more about apache internals than I really
 wanted to, and even submitted a number of patches which got rolled
 into later releases.
 
 All in all it is working pretty well for us but we still get some
 core dumps once in a while, nothing that causes apache to completely
 fail though. We do have one nasty bug we hope the 2.0.49 release will
 fix.  That is a runaway apache process which consumes all memory on
 the server.  That was pretty nasty until we used ulimit on solaris
 to limit the size of the data and virtual memory segments for apache
 processes. Now the infrequent times this bug is triggered the apache
 process core dumps when it hits these memory limits rather than 
 causing general failures on the server due to exhausing all physical
 and virtual memory.
 
 The biggest effort had to be put into making sure all the third
 party apache modules we use were thread safe. This included patches
 to mod_jk 1.2 to fix a few thread safe problems. The mod_jk 1.2.5
 includes all these patches.
 
 All in all it was worth the effort, 9 months later it should be
 easier for someone with a similar environment to mine to upgrade
 to apache 2.
 
 Regards,
 
 Glenn
 
 --
 Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
 MOREnet System Programming   |  * if iz ina coment.  |
 Missouri Research and Education Network  |  */   |
 --
 
 -
 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]
--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--

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



Re: jk2 new shmem using APR

2004-03-16 Thread Glenn Nielsen
On Tue, Mar 16, 2004 at 02:48:26PM -, [EMAIL PROTECTED] wrote:
  Greg,
 As an aside our team will be looking at apache2 and tomcat5 sooner rather
 than later as it would appear that more development effort is taking place
 on these platforms.  However balancing lots of apps and infrastructure
 upgrades and testing with day to day support means this will not happen
 soon.

I went through the process of upgrading our servers to Apache2 over
the last 9 months. These are Sun servers running Solaris and using
the Apache 2 worker MPM.  There are alot of advantages to upgrading.
My testing found Apache 2 to require a great deal fewer system resources
(CPU,memory) when using the worker MPM and be much more scaleable.
I also like the way filters work. You can now have Tomcat generate HTML
with SSI which mod_include can then parse. This can help scaling for
Tomcat.  We use it with Tomcat4 and mod_jk 1.2.5, both are working very
reliably for us.

I did run into a number of problems at first. Most of them were
Solaris specific.  And some bugs which caused problems. I ended
up learning a whole lot more about apache internals than I really
wanted to, and even submitted a number of patches which got rolled
into later releases.

All in all it is working pretty well for us but we still get some
core dumps once in a while, nothing that causes apache to completely
fail though. We do have one nasty bug we hope the 2.0.49 release will
fix.  That is a runaway apache process which consumes all memory on
the server.  That was pretty nasty until we used ulimit on solaris
to limit the size of the data and virtual memory segments for apache
processes. Now the infrequent times this bug is triggered the apache
process core dumps when it hits these memory limits rather than 
causing general failures on the server due to exhausing all physical
and virtual memory.

The biggest effort had to be put into making sure all the third
party apache modules we use were thread safe. This included patches
to mod_jk 1.2 to fix a few thread safe problems. The mod_jk 1.2.5
includes all these patches.

All in all it was worth the effort, 9 months later it should be
easier for someone with a similar environment to mine to upgrade
to apache 2.

Regards,

Glenn

--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--

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



Re: [PATCH] JasperLoader - Security manager usage LoadClass concurrency problem fix

2004-03-04 Thread Glenn Nielsen
This only occurs when Tomcat is started without a SecurityManager and
then later application code sets a SecurityManager.

Please see the following bug report for an explanation of why
that is not a good thing to do:

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

Thanks for taking the time to analyze how this works but the
behaviour will not be changed.

Glenn

On Thu, Mar 04, 2004 at 11:46:31AM +0200, Matti Härö wrote:
 Hi,
 
 the patch below fixes a bug that occasionally causes a NullPointerException in
 loadClass() method. The problem was caused by the way the system security
 manager was used in this class. For checking if there is a security manager, and
 then using the security manager for checking the access, two (potentially
 different) security managers were used. Checking for the existence of a security
 manager was done by System.getSecurityManager(). Then inside the if block, a
 reference to a class private variable securityManager was used.
 
 The private variable securityManager had been set in the constructor of the
 JasperLoader instance, and was often different from the one used in the
 loadClass() method for checking if there was a securityManager. More
 specifically, the private attribute securityManager was often null, while
 System.getSecurityManager() returned a non-null value in loadClass() method.
 This in turn caused the loadClass() to throw a NullPointerException.
 
 Mr Matti Haro
 
 --- JasperLoader.java   2004-03-04 08:57:52.0 +0200
 +++
 ./tomcat-5-0-19-src/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet/JasperLoader.java
2004-03-04 08:59:43.0 +0200
 @@ -75,6 +75,7 @@
   * @author Anil K. Vijendran
   * @author Harish Prabandham
   * @author Jean-Francois Arcand
 + * @author Matti Haro
   */
  public class JasperLoader extends URLClassLoader {
 
 @@ -82,7 +83,6 @@
  private CodeSource codeSource;
  private String className;
  private ClassLoader parent;
 -private SecurityManager securityManager;
  private PrivilegedLoadClass privLoadClass;
 
  public JasperLoader(URL[] urls, ClassLoader parent,
 @@ -93,7 +93,6 @@
 this.codeSource = codeSource;
 this.parent = parent;
  this.privLoadClass = new PrivilegedLoadClass();
 -   this.securityManager = System.getSecurityManager();
  }
 
  /**
 @@ -147,8 +146,9 @@
  resolveClass(clazz);
  return (clazz);
  }
 -
 +
  // (.5) Permission to access this class when using a SecurityManager
 +SecurityManager securityManager = System.getSecurityManager();
  if (securityManager != null) {
  int dot = name.lastIndexOf('.');
  if (dot = 0) {
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--

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



Re: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apach e2 mod_jk2.c

2004-03-04 Thread Glenn Nielsen
On Thu, Mar 04, 2004 at 05:49:21PM +0100, jean-frederic clere wrote:
 jean-frederic clere wrote:
  [EMAIL PROTECTED] wrote:
  
 jfclere 2004/03/03 09:55:32
 
   Modified:jk/native2/server/apache2 mod_jk2.c
   Log:
   Remove jk2_translate... It is still not 100% OK:
   - LocationMatch does not work.
   - Some _not_found ends in Tomcat when using mod_dav.
  
  
  That is still not OK. I will go on later. Sorry :-(
 
 Now it looks better. The only thing I have removed is the logic for mod_dir
 Tomcat will do it if needed.

Does that mean that Tomcat would have to resovlve identification
of the directory index file?

It would be nice to keep this on the apache side when someone
uses Alias or JkAutoAlias to serve static pages, fourwarding
and DirectoryIndex files which are *.jsp to Tomcat of course.

Glenn


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



Re: jk/jk2 and ap_hook_translate_name

2004-03-02 Thread Glenn Nielsen
Henri,

It is hard to say.  It all depends on how changing jk hook
priorities impact other apache modules. I am convinced that
the best solution for this will not be found until we have
an extensive test suite to test use of mod_jk 1/2 with other
modules.  So if a change is made we can make sure use of
mod_jk with other modules hasn't been broken.

Regards,

Glenn

On Tue, Mar 02, 2004 at 04:13:29PM +0100, Henri Gomez wrote:
 Hi Glenn and others :)
 
 I see in jk that we're using :
 
 ap_hook_translate_name(jk_translate,NULL,NULL,APR_HOOK_MIDDLE);
 
 and now in jk2 :
 
 static const char * const aszPre[] = { mod_rewrite.c, NULL };
 ap_hook_translate_name(jk2_translate, aszPre, NULL, APR_HOOK_FIRST);
 
 What do you think of it ?
 
 MIDDLE or FIRST but after mod_rewrite ?
 
 We should be consistent here ...
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--

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



Re: jk2 buglets

2004-03-01 Thread Glenn Nielsen
In my apache 2.0.48 install the version of apr is 0.95.

Glenn

On Mon, Mar 01, 2004 at 05:04:17PM -, [EMAIL PROTECTED] wrote:
 
 
  -Original Message-
  From: Guenter Knauf [mailto:[EMAIL PROTECTED]
  Sent: 27 February 2004 16:13
  To: [EMAIL PROTECTED]
  Subject: RE: jk2 buglets
  
  
  hmm, you could check to use the old mmap code which Henri 
  just has checked in again; get latest jk_shm.c from cvs and 
  modifiy it to ignore APR_HAS_MMAP and use HAVE_MMAP instead; 
  if that works then we know for sure that APR mmap supportg is 
  somehow broken on Solaris, and you have to ask in the apr 
  group for a fix...
  
  Guenter.
 
 Good call.  Ignoring APR results in an so that starts and responds
 apparently without error.
 
 Assuming that the next mod_jk2 release wants to go with the present APR
 (0.94) or even the CVS (pre 1.0?) then we need to kludge mod_jk on solaris 8
 (at least) to not use APR for this bit.
 
 I was going to add an  defined(foo) to the APR defined lines, however I do
 not know the right foo to add __sun seems too broad.  The next more complex
 fix is to alter the Makefile with a -d.
 
 What do people think?
 
 Thanks Guenter.
 
 Greg
 
 
 
 
 
  
  
  
  -
  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]
--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--

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



Re: Apache 2 module hook priorities, was: Help required on Apache from scratch...

2004-02-25 Thread Glenn Nielsen
Henri,

Perhaps we should bounce these last two messages to tomcat-dev
and continue the discussion there.

Resolving this problem will require a great deal of painstaking
work.  Setting up test conditions to test mod_jk 1.2/2 interaction
with other core apache modules and commonly used ones like mod_dav.
Once all the test conditions are setup then we will have to review
the hook priority for these modules and try to determine the best
hook settings for mod_jk or where we need to add code to handle exceptions
in mod_jk.  Then test again until all of our test conditions pass.

Regards,

Glenn

On Wed, Feb 25, 2004 at 06:12:23PM +0100, Henri Gomez wrote:
 
 Henri,
 
 Getting the priority set correctly for hooks in JK2 is sticky.
 You might take a look at what I did setting hook priority in
 mod_jk 1.2 so that it would work correctly with mod_dir. My
 cvs commit messages might be helpful from 
 jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c .
 
 Here is the page the docs how hook priority works:
 
 http://httpd.apache.org/docs-2.0/developer/hooks.html
 
 It all comes down to carefully reviewing the hook priority of other
 modules and how those modules interact with JK2. Then setting the
 hook priorities in JK2.
 
 It seems we should add more code in jk2_map_to_storage(...)
 
 Here's what you put in jk
 
 
 Correct ?
 
  if(!r-proxyreq  !apr_table_get(r-notes, JK_WORKER_ID)) {
jk_server_conf_t *conf =
(jk_server_conf_t 
 *)ap_get_module_config(r-server-module_config,
 jk_module);
 
if(conf) {
char *worker;
if( (r-handler != NULL ) 
(! strcmp( r-handler, JK_HANDLER ) )) {
/* Somebody already set the handler, probably manual 
 config
 * or native configuration, no need for extra 
 overhead
 */
jk_log(conf-log, JK_LOG_DEBUG,
   Manually mapped, no need to call 
 uri_to_worker\n);
return DECLINED;
}
worker = map_uri_to_worker(conf-uw_map, r-uri, 
 conf-log);
 
if(worker) {
r-handler=apr_pstrdup(r-pool,JK_HANDLER);
apr_table_setn(r-notes, JK_WORKER_ID, worker);
 
/* This could be a sub-request, possibly from 
 mod_dir */
if(r-main)
apr_table_setn(r-main-notes, JK_WORKER_ID, 
 worker);
 
}
}
}
--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--

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



Re: mod_jk 1.2.6 release

2004-02-15 Thread Glenn Nielsen
On Sat, Feb 14, 2004 at 07:18:54PM +0100, Henri Gomez wrote:
 Mike Anderson wrote:
 I'd like to see this since Henri's timeout fixes really help some issues
 that we've seen with apps that hang Tomcat threads.  It might be good to
 wait until the POST data issues are resolved (see threads titled POST
 recovery in JK and JK2 HEAD and Mod_JK2 - Default Worker)
 
 Glenn, you could works on the 1.2.6 release, since 2.0.4 will be 
 released next week, what about the week after ?

Sure, if its ready.  I would like to see the bug fix for that POST
bug finalized before doing a release.

 You have my +0 for RM ;-)

Thanks, I think. ;-)

--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--

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



mod_jk 1.2.6 release

2004-02-13 Thread Glenn Nielsen
I have noticed a number of bug fixes and patches to mod_jk 1.2.

Whenever you think it is ready I can act as the release manager for
a mod_jk 1.2.6 if you want me to.

Regards,

Glenn

--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--

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



Re: [PATCH]Virtual Host Choice on HTML Manager

2004-01-15 Thread Glenn Nielsen
On Mon, Jan 12, 2004 at 11:43:44AM -0700, George Sexton wrote:
 Here is my thinking. Of course, I am a lowly user and not a developer
 but I think it pretty much covers the issues. The major issues from my
 perspective are:
 
 1)Admin cannot deploy privileged applications. This requires
 deploying manager by hand.
 2)Admin cannot stop or restart applications. This requires using
 manager. 
 3)Manager already displays the status for all virtual hosts. This
 kind of breaks the virtual host purity that Remy and others want in this
 application.
 4)Deployment of application using manager is difficult at best. I
 have never been able to do it. Even if you can do it, there are no
 configuration points. IOW, you cannot configure logging.
 5)As Remy points out, people will next be asking for manager to
 manage virtual hosts.
 
 The biggest issue for me is that if you want to use a UI to manage
 tomcat, 3 different tools (Admin, Hand Edit, and Manager) must be used
 to create a virtual host that can be stopped and restarted. Doesn't
 anyone else see a problem with this?
 
 If I had my way, what I would do is:
 
 1)Add capability for admin application to stop/start/re-start
 contexts. This really shouldn't be that big a deal. I cannot see any
 rationale for not putting it in. Additionally, I would put the status
 reports in the Admin app. If you do this, then I don't really care about
 the manager application and wouldn't even deploy it all.

This is ok, no reason why the uber-tomcat-admin can't have just
one place to do this.

 2)Strip every feature except list, status, stop, and re-start from
 manager. IOW, remove the deployment capability and the complete server
 status feature (or limit it to the virtual host). How many people REALLY
 need to script deployment of a web application? Particularly in the
 limited fashion allowed by the current Manager?

Strong -1. Its there and it is being used, and there will continue to
be a need for it even if the admin app supports the types of things
the manager does.

There are many who use the ant tasks to manage webapps, especially during
web application development. The ability to delegate out web application
mangement and deployment to a customer for only a single virtual host
is crucial for those who administer instances of Tomcat which support
multiple customers in multiple virtual hosts.  Including the ability
to deploy a web application via the HTML manager.

Regards,

Glenn

 
 -Original Message-
 From: Remy Maucherat [mailto:[EMAIL PROTECTED] 
 Sent: Monday, January 12, 2004 9:04 AM
 To: Tomcat Developers List
 Subject: Re: [PATCH]Virtual Host Choice on HTML Manager
 
 
 TANAKA Yoshihiro wrote:
  on Tue, 6 Jan 2004 16:48:47 -0600
  Glenn Nielsen [EMAIL PROTECTED] wrote:
 I'll try to modify as follows:
 
 1)Make new classes extend HTMLManagerServlet  ManagerServlet.
 2)These servlets are optional. (commented out in web.xml)
 3)Only admin role can access them. (by web.xml)
 
 Do you think I've it figured out?
 
 That sounds right. :-)
  
  I've done and put them on
  http://www.ytp.ne.jp/tech/tomcat/manager/index.html
  
  I modified existing classes to allow them to be extended,
  but did not change their functions.
  Also I create a new build file for Deployer named 'build-muti.xml'
  cause of security.
  
  I hope committers evaluate and commit them.
 
 While I appreciate the effort, I don't like your patch right now, sorry
 :-(
 
 Why add complexity when it is so simple to deploy the manager webapp on 
 a new host ? Note: A webapp doesn't use any noticeable amount of 
 resources in TC 5 (no background thread, no nothing).
 I suppose if there weren't all the changes to the default manager, I 
 would have nothing against the patch (although I do hate the changes to 
 the Ant tasks; it's really counter productive, and proves this is a bad 
 design: the place of the vhost is in the URL).
 
 Soon, there will be requests to add host management in the manager 
 webapp, and it will become a big mess. If there's interest in improving 
 the management tools, fine, but there should be a thinking process 
 before the hacking starts.
 
 Fixes were added a few days ago to the admin webapp to support dynamic 
 host creation. This is a first step. It should then be possible to add a
 
 manager to a newly created host using the admin webapp (and then you're 
 done, no hacks required). The biggest problem is probably that the admin
 
 webapp is not scriptable at all.
 
 Rémy
 
 
 
 -
 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]
--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut

Re: Jk2 object model

2004-01-07 Thread Glenn Nielsen
Rather than look at different architectures for implementing
a web server connector to Tomcat I would rather focus on
improving the connector.

Digging into jk2 has been on my list of things to do but I haven't
had time yet. mod_jk 1.2 with Apache 2 is working well enough for me.

I like the concept of JMX in JK2 for the purpose of application
monitoring.

Some things that could be improved whether in jk or jk2 are:

Switching jk to use APR everywhere possible to make portability
easier between operating systems.

Develop a way to use a global connection pool to Tomcat.
The current way connectors are allocated where they are
tied to the httpd process use up too many resources with
idle connections.  One idea I had was to follow the model
used by Apache 2 for mod_cgid when using the worker MPM.
mod_cgid runs as a separate process which the httpd process
communicates with to execute CGI's.  We could use the same
model but have the process spawn threads for handling
requests being forwarded to Tomcat.  This would make the
most efficient use of the connectors to Tomcat and allow
us to do more sophisticated load balancing by tracking
information in this process for each worker's performance.

Regards,

Glenn

On Wed, Jan 07, 2004 at 09:52:06AM +0100, Mladen Turk wrote:
  
 
  -Original Message-
  From: Bill Barker
  Sent: 7. sije?anj 2004 9:22
  To: Tomcat Developers List
  Subject: Re: Jk2 object model
  
  
  
   I'm interested if jk2 could plug into more applications - 
  there aren't
   that many generic connectors. KDE has one specialized for 
  konqueror,
   and mozilla has one - both are mostly for applet support, 
  with xconnect
   hardly used ( and I heard pretty slow ). If jk2 would 
  support (XP)COM or
   gtk object model - it may be possible to access and control various
   desktop application with some simple web-like requests.
  
  
  The big problem that I see is that currently jk2 uses 
  'abstract classes' to
  enable it to handle the fact that that the 'implementing 
  class' needs to
  control I/O (reading the Request, writing the Response).  
  This doesn't fit
  well with other frameworks.  IMHO, this part would need to be 
  re-writen to
  work on something more like a Listener model (certainly 
  required for a COM
  implementation :).  However, this may mean a performance hit 
  when using the
  standard Apache/IIS/SunOne modules.
  
 
 I was allways looking at a JK2 from that perspective, meaning, enabling it
 to embed the TC inside web server (acting like a COM proxy).
 
 What I was thinking is to pull all the AJP logic and configuration from C to
 Java, leaving only JNI to comunicate with that new proxy.
 The client Java part would be able in that case to constuct the AJP messages
 in case of out-of the process server, or what ever comunication channel.
 
 Since this changes the things conceptualy, I see this as a new product
 living together with JK.
 
 
 MT.
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--

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



Re: [PATCH]Virtual Host Choice on HTML Manager

2004-01-06 Thread Glenn Nielsen
On Wed, Jan 07, 2004 at 12:33:38AM +0900, TANAKA Yoshihiro wrote:
 on Mon, 05 Jan 2004 20:57:28 +0100
 Remy Maucherat [EMAIL PROTECTED] wrote:
 
  An acceptable patch would be to extend the existing manager class with
  a new class which implements this feature.  Then those administering
  Tomcat can choose which version of the manager they want to install.
 
 I agree with this.
 Is one manager per vhost really too much to ask ? (since different 
 principals will be needed in many situations)
 
 Thanx for your comments everyone. I got your point.
 I'm not lazy to login each virtual host, but I am 
 when installing manager application to each virtual host.
 
 There are a use cases for the feature, of course, so I'm ok with having 
 an extension class that could replace the default manager servlet.
 
 I'll try to modify as follows:
 
 1)Make new classes extend HTMLManagerServlet  ManagerServlet.
 2)These servlets are optional. (commented out in web.xml)
 3)Only admin role can access them. (by web.xml)
 
 Do you think I've it figured out?

That sounds right. :-)

Thanks for contributing your patches so that others can benefit
from them.

Glenn

--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--

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



Re: [PATCH]Virtual Host Choice on HTML Manager

2004-01-05 Thread Glenn Nielsen
On Mon, Jan 05, 2004 at 01:11:12AM +0900, TANAKA Yoshihiro wrote:
 Hi, Happy New Year!
 I wrote patches that allow to choose any virtual host of Tomcat
 when you operate HTML Manager, Manager Servlet, and Deployer.
 I put patches and screen shots on:
 http://www.ytp.ne.jp/tech/tomcat/manager/index.html
 
 I hope committers would try and apply the patches. It's my pleasure
 to debug, if any.

This breaks security for virtual hosting by allowing anyone who can
authenticate to use the manager to manage all virtual hosts.
Though this may be easier for you it prevents me from administering
a Tomcat server where multiple virtual hosta are managed by different
customers.

Therfor I am -1 for applying this patch.

An acceptable patch would be to extend the existing manager class with
a new class which implements this feature.  Then those administering
Tomcat can choose which version of the manager they want to install.

Regards,

Glenn

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



Re: catalina.policy to avoid no object DCH for MIME...

2003-11-24 Thread Glenn Nielsen
This is a special use case depending on where you install the mail API jars.
Since there are potentially 1000's of special use cases I don't see where
adding these examples to catalina.policy would help.
A better solution would be to add a section to the Tomcat SecurityManager doc
which lists what permissions are required for different standard API's.  JDBC,
mail, etc.
If you want to create a patch for the Tomcat security manager docs I would be
happy to review it and commit it.
Thanks,

Glenn

Jun Inamori wrote:
Hi,

We faced the same problem as:
   http://www.mail-archive.com/[EMAIL PROTECTED]/msg48320.html
The message reports the exception when sending e-mail.
It looks like this:
javax.activation.UnsupportedDataTypeException: no object DCH for MIME type 
text/plain
at javax.mail.Transport.send0(Transport.java:219)
We re-produce this, only if we enable SecurityManager and place mail.jar and 
activation.jar into:
   ${catalina.home}/shared/lib
SecurityManager seems to prevent javax.activation.CommandMap to load:
   META-INF/mailcap
from mail.jar
To avoid this kind of problem, catalina.policy should include the entity like this:

   grant codeBase file:${catalina.home}/shared/lib/activation.jar {
  permission java.io.FilePermission 
/usr/local/jakarta-tomcat-4.1.12-LE-jdk14/shared/lib/mail.jar,read;
   };
I request you to add the lines below to catalina.policy.

// If you place mail.jar and activation.jar into:
//${catalina.home}/shared/lib
// please activate the entity below and update the target of
// FilePermission.
//grant codeBase file:${catalina.home}/shared/lib/activation.jar {
//  permission java.io.FilePermission 
/usr/local/jakarta-tomcat-4.1.12-LE-jdk14/shared/lib/mail.jar,read;
//};
I think this will help many Tomcat users, but do no harm.
Any suggestion/questions are welcome to me.


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


Re: tomcat stats and performance

2003-11-24 Thread Glenn Nielsen
[EMAIL PROTECTED] wrote:
Hi to all, I have two questions. We have Tomcat as server for a struts web
application.
- We need do stats for that web application, stats like  what pages user
enter, who user enter more to the application, performance stats ... I have
seen that one choice is do a manual filter, other choice use awstats.  I
would appreciate information about that of someone that have experiencia on
stats, and he can help me to choose the best choice on time and effort.
- The second question is about performance, here we have tomcat and when
most user enter to the application the server don't reply very well. I have
read that is better have APACHE as web server and TOMCAT as server
container, is that true?  would I improve the performance? or the solution
is customize tomcat better?.
THANKS IN ADVANCE. REGARDS.

I recommend using Apache 2 with mod_jk 1.2 to serve static content in front
of Tomcat.   You can then configure mod_jk to do tomcat request logging which
includes things like request latency in ms.  There are perl scripts which come
with the mod_jk 1.2 source distribution which can be used to analyze the mod_jk log.
With Apache in front you can also use tools like analog to generate web statistics
from the apache logs.
For general Tomcat peformance issues there was a session at ApacheCon on this.

Regards,

Glenn

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


Re: catalina.policy to avoid no object DCH for MIME...

2003-11-24 Thread Glenn Nielsen
Jun Inamori wrote:
Hi,

Thank you for your reply.


This is a special use case depending on where you install
the mail API jars.
Since there are potentially 1000's of special use cases I
don't see where adding these examples to catalina.policy
would help.
A better solution would be to add a section to the Tomcat
SecurityManager doc which lists what permissions are required
for different standard API's.  JDBC, mail, etc.


That's a good idea.
I'll try it.
I just downloaded:
   security-manager-howto.xml
from CVS.
I think I should work on this XML, rather than the HTML.
Yes, thats the right place.

After the section titled:

  h3Policy File Format/h3

I'll add the new section titled:

  h3Required Permissions for standard API's/h3

The new section will list the required permissions for JDBC and JavaMail.
I have ever experienced the difficulties in Java Advanced Imaging API with 
SecurityManager, and so I'll also list the required permission for it.
I'll work on it in the next weekend.
Any suggestions are welcome to me.
Best regards,
This sounds great.  Thanks for taking the initiative to improve the docs.

Regards,

Glenn

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


Re: [5.0] Getting some defaults from system properties

2003-11-13 Thread Glenn Nielsen
Couldn't these be set using the DefaultContext?

Regards,

Glenn

Remy Maucherat wrote:
Hi,

This is a little similar to the Ant-like properties for server.xml.

The problem: the allowLinking and caseSensitivity flags of 
FileDirContext, which can be set per context using the Resources 
element, but it's kind of annoying to do it server wide.

All defaults for flags (and others) are hardcoded, which is logical. 
However, for some, it would be convinient to be able to set them in a 
global way.

For the naming conventions for the property names, I plan to use:
fully_qualified_class_name.field_name
The algorithm is the following for a field:
- look up the appropriate system property
- if defined, use it
- otherwise, use the old defaults
I don't think that many fields would be defaulted using this.

Additionally, to allow easily setting system properties, all the 
properties from catalina.properties will be set as system properties. 
Since catalina.properties is not used in embedded mode (it is loaded 
only by Bootstrap), there should be zero impact for this use case.

Comments ?

Remy



-
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: [5.0] Getting some defaults from system properties

2003-11-13 Thread Glenn Nielsen


Remy Maucherat wrote:
Glenn Nielsen wrote:

Couldn't these be set using the DefaultContext?


Why not ?
It seems like a better fit.
In what way?

Having one method to configure defaults for Context's seems better
than having multiple methods. And keeping the configuration of these
in server.xml keeps everything consistent.
Regards,

Glenn

--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: [5.0] Getting some defaults from system properties

2003-11-13 Thread Glenn Nielsen
Oops, I misread your reply. :-)

Glenn

Remy Maucherat wrote:
Glenn Nielsen wrote:

Remy Maucherat wrote:

Glenn Nielsen wrote:

Couldn't these be set using the DefaultContext?


Why not ?
It seems like a better fit.


In what way?

--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Why is mod_jk distributed both as 2.0.2 and 2.0.4?

2003-11-12 Thread Glenn Nielsen


Kurt Miller wrote:
From: Henri Gomez [EMAIL PROTECTED]

Kurt Miller a écrit :


From: Glenn Nielsen [EMAIL PROTECTED]

Perhaps the mod_jk connector should not be released with Tomcat 4/5

since

it


has its own release cycle and we are already doing separate releases of
these.
Regards,

Glenn



Would this work...

When a stable version of mod_jk or mod_jk2 is released put the stable

jar

files in the
jakarta/tomcat-connectors/jk(2)/binaries/ directories. Then have Tomcat

4/5

use the released stable jars instead of building them.

If this works, then it may also serve as a way for users to upgrade both

the

native and the java side when a new jk/jk2 release is made.
I think that we should decouple jk/jk2 release from tomcat3/4/5 release,
in some case jk 1.2.x add a faster release rate that tomcats :)


I guess the simplest solution is to exclude the following directories from
the jakarta-tomcat-connectors-4.X-src archives to avoid confusion:
jk/native
jk/native2
webapp/apache-1.3
webapp/apache-2.0
webapp/lib
webapp/support
webapp/include
Another way to look at this is, what things out of j-t-c need to have
a source release along with a Tomct 3/4/5 release?  Remy?
coyote, http11, and util, anything else?

Would we then need to provide jars and source for the AJP connector side
of things in our mod_jk releases?
Regards,

Glenn

--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: [VOTE] Kurt Miller as commiter

2003-11-11 Thread Glenn Nielsen
+1, Glad to have you aboard.

Henri Gomez wrote:
Hi to all,

I would like to propose you a new tomcat commiter, Kurt Miller
which as proposed many usefull patches for JK2.
Since we want to deprecated jk and focus jk2, we need
more people involved on jk2.
Vote please.



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


--
--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Vegas Anyone? :-)

2003-11-07 Thread Glenn Nielsen
On Fri, Nov 07, 2003 at 09:44:04AM -0800, Amy Roh wrote:
 
 ApacheCon 2003 will be held in Las Vegas this November 16-19.  Who is going
 to be there from Tomcat Dev?  Maybe we can coordinate Tomcat get together...
 :-)
 

I'll be there, including Sat  Sun for the Hack-A-Thon.

Glenn

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



Re: Missing mod_jk2 docs?

2003-10-31 Thread Glenn Nielsen
Thanks for reporting this.  Forwarding on to the tomcat developers.

Glenn

Matt McParland wrote:
There are links in various places on jakarta.apache.org pointing to the 
URL below:

http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk2/doc/

But that URL points me to:

http://jakarta.apache.org/site/binindex.cgi

which doesn't have any documentation on jk2 at all.  Am I missing 
something?



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


Re: [VOTE] New builds

2003-10-29 Thread Glenn Nielsen
Remy Maucherat wrote:
ballot
Release 4.1.29 as Stable ?
[X] Yes
[ ] No
/ballot
ballot
Release 5.0.14 as Beta ?
[ ] Yes
[ ] No
/ballot
Rémy



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



--
--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: mod_jk timeout?

2003-10-28 Thread Glenn Nielsen
Brian Maher wrote:
On Mon, 27 Oct 2003, Henri Gomez wrote:

If the thread on java side is a long running task or a blocking task,
it should be handled by the servlet engine and sus some watchdog support
should be added in Tomcat.
In you're exemple I didn't know how the thread could be ever finished 
!!!


In theory, that's what Thread#interrupt is for. It asks the thread to 
shut
down, resulting in setting the #interrupted flag / an 
InterruptedException
on potentially blocking calls such as wait() or sleep(). One could
interrupt named jsp like that.


Actually, I was thinking the Thread#join would be better since we could 
be in an infinite loop not doing any calls to wait() or sleep().  I was 
thinking of implementing a scheme sort of like this:

   mod_jk |  tomcat
   ---+--
   PING  --  received
   received  --  PONG
  [ sleep ~2 seconds ]
   received  --  PING
   PONG  --  received
If any side sends a PING and doesn't hear a PONG in 0.1 seconds, it can 
assume the other side is dead.  This would mean a there would need to 
be a separate thread in the tomcat that is simply doing housekeeping or 
watch dogging on the status of the connections.

This won't work well on the Tomcat side due to Garbage Collection.
the JVM will often freeze Tomcat for  .1 seconds during GC.  And
when doing a Full GC can freeze Tomcat for many seconds.
Regards,

Glenn

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


Re: jk binaries and new mirorring

2003-10-27 Thread Glenn Nielsen
Henri Gomez wrote:
Hi to all,

Some people ask me for jk 1.2.5 iSeries binaries.

I will build it but where should I upload it to make it later
replicated on mirrors site ?
Look in CVS at j-t-c/jk/HOW-TO-RELEASE

Glenn

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


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

2003-10-25 Thread Glenn Nielsen
Since I recently made changes to the DefaultContext in Tomcat 4, perhaps
this could be back ported to Tomcat 4.1.
Regards,

Glenn

[EMAIL PROTECTED] wrote:
remm2003/10/24 04:57:27

  Modified:catalina/src/share/org/apache/catalina/core
StandardDefaultContext.java
  Log:
  - Add support for resource links to StdDefContext.
  
  Revision  ChangesPath
  1.8   +16 -4 jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardDefaultContext.java
  
  Index: StandardDefaultContext.java
  ===
  RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardDefaultContext.java,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- StandardDefaultContext.java	21 Oct 2003 00:18:25 -	1.7
  +++ StandardDefaultContext.java	24 Oct 2003 11:57:27 -	1.8
  @@ -1373,6 +1373,14 @@
   }
   listener.addResource(contextEntry);
   }
  +ContextResourceLink [] resourceLinks = findResourceLinks();
  +for (int i = 0; i  resourceLinks.length; i++) {
  +ContextResourceLink contextEntry = resourceLinks[i];
  +if (contextResources.exists(contextEntry.getName())) {
  +listener.removeResourceLink(contextEntry.getName());
  +}
  +listener.addResourceLink(contextEntry);
  +}
   String [] envRefs = findResourceEnvRefs();
   for (int i = 0; i  envRefs.length; i++) {
   if (contextResources.exists(envRefs[i])) {
  @@ -1498,6 +1506,10 @@
   ContextResource [] resources = findResources();
   for( int i = 0; i  resources.length; i++ ) {
   context.addResource(resources[i]);
  +}
  +ContextResourceLink [] resourceLinks = findResourceLinks();
  +for( int i = 0; i  resourceLinks.length; i++ ) {
  +context.addResourceLink(resourceLinks[i]);
   }
   String [] envRefs = findResourceEnvRefs();
   for( int i = 0; i  envRefs.length; i++ ) {
  
  
  

-
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: Coyote Connector logging

2003-10-22 Thread Glenn Nielsen


Remy Maucherat wrote:
Glenn Nielsen wrote:

The Coyote docs state the following regarding coyote connector logging:

Any debugging or exception logging information generated by this 
Connector will be automatically routed to the Logger that is 
associated with our related Engine. No special configuration is 
required to enable this support.

But this doesn't seem to work.

The Connector is configured in the Service scope and the Logger is 
configured in the Engine
scope.  A Service can not have a Logger configured, and an Engine 
can't have a Connector
configured.

I see logging output from the Coyote Connector going to the default 
stdout/stderr Tomcat
logs rather than to to the log configured for the Engine.

Am I just mistaken, or is the documented logging behaviour broken?


As many components, the connector now logs to commons-logging (with 
categories according to its classname), so this particular page in the 
docs would need updates :-(
Right, I saw that.  So how would you configure Coyote to log to the
same log as you configured for the Engine in Tomcat 4.1?
Glenn

--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java

2003-10-22 Thread Glenn Nielsen
Remy Maucherat wrote:
[EMAIL PROTECTED] wrote:

glenn   2003/10/22 06:46:28

  Modified:util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java
  Log:
  SocketExceptions can occur in a networked app.
  No need to log a stack trace, just log the remote host
  name/ip and the exception message. Then there is less
  cruft in the logs.


I'd like more details :)
With HTTP/1.1, an exception can only occur while setting the socket 
options. I don't consider that very normal, though. What was your 
motivation for the change ? Did you see many logs coming out of here ?

Yes, that is where I saw the Exception:

[ERROR] PoolTcpEndpoint - -Unexpected error java.net.SocketException: Socket 
closedjava.net.SocketException: Socket close
d
at java.net.PlainSocketImpl.socketSetOption(Native Method)
at java.net.PlainSocketImpl.setOption(PlainSocketImpl.java:187)
at java.net.Socket.setTcpNoDelay(Socket.java:372)
at 
com.sun.net.ssl.internal.ssl.SSLSocketImpl.setTcpNoDelay([DashoPro-V1.2-120198])
at 
org.apache.tomcat.util.net.PoolTcpEndpoint.setSocketOptions(PoolTcpEndpoint.java:495)
at 
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:587)
at 
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:666)
at java.lang.Thread.run(Thread.java:479)

This was due to simple external system monitoring that would periodically
connect to the Coyote port to verify that the port was accepting connections,
then immediately disconnect.  So the stack trace would end up in the logs
each time the system monitoring did its checks.  In this case the Coyote
connector implemented SSL so there was no easy way to get the system
monitoring software to do an actual HTTPS negotiation with it.
Regards,

Glenn

--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Coyote Connector logging

2003-10-22 Thread Glenn Nielsen
Bill Barker wrote:
- Original Message -
From: Glenn Nielsen [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Wednesday, October 22, 2003 11:39 AM
Subject: Re: Coyote Connector logging


Remy Maucherat wrote:

Glenn Nielsen wrote:


The Coyote docs state the following regarding coyote connector logging:

Any debugging or exception logging information generated by this
Connector will be automatically routed to the Logger that is
associated with our related Engine. No special configuration is
required to enable this support.
But this doesn't seem to work.

The Connector is configured in the Service scope and the Logger is
configured in the Engine
scope.  A Service can not have a Logger configured, and an Engine
can't have a Connector
configured.
I see logging output from the Coyote Connector going to the default
stdout/stderr Tomcat
logs rather than to to the log configured for the Engine.
Am I just mistaken, or is the documented logging behaviour broken?


As many components, the connector now logs to commons-logging (with
categories according to its classname), so this particular page in the
docs would need updates :-(
Right, I saw that.  So how would you configure Coyote to log to the
same log as you configured for the Engine in Tomcat 4.1?


Change the Engine logging to use c-l? ;-).

I don't see that it could be done since none of the components outside of
o.a.c.t5 understand anything about Catalina (and I'm strongly -1 to changing
this, since it will break 3.3).
And you are right, code outside of o.a.catalina shouldn't need to know anything
about o.a.catalina.
I like the fact that logging is inheritable by nested components in Tomcat 4,
I can't speak for Tomcat 3.3 or 5.0.  The way the latest Coyote Connector
works breaks that contract.  org.apache.coyote.tomcat4.CoyoteConnector uses
org.apache.catalina.Logger yet org.apache.util.net.* uses commons-logging.
That means that you can't log everything related to the same CoyoteConnector
to the same log file,
I don't know what the best solution is, just identified a problem. :-)

Regards,

Glenn







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


Tomcat [5] java 1.4 dependency

2003-10-19 Thread Glenn Nielsen
A dependency for java 1.4 has crept into Tomcat 5 in the manager StatusTransformer.

writer.write( max=' + Runtime.getRuntime().maxMemory() + '/);

The Runtime.maxMemory() method does not exist in java 1.3.

Glenn

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


Tomcat 5/4 DefaultContext Listener/Loader

2003-10-19 Thread Glenn Nielsen
The docs for both Tomcat 4 and 5 imply that you can nest a Context Listener inside
the DefaultContext.  But this had not been implemented.
I had a need to implement a custom Context Listener and Custom Loader (WebappLoader)
which needed to be configurable using the DefaultContext.
I have patches for both Tomcat 4 and Tomcat 5 which implement the ability
to configure a nested Context Listener and a nested Webapp Loader inside
the DefaultContext.
When developing that patches I did not change any published interfaces, though
the internal catalina implementation had to be slightly modified.
I can commit this to Tomcat 5 first, then if everyone is ok with it,
commit the Tomcat 4 version of the patches.
Regards,

Glenn

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


Re: jk2 evolution plan

2003-10-17 Thread Glenn Nielsen
+1

I can help out.

This is a significant change for a minor revision to 2.0.4,
perhaps we should bump it to 2.1 or even 3.0?
Glenn

Henri Gomez wrote:
Ok, about everybody seems to agree on using apr for jk2
(still waiting Nacho for IIS).
APR side will be to :

- Update doc to indicate that APR is mandatory

- Remove #idef APR

- Use APR for all OS operation and sus will save us from
  handling all the #include for all the diverses IO operation
  (it's really a pain).
- For now still use_jk pool, but the version using apr_tools.

- Make socket use apr_socket for compatibility.

JK to JK2 fonctionnalities backport :

- Check features added in jk and not present in jk2 (ie cping/cpong).
  There was also some specific lb workers settings which should be
  studied.
- After this works, make a 2.0.4 release and start extensive
  testing.
On the channel side I added a new method, hasinput which should help
use determine if there is something to do on 'stream connections'.
For instance, it's used in jk/jk2 by the cping/cpong stage when
connectTimeout, prepostTimeout and replyTimeout are set.
And no the who's who ;)

I'd like to know who could works on jk2 evolution.

BTW, where could we find today the jk/jk2 documentation which is
regenerated each day  ?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


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


Re: jk/jk2 - time for apr

2003-10-15 Thread Glenn Nielsen
+1 to have a version of mod_jk rewritten to use APR for all OS stuff

It would be best to use the version of APR which is distributed with
the current Apache 2 release so that there are no conflicts when using
mod_jk with Apache 2.
Requiring APR would allow using a global connection pool for the socket
connections to Tomcat.  And allow more sophisticated load balancing when
you can have access to global information about how each pool of connectors
to Tomcat is performing.
If this involves significant changes to the code we might want to bump
the major version to jk3.
We will still need at least one more release of mod_jk 1.2 for the
minor changes committed since the 1.2.5 release.
Regards,

Glenn

Henri Gomez wrote:
Hi to all,

Now that jk seems stabilized a bit, should we focalize on jk2 ?

For instance I added some features to jk (ping/pong) which should be
ported to jk2.
Also I wonder if APR is mandatory for jk2.

I'd like to use APR as a facade to all Operating System calls.

The goal is to hide all the complexity of Windows, iSeries,
differents Unix implementations behind APR which is now stable
and well diffused.
As such it will be +1 to make APR mandatory and start modifying jk2, to 
make it use only APR call.

But I'd like to have your opinion first.

PS: For those of you who was here 2 or 3 years ago, the requirement
of APR for mod_webapp got my total -1 at this time since it
wasn't really available, but today that's completly different.
-
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: Important requirement : Re: [next] What's next ?

2003-10-13 Thread Glenn Nielsen
Henri Gomez wrote:
Remy Maucherat a écrit :

Henri Gomez wrote:

No reply for this request ?

Should I assume I could start to work on settings the currentWorking
dir at web.xml dir location at web.xml parsing time ?


I like basing the resolution on the host appBase a lot more.


Well it will be problematic for all TC 3.2/3.3 users since the
location was the web.xml (which seems more realist).
Let me explain :

If you have a large and segmented web application, you won't put
all the settings in the same web.xml.
So you're using entities in web.xml to load parts of the applications
from files present in WEB-INF, whatever webapp location could be.


!ENTITY ap_part1 SYSTEM app_part1.xml
!ENTITY ap_part2SYSTEM app_part2.xml
!ENTITY ap_part3SYSTEM app_part3.xml


ap_part1;
ap_part2;
ap_part3;


With a load base relative to app base you break such 'natural'
behaviour.
Also consider that you could have many webapps, in many differents
locations (think ISP/ASP), which didn't have to know the location of
the appBase.
If you want we could make it Context optional but the choice should be
present to allow sites using TC 3.2/3.3 to switch more easily to 5.0...
Henri, this issue is only related to loading of ENTITY's from web.xml?

Doesn't the XML parser handle resolving those, and can't you use references
relative to the directory the web.xml is in?
Regards,

Glenn



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


[ANN] Apache Tomcat mod_jk 1.2.5 Web Server Connector released

2003-10-11 Thread Glenn Nielsen
[October 11, 2003]

The Tomcat team is pleased to announce the release of version 1.2.5 of the Apache
Tomcat mod_jk web server connector.
Tomcat is the reference implementation of a web application server which implements
the Java Servlet and JavaServer Pages specifications.
mod_jk is a connector which allows a web server such as Apache HTTPD or IIS to act as a
front end to the Tomcat web application server.
This version fixes a number of minor bugs.

See the file CHANGES.txt in the source distribution for a complete list of changes.

Soucre distribtions can be downloaded from an Apache Software Foundation mirror at:

http://jakarta.apache.org/site/sourceindex.cgi

Binary distributions for a number of different operating systems and
web servers can be downloaded from an Apache Software Foundation mirror at:
http://jakarta.apache.org/site/binindex.cgi

Documentation for using mod_jk with Tomcat 3.3, 4.1, and 5.0 can be found at:

http://jakarta.apache.org/tomcat/

The Apache Tomcat team.



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


Re: [next] What's next ?

2003-10-06 Thread Glenn Nielsen
[EMAIL PROTECTED] wrote:
Glenn Nielsen wrote:


Remy Maucherat wrote:

Glenn Nielsen wrote:


I proposed a while ago to implement a custom java policy for the
SecurityManager which uses XML for configuring permissions for
the Java SecurityManager.  There were a number of features which
made configuring a strict security policy easier.  You can look
back through the archives for the initial proposal and discussion.


It's an open discussion :)

However, I'd say this is an uphill battle. I think Costin argued the
same earlier, and the standard policy file remained consistent, and
now added JMX security rather (which is an important feature since we're
now JMX based). So well, I don't know ...
Remy


From what I recall of the discussion, the issue was not with adding
this as a feature, but with how it was implemented using Castor.


Castor was clearly a big problem, but not the only one :-)

My big concern was about inventing yet-another application-specific DTD.
If you want to support an XML format that is in use by 1-2 other
applications - great. If you can discuss this issue with any other project
and come to an agreement - again, I'm ok. But if this is an XML that only
tomcat uses - I would rather stick with the standard policy format.
Point me at these other projects which are using an alternate policy file
and I will gladly cooperate with them to come up with a standard DTD or
XML Schema.  But I don't think collaboration should be a prerequesite to
add a new feature.  Tomcat could be the leader in defining the format.
IMO parsing and generating a policy file is a bit more difficult than
parsing/generating XML - but not by much, and it's just some code.
Documenting and supporting an XML DTD - and getting people to understand
and use it is far more difficult. Almost anyone how uses security policies 
knows the standard format. To force a new syntax on the user just because
XML is a bit easier to parse is not a good idea IMO.

When originally proposed it was implemented as a pluggable alternative,
those who wanted to use the standard policy file could still do so.
Though pluggable it did require that code be added to Tomcat to support
the new features.

For those who have to maintain strict java security policies the current
policy file format of granting permissions is a pain to use.  The XML
based policy feature I designed is much easier to use.


I disagree - if you mean that XML makes it somehow easier to use because of
the . It is usually easier to use what you know or can learn from others.
If you mean the extra flexibility you proposed - like ability to define a
policy file per app, etc - I agree, but that's unrelated with XML.
The new security policy flexibility and ease of configuration could not
be done with the current policy file format.  XML seemed like the best
choice for the format of a new policy file so that the new policy
configuration features could be added.
Costin

Regards,

Glenn

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


Re: [next] What's next ?

2003-10-03 Thread Glenn Nielsen
[EMAIL PROTECTED] wrote:
On Thu, 2 Oct 2003, Angus Mezick wrote:


2. Eliminate the shared and common classloader repositories.  Unless
these are required by the spec?  Force webapps to be self-contained by
putting all their classes in WEB-INF/lib or WEB-INF/classes of their
webapp.  Have the WEB-INF/clases - WEB-INF/lib - endorsed - system
classloader hierarchy, much simpler than current.
-1 Ugh!  No.  I love the current format.  I have full control of what
webapps are in use on my system and I don't wish to have to maintain the
build config that has each of my 5 web apps copy from a central
repository instead of just using commons.  I find the current solution
rather elegant because I can use it but am not forced to.


Ack. In contrast, I've sometimes wished to have webapp (classloader)
hierarchies. A context nested in another context would see the outer
classes but would be independently restartable. However, if a parent
context is restarted, all children are restarted, too.
Recently I implemented a Host classloader using a Host Listener and a
custom WebappLoader. Then extended the web app manager app so that it could
reload the Host, all its webapps, and recycle its Host classloader.  
This comes in handy when you want to use shared libraries for all the webapps
deployed for a host but need to be able to update them in a running container.

GLenn

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


Re: [next] What's next ?

2003-10-03 Thread Glenn Nielsen
I proposed a while ago to implement a custom java policy for the
SecurityManager which uses XML for configuring permissions for
the Java SecurityManager.  There were a number of features which
made configuring a strict security policy easier.  You can look
back through the archives for the initial proposal and discussion.
Glenn

Remy Maucherat wrote:
Usually, when a Tomcat branch nears its release, a new branch is created.

However, I only have a few feature ideas that make some sense, and the 
problem is that they are minor evolutions (hence, they could perfectly 
fit inside the 5.0 branch). This includes:

- Updating JK2 to use the JMX events (the same ones the mapper uses) to 
get autoconfiguration, as an option. That seems useful, but it might 
well be a really stupid thing in the real world.

- Java or native load balancer, with session affinity support. This 
could be the perfect commons project, and is not really related to Tomcat.

- Use an in memory Java compiler to be able to automatically precompile 
webapps upon deployment. I heard such a compiler now exists, and this 
could be added fairly easily if it works well enough. I'm not a very big 
fan, but maybe it would make sense for some people.

So to summarize, I have nothing to propose (sorry), and will focus on 
bugfixes and small additions in the 5.0 branch.

If people want to see something more radical happen for the next major 
release, it's probably time to come up with proposals :)

Remy



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


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


Re: [next] What's next ?

2003-10-03 Thread Glenn Nielsen


Remy Maucherat wrote:
Glenn Nielsen wrote:

I proposed a while ago to implement a custom java policy for the
SecurityManager which uses XML for configuring permissions for
the Java SecurityManager.  There were a number of features which
made configuring a strict security policy easier.  You can look
back through the archives for the initial proposal and discussion.


It's an open discussion :)

However, I'd say this is an uphill battle. I think Costin argued the 
same earlier, and the standard policy file remained consistent, and 
now added JMX security rather (which is an important feature since we're 
now JMX based). So well, I don't know ...

Remy


From what I recall of the discussion, the issue was not with adding
this as a feature, but with how it was implemented using Castor.
For those who have to maintain strict java security policies the current
policy file format of granting permissions is a pain to use.  The XML
based policy feature I designed is much easier to use.
Regards,

Glenn

--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: mod_jk release packaging and connector download move to www.apache.org/dist mirror and archive.apache.org

2003-09-30 Thread Glenn Nielsen
jean-frederic clere wrote:
Glenn Nielsen wrote:

Joseph Shraibman wrote:

./configure -with-apxs=/usr/local/apache2/bin/apxsGlenn Nielsen wrote:

As part of the mod_jk 1.2.5 release I promised to move the JTC 
download to




BTW you forgot to generate a configure file for the release, users 
will have to run buildconf.sh

Running buildconf.sh is in the building mod_jk from source instructions.


That is not what the other products are doing and that will bring 
complex questions about autoconf/automake. I think we have to deliver a 
configure not a configure.in

Ok, I'll run buildconf.sh and reupload the source dist.

Glenn

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


Re: [5.0] Schedule change

2003-09-30 Thread Glenn Nielsen


Remy Maucherat wrote:
Hi,

The signals I'm getting from Sun about the schedule of the 
specifications is highly confusing. Since I'm tired of having Tomcat 
depend on these, I propose taking advantage of the backwards 
compatibility of the spec, and replacing the TC 5 statement phrase with:

The 5.x releases implement the Servlet 2.3 and JSP 1.2 specifications, 
and will add support for the Servlet 2.4 and JSP 2.0 as soon as they are 
officially available.

That would allow making a timely 5.0 release, rather than expecting 
stuff for an indefinite amount of time ...

If I don't get yelled at too much, I'll call for a vote on this.

Comments ?



How much work is it to revert Tomcat 5 back to Sevlet 2.3/JSP 1.2?

And I agree with Costin that we should keep the major revision tied
to the versions of the Servlet/JSP spec.
Glenn

--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


mod_jk release packaging and connector download move to www.apache.org/dist mirror and archive.apache.org

2003-09-29 Thread Glenn Nielsen
As part of the mod_jk 1.2.5 release I promised to move the JTC download to
www.apache.org/dist so that the downloads can be mirrored.  Here are the
changes I propose to make as I set this up.
First, here is the directory layout for mirrored downloads at
/www/www.apache.org/dist/jakarta/tomcat-connectors :
KEYS
jk
jk/README.html
jk/jakarta-tomcat-connectors-jk-1.2-src-current.tar.gz -
 jk/source/jakarta-tomcat-connectors-jk-1.2.5-src.tar.gz
jk/jakarta-tomcat-connectors-jk-1.2-src-current.tar.gz.asc -
 jk/source/jakarta-tomcat-connectors-jk-1.2.5-src.tar.gz.asc
jk/binaries
jk/binaries/aix
jk/binaries/freebsd
jk/binaries/iseries
jk/binaries/linux
jk/binaries/macosx
jk/binaries/netware
jk/binaries/solaris
jk/binaries/win32
jk/source
jk/source/jakarta-tomcat-connectors-jk-1.2.5-src.tar.gz
jk/source/jakarta-tomcat-connectors-jk-1.2.5-src.tar.gz.asc
jk2
jk2/README.html
jk2/jakarta-tomcat-connectors-jk-2.0-src-current.tar.gz -
  jk2/source/jakarta-tomcat-connectors-jk-2.0.2-src.tar.gz
jk2/jakarta-tomcat-connectors-jk-2.0-src-current.tar.gz.asc -
  jk2/source/jakarta-tomcat-connectors-jk-2.0.2-src.tar.gz.asc
jk2/binaries
jk2/binaries/aix
jk2/binaries/freebsd
jk2/binaries/iseries
jk2/binaries/linux
jk2/binaries/macosx
jk2/binaries/netware
jk2/binaries/solaris
jk2/binaries/win32
jk2/source
jk2/source/jakarta-tomcat-connectors-jk-2.0.2-src.tar.gz
jk2/source/jakarta-tomcat-connectors-jk-2.0.2-src.tar.gz.asc
Each binary directory would contain a tar.gz, rpm, or zip for the binary release
rather than .dll or .so files.  The archive would be named:
jakarta-tomcat-connector-jk-{version}-{OS-Version-CPU}-{Webserver}.tar.gz (.zip for 
windows, .rpm for linux rpm's)
linux rpms would go in the binaries/linux directory.
Here is an example for mod_jk 1.2.5 for FreeBsd on i386 for apache 2:

jakarta-tomcat-connector-jk-1.2.5-freebsd4.8-i386-apache-2.0.47.tar.gz

This will allow us to put multiple binaries in the same directory for different
jk release versions, OS versions, and web server versions and make managing
the mirrored download and archive.apache.org directories easier.
httpd includes the source with their binary distributions, I recommend that we do
the same.  The binary release should contain the contents of the source release
plus the binary files.
Here is what I propose we do:

1. Coyote - /www/jakarta.apache.org/builds/jakarta-tomcat-connectors/coyote/release/

This contains 9 coyote connector beta release and one release candidate.

Do we need to keep these?  If not, since coyote comes with the Tomcat releases,
why not completely remove coyote from the tomcat-connectors download?
+1 to remove coyote from the download completely since it is part of the Tomcat release.

If we keep them, I will make the following changes.

Take each release directory and create both a tar.gz and .zip for the
release, sign each.  i.e.  The jar files in v1.0-b1 are put into
apache-tomcat-coyote-1.0-b1.tar.gz.
Place the tar.gz and zip files in the
/www/archive.apache.org/dist/jakarta/tomcat-connectors/coyote/binaries/ directory.
2. JK1.2 /www/jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/

Remove the docs directory, point users to jakarta.apache.org/tomcat in the README.html.

Remove the nightly directory, no nightlies have been done.

Reorganize the releases as described above.  Move old releases to 
archive.apache.org/dist,
move the current release to www.apache.org/dist .
3. JK2 /www/jakarta.apache.org/builds/jakarta-tomcat-connectors/jk2/

Remove the docs directory, point users to jakarta.apache.org/tomcat in the README.html.

Remove the nightly directory, last nightly was done Oct. 5 2002.

Reorganize the releases as described above.  Move old releases to 
archive.apache.org/dist,
move the current release to www.apache.org/dist .
4. Add a section to http://jakarta.apache.org/site/sourceindex.cgi for downloading 
the
tomcat connectors from the mirror.
5. Use a .htaccess file to add  a permanent redirect for 
jakarta.apache.org/builds/jakarta-tomcat-connectors to
www.apache.org/dist/jakarta/tomcat-connectors/ .
Comments and suggestions welcome.

Regards,

Glenn



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


Re: mod_jk release packaging and connector download move to www.apache.org/dist mirror and archive.apache.org

2003-09-29 Thread Glenn Nielsen


Henri Gomez wrote:
Glenn Nielsen a écrit :

As part of the mod_jk 1.2.5 release I promised to move the JTC 
download to
www.apache.org/dist so that the downloads can be mirrored.  Here are the
changes I propose to make as I set this up.

First, here is the directory layout for mirrored downloads at
/www/www.apache.org/dist/jakarta/tomcat-connectors :
KEYS
jk
jk/README.html
jk/jakarta-tomcat-connectors-jk-1.2-src-current.tar.gz -
 jk/source/jakarta-tomcat-connectors-jk-1.2.5-src.tar.gz
jk/jakarta-tomcat-connectors-jk-1.2-src-current.tar.gz.asc -
 jk/source/jakarta-tomcat-connectors-jk-1.2.5-src.tar.gz.asc
jk/binaries
jk/binaries/aix
jk/binaries/freebsd
jk/binaries/iseries
jk/binaries/linux
jk/binaries/macosx
jk/binaries/netware
jk/binaries/solaris
jk/binaries/win32
jk/source
jk/source/jakarta-tomcat-connectors-jk-1.2.5-src.tar.gz
jk/source/jakarta-tomcat-connectors-jk-1.2.5-src.tar.gz.asc
jk2
jk2/README.html
jk2/jakarta-tomcat-connectors-jk-2.0-src-current.tar.gz -
  jk2/source/jakarta-tomcat-connectors-jk-2.0.2-src.tar.gz
jk2/jakarta-tomcat-connectors-jk-2.0-src-current.tar.gz.asc -
  jk2/source/jakarta-tomcat-connectors-jk-2.0.2-src.tar.gz.asc
jk2/binaries
jk2/binaries/aix
jk2/binaries/freebsd
jk2/binaries/iseries
jk2/binaries/linux
jk2/binaries/macosx
jk2/binaries/netware
jk2/binaries/solaris
jk2/binaries/win32
jk2/source
jk2/source/jakarta-tomcat-connectors-jk-2.0.2-src.tar.gz
jk2/source/jakarta-tomcat-connectors-jk-2.0.2-src.tar.gz.asc
Each binary directory would contain a tar.gz, rpm, or zip for the 
binary release
rather than .dll or .so files.  The archive would be named:

jakarta-tomcat-connector-jk-{version}-{OS-Version-CPU}-{Webserver}.tar.gz 
(.zip for windows, .rpm for linux rpm's)
linux rpms would go in the binaries/linux directory.

Here is an example for mod_jk 1.2.5 for FreeBsd on i386 for apache 2:

jakarta-tomcat-connector-jk-1.2.5-freebsd4.8-i386-apache-2.0.47.tar.gz

This will allow us to put multiple binaries in the same directory for 
different
jk release versions, OS versions, and web server versions and make 
managing
the mirrored download and archive.apache.org directories easier.

httpd includes the source with their binary distributions, I recommend 
that we do
the same.  The binary release should contain the contents of the 
source release
plus the binary files.

Here is what I propose we do:

1. Coyote - 
/www/jakarta.apache.org/builds/jakarta-tomcat-connectors/coyote/release/

This contains 9 coyote connector beta release and one release candidate.

Do we need to keep these?  If not, since coyote comes with the Tomcat 
releases,
why not completely remove coyote from the tomcat-connectors download?

+1 to remove coyote from the download completely since it is part of 
the Tomcat release.

If we keep them, I will make the following changes.

Take each release directory and create both a tar.gz and .zip for the
release, sign each.  i.e.  The jar files in v1.0-b1 are put into
apache-tomcat-coyote-1.0-b1.tar.gz.
Place the tar.gz and zip files in the
/www/archive.apache.org/dist/jakarta/tomcat-connectors/coyote/binaries/ 
directory.

2. JK1.2 /www/jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/

Remove the docs directory, point users to jakarta.apache.org/tomcat in 
the README.html.

Remove the nightly directory, no nightlies have been done.

Reorganize the releases as described above.  Move old releases to 
archive.apache.org/dist,
move the current release to www.apache.org/dist .

3. JK2 /www/jakarta.apache.org/builds/jakarta-tomcat-connectors/jk2/

Remove the docs directory, point users to jakarta.apache.org/tomcat in 
the README.html.

Remove the nightly directory, last nightly was done Oct. 5 2002.

Reorganize the releases as described above.  Move old releases to 
archive.apache.org/dist,
move the current release to www.apache.org/dist .

4. Add a section to http://jakarta.apache.org/site/sourceindex.cgi for 
downloading the
tomcat connectors from the mirror.

5. Use a .htaccess file to add  a permanent redirect for 
jakarta.apache.org/builds/jakarta-tomcat-connectors to
www.apache.org/dist/jakarta/tomcat-connectors/ .

Comments and suggestions welcome.


I'm fine with it but the Linux RPMs are problematic since there is by 
now just too many distributions to follow :

- Redhat 6.x, 7.x, 8.x/9.x
- Suse
- Mandrake.
There is way too mixed case, Apache 1.3, 2.0, 1.3 with SSL, so I suggest 
to make a link to www.jpackage.org which take care of all the current 
distro and produce rpms accordingly...

I am not familiar with jpackage, are you saying that they are creating
distributions of mod_jk for linux?
Glenn

--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network

Re: mod_jk release packaging and connector download move to www.apache.org/dist mirror and archive.apache.org

2003-09-29 Thread Glenn Nielsen


Remy Maucherat wrote:
Glenn Nielsen wrote:

1. Coyote - 
/www/jakarta.apache.org/builds/jakarta-tomcat-connectors/coyote/release/

This contains 9 coyote connector beta release and one release candidate.

Do we need to keep these?  If not, since coyote comes with the Tomcat 
releases,
why not completely remove coyote from the tomcat-connectors download?

+1 to remove coyote from the download completely since it is part of 
the Tomcat release.


+1.

2. JK1.2 /www/jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/

Remove the docs directory, point users to jakarta.apache.org/tomcat in 
the README.html.

Remove the nightly directory, no nightlies have been done.

Reorganize the releases as described above.  Move old releases to 
archive.apache.org/dist,
move the current release to www.apache.org/dist .

3. JK2 /www/jakarta.apache.org/builds/jakarta-tomcat-connectors/jk2/

Remove the docs directory, point users to jakarta.apache.org/tomcat in 
the README.html.

Remove the nightly directory, last nightly was done Oct. 5 2002.

Reorganize the releases as described above.  Move old releases to 
archive.apache.org/dist,
move the current release to www.apache.org/dist .


What will the new docs location be, then (I need to link it from the 
main TC docs) ?

There are already docs for jk/jk2 in the tomcat docs directory:

I was going to point the README.html file at:

http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jk2/index.html

The goal is to only put source or binary distributions on www.apache.org/dist
and keep all the docs at jakarta.apacheo.org/tomcat/ .
Generated docs for a specific version are also available within the source 
distribution.

Regards,

Glenn

--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: mod_jk release packaging and connector download move to www.apache.org/dist mirror and archive.apache.org

2003-09-29 Thread Glenn Nielsen


jean-frederic clere wrote:
Henri Gomez wrote:

Glenn Nielsen a écrit :

As part of the mod_jk 1.2.5 release I promised to move the JTC 
download to
www.apache.org/dist so that the downloads can be mirrored.  Here are the
changes I propose to make as I set this up.

First, here is the directory layout for mirrored downloads at
/www/www.apache.org/dist/jakarta/tomcat-connectors :
KEYS
jk
jk/README.html
jk/jakarta-tomcat-connectors-jk-1.2-src-current.tar.gz -
 jk/source/jakarta-tomcat-connectors-jk-1.2.5-src.tar.gz
jk/jakarta-tomcat-connectors-jk-1.2-src-current.tar.gz.asc -
 jk/source/jakarta-tomcat-connectors-jk-1.2.5-src.tar.gz.asc
jk/binaries
jk/binaries/aix
jk/binaries/freebsd
jk/binaries/iseries
jk/binaries/linux
jk/binaries/macosx
jk/binaries/netware
jk/binaries/solaris
jk/binaries/win32
jk/source
jk/source/jakarta-tomcat-connectors-jk-1.2.5-src.tar.gz
jk/source/jakarta-tomcat-connectors-jk-1.2.5-src.tar.gz.asc
jk2
jk2/README.html
jk2/jakarta-tomcat-connectors-jk-2.0-src-current.tar.gz -
  jk2/source/jakarta-tomcat-connectors-jk-2.0.2-src.tar.gz
jk2/jakarta-tomcat-connectors-jk-2.0-src-current.tar.gz.asc -
  jk2/source/jakarta-tomcat-connectors-jk-2.0.2-src.tar.gz.asc
jk2/binaries
jk2/binaries/aix
jk2/binaries/freebsd
jk2/binaries/iseries
jk2/binaries/linux
jk2/binaries/macosx
jk2/binaries/netware
jk2/binaries/solaris
jk2/binaries/win32
jk2/source
jk2/source/jakarta-tomcat-connectors-jk-2.0.2-src.tar.gz
jk2/source/jakarta-tomcat-connectors-jk-2.0.2-src.tar.gz.asc
Each binary directory would contain a tar.gz, rpm, or zip for the 
binary release
rather than .dll or .so files.  The archive would be named:

jakarta-tomcat-connector-jk-{version}-{OS-Version-CPU}-{Webserver}.tar.gz 
(.zip for windows, .rpm for linux rpm's)
linux rpms would go in the binaries/linux directory.

Here is an example for mod_jk 1.2.5 for FreeBsd on i386 for apache 2:

jakarta-tomcat-connector-jk-1.2.5-freebsd4.8-i386-apache-2.0.47.tar.gz

This will allow us to put multiple binaries in the same directory for 
different
jk release versions, OS versions, and web server versions and make 
managing
the mirrored download and archive.apache.org directories easier.

httpd includes the source with their binary distributions, I 
recommend that we do
the same.  The binary release should contain the contents of the 
source release
plus the binary files.

Here is what I propose we do:

1. Coyote - 
/www/jakarta.apache.org/builds/jakarta-tomcat-connectors/coyote/release/

This contains 9 coyote connector beta release and one release candidate.

Do we need to keep these?  If not, since coyote comes with the Tomcat 
releases,
why not completely remove coyote from the tomcat-connectors download?

+1 to remove coyote from the download completely since it is part of 
the Tomcat release.

If we keep them, I will make the following changes.

Take each release directory and create both a tar.gz and .zip for the
release, sign each.  i.e.  The jar files in v1.0-b1 are put into
apache-tomcat-coyote-1.0-b1.tar.gz.
Place the tar.gz and zip files in the
/www/archive.apache.org/dist/jakarta/tomcat-connectors/coyote/binaries/ 
directory.

2. JK1.2 /www/jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/

Remove the docs directory, point users to jakarta.apache.org/tomcat 
in the README.html.

Remove the nightly directory, no nightlies have been done.

Reorganize the releases as described above.  Move old releases to 
archive.apache.org/dist,
move the current release to www.apache.org/dist .

3. JK2 /www/jakarta.apache.org/builds/jakarta-tomcat-connectors/jk2/

Remove the docs directory, point users to jakarta.apache.org/tomcat 
in the README.html.

Remove the nightly directory, last nightly was done Oct. 5 2002.

Reorganize the releases as described above.  Move old releases to 
archive.apache.org/dist,
move the current release to www.apache.org/dist .

4. Add a section to http://jakarta.apache.org/site/sourceindex.cgi 
for downloading the
tomcat connectors from the mirror.

And something like: 
http://www.apache.org/dyn/closer.cgi/jakarta-tomcat-connectors/jk2/ in 
the mod_jk documentation we have a link to download.

Ok, nice catch.  Yes, the docs will need to have any links to the
mod_jk download page fixed.
5. Use a .htaccess file to add  a permanent redirect for 
jakarta.apache.org/builds/jakarta-tomcat-connectors to
www.apache.org/dist/jakarta/tomcat-connectors/ .

Comments and suggestions welcome.


I'm fine with it but the Linux RPMs are problematic since there is by 
now just too many distributions to follow :

- Redhat 6.x, 7.x, 8.x/9.x
- Suse
- Mandrake.
There is way too mixed case, Apache 1.3, 2.0, 1.3 with SSL, so I 
suggest to make a link to www.jpackage.org which take care of all the 
current distro and produce rpms accordingly...


The *.so are quite easy to use 
jakarta-tomcat-connector-jk-{version}-{OS-Version-CPU}-{Webserver}.so

I'm ok with that as long as we no longer need a separate directory for
each released version.  I still

Re: mod_jk release packaging and connector download move to www.apache.org/dist mirror and archive.apache.org

2003-09-29 Thread Glenn Nielsen
Joseph Shraibman wrote:
./configure -with-apxs=/usr/local/apache2/bin/apxsGlenn Nielsen wrote:

As part of the mod_jk 1.2.5 release I promised to move the JTC 
download to


BTW you forgot to generate a configure file for the release, users will 
have to run buildconf.sh

Running buildconf.sh is in the building mod_jk from source instructions.

Glenn



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


Re: mod_jk release packaging and connector download move to www.apache.org/dist mirror and archive.apache.org

2003-09-29 Thread Glenn Nielsen
I have completed most of the below.

The directory layout is setup in
/www/www.apache.org/dist/jakarta/tomcat-connectors and
/www/archive.apache.org/dist/jakarta/tomcat-connectors .
The old coyote beta and milestone releases have been removed.
The webapp releases have been moved to the archive.
The latest jk2 release is setup on the mirror and previous releases
are in the archive.
The mod_jk 1.2.5 source distribution has been released on the mirror,
previous versions have been copied to the archive.
The jakarta site binindex.cgi and sourceindex.cgi have been updated.
The jk docs in the Tomcat 4.1 directory have been updated with the
download links fixed.
For now I am leaving the current jk/jk2 releases in place on the jakarta
site.  After a few days I will remove them and put the .htaccess file in place.
The mod_jk 1.2.5 release is now accepting binary releases.  Please consider
the following when packaging your binary release distributions:
Build binaries and upload distributions to www.apache.org
--
Build mod_jk for a specific web server and OS.  Package it as appropriate for
the OS and sign the archive using PGP. Please include the ASF License, the
generated docs, and the tools.  Please name the distribuiton as follows:
jakarta-tomcat-connectors-jk-{version}-{os-version-cpu}-{web server-version}.(tar.gz|zip)

scp the binary distribution and pgp signature file to the appropriate binaries/{os} directory.

Make sure the group write bit is on for all files you upload.

I will send out the announcement in a few days once some binaries have accumulated
and the mirrors have had a chance to rsync them.
Thanks,

Glenn

Glenn Nielsen wrote:
As part of the mod_jk 1.2.5 release I promised to move the JTC download to
www.apache.org/dist so that the downloads can be mirrored.  Here are the
changes I propose to make as I set this up.
First, here is the directory layout for mirrored downloads at
/www/www.apache.org/dist/jakarta/tomcat-connectors :
KEYS
jk
jk/README.html
jk/jakarta-tomcat-connectors-jk-1.2-src-current.tar.gz -
 jk/source/jakarta-tomcat-connectors-jk-1.2.5-src.tar.gz
jk/jakarta-tomcat-connectors-jk-1.2-src-current.tar.gz.asc -
 jk/source/jakarta-tomcat-connectors-jk-1.2.5-src.tar.gz.asc
jk/binaries
jk/binaries/aix
jk/binaries/freebsd
jk/binaries/iseries
jk/binaries/linux
jk/binaries/macosx
jk/binaries/netware
jk/binaries/solaris
jk/binaries/win32
jk/source
jk/source/jakarta-tomcat-connectors-jk-1.2.5-src.tar.gz
jk/source/jakarta-tomcat-connectors-jk-1.2.5-src.tar.gz.asc
jk2
jk2/README.html
jk2/jakarta-tomcat-connectors-jk-2.0-src-current.tar.gz -
  jk2/source/jakarta-tomcat-connectors-jk-2.0.2-src.tar.gz
jk2/jakarta-tomcat-connectors-jk-2.0-src-current.tar.gz.asc -
  jk2/source/jakarta-tomcat-connectors-jk-2.0.2-src.tar.gz.asc
jk2/binaries
jk2/binaries/aix
jk2/binaries/freebsd
jk2/binaries/iseries
jk2/binaries/linux
jk2/binaries/macosx
jk2/binaries/netware
jk2/binaries/solaris
jk2/binaries/win32
jk2/source
jk2/source/jakarta-tomcat-connectors-jk-2.0.2-src.tar.gz
jk2/source/jakarta-tomcat-connectors-jk-2.0.2-src.tar.gz.asc
Each binary directory would contain a tar.gz, rpm, or zip for the binary 
release
rather than .dll or .so files.  The archive would be named:

jakarta-tomcat-connector-jk-{version}-{OS-Version-CPU}-{Webserver}.tar.gz 
(.zip for windows, .rpm for linux rpm's)
linux rpms would go in the binaries/linux directory.

Here is an example for mod_jk 1.2.5 for FreeBsd on i386 for apache 2:

jakarta-tomcat-connector-jk-1.2.5-freebsd4.8-i386-apache-2.0.47.tar.gz

This will allow us to put multiple binaries in the same directory for 
different
jk release versions, OS versions, and web server versions and make managing
the mirrored download and archive.apache.org directories easier.

httpd includes the source with their binary distributions, I recommend 
that we do
the same.  The binary release should contain the contents of the source 
release
plus the binary files.

Here is what I propose we do:

1. Coyote - 
/www/jakarta.apache.org/builds/jakarta-tomcat-connectors/coyote/release/

This contains 9 coyote connector beta release and one release candidate.

Do we need to keep these?  If not, since coyote comes with the Tomcat 
releases,
why not completely remove coyote from the tomcat-connectors download?

+1 to remove coyote from the download completely since it is part of the 
Tomcat release.

If we keep them, I will make the following changes.

Take each release directory and create both a tar.gz and .zip for the
release, sign each.  i.e.  The jar files in v1.0-b1 are put into
apache-tomcat-coyote-1.0-b1.tar.gz.
Place the tar.gz and zip files in the
/www/archive.apache.org/dist/jakarta/tomcat-connectors/coyote/binaries/ 
directory.

2. JK1.2 /www/jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/

Remove the docs directory, point users to jakarta.apache.org/tomcat in 
the README.html.

Remove the nightly directory, no nightlies have

Re: mod_jk 1.2.5 test release source distribution

2003-09-25 Thread Glenn Nielsen
Henri Gomez wrote:
Glenn Nielsen a écrit :

I have generated a test release source distribution for mod_jk 1.2.5,
you can find it at:
http://jakarta.apache.org/~glenn/jakarta-tomcat-connectors-jk-1.2.5-src.tar.gz 

Please build and test on as many OS/web servers as possible.

I have already tested on Solaris7/8 Sparc.

If there are no problems with this source release I will call for a
release vote Friday 9/12 and release Monday 9/15 if the vote passes.
Regards,

Glenn


Glenn, could you tag JTC 1.2.5 so I could commit my work on JTC  ?

I would like to see modjk 1.2.5 tagged/released before committing
this.  I was waiting on a report for Windows before releasign,
we now have that.  I'll post a release vote shortly.
Glenn

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


[VOTE] release mod_jk 1.2.5

2003-09-25 Thread Glenn Nielsen
The test results are in.  No problems have been reported with
the mod_jk 1.2.5 test release.
ballot
 [ ] +1 release mod_jk 1.2.5 and I will help by building binaries for ___
 [ ] +0 release mod_jk 1.2.5
 [ ] -0 please don't release, reason __
 [ ] -1 you can't release because of __
/ballot
Voting closes saturday morning.  If the vote is to release, I will
release the source over the weekend.
Regards,

Glenn

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


Re: [VOTE] release mod_jk 1.2.5

2003-09-25 Thread Glenn Nielsen
Glenn Nielsen wrote:
The test results are in.  No problems have been reported with
the mod_jk 1.2.5 test release.
ballot
 [X] +1 release mod_jk 1.2.5 and I will help by building binaries for 
  Mac OS X/Solaris Sparc/FreeBSD 4.8, Apache 1.3/2.0
/ballot


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


Re: mod_jk 1.2.5 test release source distribution

2003-09-25 Thread Glenn Nielsen
Glenn Nielsen wrote:
Henri Gomez wrote:

Glenn, could you tag JTC 1.2.5 so I could commit my work on JTC  ?

I would like to see modjk 1.2.5 tagged/released before committing
this.  I was waiting on a report for Windows before releasign,
we now have that.  I'll post a release vote shortly.
mod_jk_1_2_5 has been tagged in CVS, the HEAD is now mod_jk 1.2.6-dev.

Glenn

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


[Fwd: Re: mod_jk does not detect a hung Tomcat]

2003-09-25 Thread Glenn Nielsen
Bill Barker wrote:
- Original Message -
From: Glenn Nielsen [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Wednesday, September 24, 2003 12:28 PM
Subject: Re: mod_jk does not detect a hung Tomcat


Henri Gomez wrote:

David Rees a écrit :


Henri Gomez said:


Henri Gomez a écrit :


Nope since you don't have to just test at protocol level but also on
higher level, for instance check the full chain, up to servlet
handling.


It's easy to simulate this behavior by sending a STOP signal to
Tomcat.
I've also attached a log from mod_jk showing the problem.  I marked
the
point at which processing in mod_jk stopped until I sent a CONT
signal to
tomcat.
Does mod_jk2 have this same problem?  Is there any interest in

fixing

this? Does anyone have a workaround for this issue?


Well, if you have a hung tomcat, you're probably allready in serious
trouble.

No, actually in my case I wasn't.  I had two Tomcats running, as one

was

prone to locking up due to a JVM or application bug.  With a 50-50 load
distribution between two Tomcats, this left me with 1/2 of the requests
getting stuck and clients waiting forever and tying up Apache
processes. Eventually, a DOS will be the result if action is not taken
in time.  If
mod_jk noticed it wasn't really alive, this wouldn't be an issue at

all.


Anyway, if we add stuff like time-out in ajp request, you could be
stuck with long running servlets. Also jk read request in a blocking
mode for performance and adding timeout here is not an option.

Agreed that we wouldn't want a timeout normally to handle normal long
running servlet processes, but if there was a PING/PONG added to the
protocol there should be a timeout to prevent the above situation.


When I worked on ajp13++ (ajp14) protocol, I added a more secure auth
mecanism at connection time.
Since there is a bidirectionnal communication, jk could detect that
even if the connection is open, the remote didn't respond and so fall
back to the next in cluster configuration.
But on allready established connections, the problem persist.

Or we should add a PING/PONG before sending any request to tomcat.

It could be done as optional but I work on it only if many users make
such requirements


if many users ask for such feature ;)


Well, you've got one so far.  ;-)  Adding a configurable option to have
mod_jk verify (PING/PONG) that Tomcat is actually responding before

using

the connection would solve the problem and I can't imagine that it

would

add a lot of complexity to the code as well.  If I wasn't so rusty
with my
C programming and had some spare time, I would offer to help code it
up. ;-)  In any case, I'll be more than happy to help test.


Well, if you could find more users or at least one tomcat commiter
(Glenn, Remy, Costin, JFC...) who need it, I'll add the necessary code
in java and C areas ;)


There may be a simple way to achieve what David is asking for without
setting a request timeout or implementing a PING/PONG between mod_jk
and Tomcat.
What if each worker tracked the number of requests which were handled
by the worker since the last successful completion of a request.
i.e. add the following to a worker

worker-last_completed // Time in seconds since last successfully
completed request

worker-requests_since_last_completed  // Number of requests sent to
worker

since last successful completion.

Then logic could be added to try and detect an instance of Tomcat which
has

failed.  Perhaps even allow several additional worker properties to
determine

when mod_jk should consider the worker failed.


This won't work  with the pre-fork MPM, since each Apache child will have
its own idea of the timing.  The only way that it could tell that a Tomcat
failed is to try the request and fail :).
Argh, you are right, this goes back to the age old problem of not being able
to write a global worker connection pool or shared memory with the current code.
The only way to move forward would be to rewrite mod_jk 1.2 to use APR.

Glenn

--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--


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


Re: mod_jk 1.2.5 test release source distribution

2003-09-25 Thread Glenn Nielsen
The test release at cvs.apache.org/~glenn is what will be released
with no changes and does reflect the source which was tagged as
mod_jk_1_2_5.
So yes, you can use binaries built from that source as mod_jk 1.2.5 release binaries.

Regards,

Glenn

Jess Holle wrote:
Were there any changes since the test release, i.e. does the tagging 
reflect (minus release notes, etc) the test release?

[I'm asking as I've built binaries for all platforms I need from the 
test release and would like to avoid rebuilding all of them]

Glenn Nielsen wrote:

Glenn Nielsen wrote:

Henri Gomez wrote:

Glenn, could you tag JTC 1.2.5 so I could commit my work on JTC  ?

I would like to see modjk 1.2.5 tagged/released before committing
this.  I was waiting on a report for Windows before releasign,
we now have that.  I'll post a release vote shortly.
mod_jk_1_2_5 has been tagged in CVS, the HEAD is now mod_jk 1.2.6-dev.

Glenn

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




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


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


Re: mod_jk 1.2.5 test release source distribution

2003-09-25 Thread Glenn Nielsen


Henri Gomez wrote:
Glenn Nielsen a écrit :

The test release at cvs.apache.org/~glenn is what will be released
with no changes and does reflect the source which was tagged as
mod_jk_1_2_5.
So yes, you can use binaries built from that source as mod_jk 1.2.5 
release binaries.


So I could commit my changes in 1.2.6-dev ?

There is C and java ;-)

You can commit your changes to HEAD.

Glenn

--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: mod_jk 1.2.5 test release source distribution

2003-09-25 Thread Glenn Nielsen
Mike,

I have built using the test release of mod_jk 1.2.5 and for me
it does not have -dev.  Looking at jk_version.h in the source
release it is properly defined for a release.
Glenn

Mike Anderson wrote:
There is one minor change to jk_version.h so that the module reports
that it is version 1.2.5 instead of 1.2.5-dev.  If you already cheated
and modified that locally, or you don't care what it reports, you should
be fine.
Mike Anderson


[EMAIL PROTECTED] 9/25/2003 8:00:54 AM 

The test release at cvs.apache.org/~glenn is what will be released
with no changes and does reflect the source which was tagged as
mod_jk_1_2_5.
So yes, you can use binaries built from that source as mod_jk 1.2.5
release binaries.
Regards,

Glenn

Jess Holle wrote:

Were there any changes since the test release, i.e. does the tagging


reflect (minus release notes, etc) the test release?

[I'm asking as I've built binaries for all platforms I need from the


test release and would like to avoid rebuilding all of them]

Glenn Nielsen wrote:


Glenn Nielsen wrote:


Henri Gomez wrote:


Glenn, could you tag JTC 1.2.5 so I could commit my work on JTC 

?

I would like to see modjk 1.2.5 tagged/released before committing
this.  I was waiting on a report for Windows before releasign,
we now have that.  I'll post a release vote shortly.
mod_jk_1_2_5 has been tagged in CVS, the HEAD is now mod_jk

1.2.6-dev.

Glenn




-

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






-

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





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

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


--
--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: mod_jk 1.2.5 test release source distribution

2003-09-25 Thread Glenn Nielsen
I am making fewer mistakes with the releases since I wrote up the doc
jk/HOW-TO-RELEASE. ;-)
Mike Anderson wrote:
Looks like Gleen was ahead of the game (as usual :-) and I was confused
between what was in CVS and his tarball.  Sorry for my misinformation.

[EMAIL PROTECTED] 9/25/2003 8:38:51 AM 

Actually from my reading of jk_version.h this change was already made
in 
the test release.  [And the version string shows up as 1.2.5 on
Windows.]

Mike Anderson wrote:


There is one minor change to jk_version.h so that the module reports
that it is version 1.2.5 instead of 1.2.5-dev.  If you already
cheated

and modified that locally, or you don't care what it reports, you
should

be fine.

Mike Anderson




[EMAIL PROTECTED] 9/25/2003 8:00:54 AM 
  


The test release at cvs.apache.org/~glenn is what will be released
with no changes and does reflect the source which was tagged as
mod_jk_1_2_5.
So yes, you can use binaries built from that source as mod_jk 1.2.5
release binaries.
Regards,

Glenn

Jess Holle wrote:



Were there any changes since the test release, i.e. does the tagging
  





reflect (minus release notes, etc) the test release?

[I'm asking as I've built binaries for all platforms I need from the
  





test release and would like to avoid rebuilding all of them]

Glenn Nielsen wrote:

  


Glenn Nielsen wrote:




Henri Gomez wrote:

  


Glenn, could you tag JTC 1.2.5 so I could commit my work on JTC 



?



I would like to see modjk 1.2.5 tagged/released before committing
this.  I was waiting on a report for Windows before releasign,
we now have that.  I'll post a release vote shortly.
  

mod_jk_1_2_5 has been tagged in CVS, the HEAD is now mod_jk



1.2.6-dev.



Glenn






-



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










  

-



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

  



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

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






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


--
--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: ManagerServlet undeploy

2003-09-18 Thread Glenn Nielsen
This is required for when the web app is not run from a war but
unpacked into the appDir for the Host.
I think it is a reasonable restriction to require that a web application
be placed in the appDir configured for the Host.  When you are running
with the SecurityManager this can make setting the security policy easier.
Glenn

Amy Roh wrote:
Undeploy fails for any app that's not installed under webapps directory. 
 For example, an attempt to undeploy /admin will fail with Cannot 
undeploy document base for path /admin because of the following lines 
from ManagerServlet line 1384

// Validate the docBase path of this application
String deployedPath = deployed.getCanonicalPath();
String docBase = context.getDocBase();
File docBaseDir = new File(docBase);
if (!docBaseDir.isAbsolute()) {
docBaseDir = new File(appBaseDir, docBase);
}
String docBasePath = docBaseDir.getCanonicalPath();
if (!docBasePath.startsWith(deployedPath)) {
writer.println(sm.getString(managerServlet.noDocBase,
displayPath));
return;
}
Any app that's installed using context configuration file with docBase 
other than ../webapps will not pass the condition since deployedPath 
is always ../webapps.

What is the reasoning behind this validation?

Thanks,
Amy


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


--
--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: mod_jk 1.2.5 test release source distribution

2003-09-15 Thread Glenn Nielsen


Henri Gomez wrote:
Glenn Nielsen a écrit :

Thanks Kurt!

It would be nice to see more reports for other OS/web servers before
the final release is done.


It works for me on iSeries and Linux



Great, Thanks Henri.

I haven't seen any reports for Windows/IIS yet.

Glenn

--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: mod_jk 1.2.5 test release source distribution

2003-09-14 Thread Glenn Nielsen
Thanks Kurt!

It would be nice to see more reports for other OS/web servers before
the final release is done.
Glenn

Kurt Miller wrote:
From: Glenn Nielsen [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Sunday, September 07, 2003 12:26 AM
Subject: mod_jk 1.2.5 test release source distribution


I have generated a test release source distribution for mod_jk 1.2.5,
you can find it at:

http://jakarta.apache.org/~glenn/jakarta-tomcat-connectors-jk-1.2.5-src.tar.gz

Please build and test on as many OS/web servers as possible.

I have already tested on Solaris7/8 Sparc.

If there are no problems with this source release I will call for a
release vote Friday 9/12 and release Monday 9/15 if the vote passes.
Regards,

Glenn


I have tested the test release on OpenBSD i386 and sparc64. No problems have
been found.
Regards,
-Kurt
-
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]


jakarta-tomcat-connectors/util build broke for j2sdk 1.3

2003-09-07 Thread Glenn Nielsen
I can no longer build jakarta-tomcat-connectors/util.  It looks like a
dependency for java 1.4 has crept in with how jsse is being used.
Glenn

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


Re: jakarta-tomcat-connectors/util build broke for j2sdk 1.3

2003-09-07 Thread Glenn Nielsen
You had to be using jsse rather than PureTLS and building with jdk  1.4.

It is fixed now.  A new JSSE class was added for JDK1.4 support
but it wasn't excluded from the build if jdk1.4 wasn't present.
Glenn

Bill Barker wrote:
It works fine for me.  I just did an update on j-t-c, and a clean build of
Tomcat 5, and it worked fine (well, up until it got to the docs, but I've
still got an old version of xalan in ant :).
- Original Message - 
From: Glenn Nielsen [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Sunday, September 07, 2003 7:59 PM
Subject: jakarta-tomcat-connectors/util build broke for j2sdk 1.3



I can no longer build jakarta-tomcat-connectors/util.  It looks like a
dependency for java 1.4 has crept in with how jsse is being used.
Glenn

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


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


mod_jk 1.2.5 test release source distribution

2003-09-06 Thread Glenn Nielsen
I have generated a test release source distribution for mod_jk 1.2.5,
you can find it at:
http://jakarta.apache.org/~glenn/jakarta-tomcat-connectors-jk-1.2.5-src.tar.gz

Please build and test on as many OS/web servers as possible.

I have already tested on Solaris7/8 Sparc.

If there are no problems with this source release I will call for a
release vote Friday 9/12 and release Monday 9/15 if the vote passes.
Regards,

Glenn

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


jakarta-tomcat-connector release cleanup

2003-09-06 Thread Glenn Nielsen
I have promised to setup the tomcat connector releases so that they
can be mirrored when I perform the next mod_jk release.  First I have
a few questions.
Are the coyote beta release/milestone releases in
/www/jakarta.apache.org/builds/jakarta-tomcat-connectors/coyote
still needed?  Will there be separate releases of coyote or will
it only be bundled with Tomcat 4/5 releases?
mod_webapp is deprecated so should we continue to have the
/www/jakarta.apache.org/builds/jakarta-tomcat-connectors/webapp
release directory or should this be moved to archive.apache.org?
Can /www/jakarta.apache.org/builds/jakarta-tomcat-connectors/jk2/nightly/
be removed?  The last nightly build of this was October of 2002.
Can the old mod_jk 1.2 and mod_jk2 releases be moved to
archive.apache.org?
Thanks,

Glenn



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


Re: mirror-enable tomcat-connector downloads

2003-09-04 Thread Glenn Nielsen
Stefan Bodewig wrote:
On Wed, 03 Sep 2003, Glenn Nielsen [EMAIL PROTECTED] wrote:

Stefan Bodewig wrote:

On Wed, 03 Sep 2003, Glenn Nielsen [EMAIL PROTECTED] wrote:


We have a release pending for mod_jk 1.2.5,
Does that affect JK2 and JNI and what not as well?
No. Just the mod_jk 1.2 connector source and binary distributions.


Do you want to move the other distributions to the mirrors then as
well or would you prefer somebody else to do it (I'd still volunteer 8-).
Nah, just as easy to move those at the same time mod_jk 1.2 is moved.

Glenn

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


Re: in_addr_t and Linux 2.2

2003-09-04 Thread Glenn Nielsen
FYI, I have put building a test mod_jk 1.2.5 source distribution on hold
pending Henri's work on IPV6.  Henri, please let me know when you think
we are ready for another test source dist.
Thanks,

Glenn

Henri Gomez wrote:
FYI, in_addr_t is not defined on Redhat 6.2 which use kernel 2.2
and glibc 2.1.
Should we also fix this case ?

-
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: in_addr_t and Linux 2.2

2003-09-04 Thread Glenn Nielsen


Henri Gomez wrote:
Glenn Nielsen a écrit :

FYI, I have put building a test mod_jk 1.2.5 source distribution on hold
pending Henri's work on IPV6.  Henri, please let me know when you think
we are ready for another test source dist.


We may add the configure stuff to determine if in_addr_t is available.
I'll take a look at it right now.
BTW, IPV6 will be added in 1.2.6 (or later), so don't delay release for it



OK, so are we ready for a test source release?

Glenn

--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: mirror-enable tomcat-connector downloads

2003-09-03 Thread Glenn Nielsen
Stefan Bodewig wrote:
Hi,

as by now you most probably know, all releases should go through
www.apache.org/dist so they will be mirrored and we (the ASF) can save
money as we pay for the transferred data.  For details please see
http://www.apache.org/dev/mirrors.html and
http://jakarta.apache.org/site/convert-to-mirror.html.
Tomcat 4.1 is using the official distribution location, but AFAICS
no connector distribution is doing so.
I'll be happy to help with the migration ranging from giving advice to
doing it myself, just let me know what is needed.
We have a release pending for mod_jk 1.2.5, I can take care of this
when I do the release.  I migrated jakarta-taglibs to support the
mirror months ago.  Thanks for the offer to help.
On a related note: How does anybody find the connector distributions?

Yesterday I had a customer who insists on placing Tomcat behind IIS
rant about that damned open source software as he failed to locate
iis_redirect.dll.  He started from the location he used to download
the version bundled with 3.2.4 as he couldn't find a link on Tomcat's
pages.  It's rather hard to find them that way.
Even before Robert changed the Jakarta download pages a few hours ago,
there has been no link to a connector download and I cannot find a
link in Tomcat's part of the Jakarta website at all.
I found the JK2 download by following the link in Tomcat's README in
http://www.apache.org/dist/jakarta/tomcat-4/binaries/, but please
note that (1) mirrors may not display that file at all[1] and (2)
almost nobody is going to see the README after the redesign of the
Jakarta download page.
Yeah, this should be made clearer and can be done as part of migrating
mod_jk to support the mirror.  I can publish to the jakarta site so
I will look into this.
Thanks for prodding us Stefan.

Regards,

Glenn



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


Re: mirror-enable tomcat-connector downloads

2003-09-03 Thread Glenn Nielsen


Stefan Bodewig wrote:
On Wed, 03 Sep 2003, Glenn Nielsen [EMAIL PROTECTED] wrote:


We have a release pending for mod_jk 1.2.5,


Does that affect JK2 and JNI and what not as well?

No. Just the mod_jk 1.2 connector source and binary distributions.


I can take care of this when I do the release.


Please do.  And while you are at it, please move all old releases to
archive.apache.org.
Sure.

The ultimate goal should be that jakarta/builds is empty (nightlies
are supposed to be on cvs.apache.org for some reason).
Nightlies were moved to cvs.apache.org a while ago when daedalus was
running out of disk space. Now that jakarta.apache.org and cvs.apache.org
are on the same server it doesn't matter.
Regards,

Glenn

--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: jk 1.2.5 and ipv6

2003-08-28 Thread Glenn Nielsen
Henri,

Can this wait until after the mod_jk 1.2.5 release?

BTW, int inet_pton(int af, const char *cp, void *addr);
is available in both Solaris 7 and 8.
And on FreeBSD 4.8 it is defined as:
int inet_pton __P((int, const char *, void *));
Regards,

Glenn

Henri Gomez wrote:
Hi to all,

Still working on finding why iSeries couldn't use Unix98 def in_addr_t.

BTW, what about adding ipv6 support in jk_connect.c by using inet_pton
instead of inet_addr ?
I'd like to have replies from people who have differents OS to know if
they have support for inet_pton...
Regards

-
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: [j-t-c] Thread problem in jk_uri_worker_map.c

2003-08-27 Thread Glenn Nielsen
Henri Gomez wrote:
Marc Saegesser a écrit :

That makes sense.  The manipulations that map_uri_to_worker() does always
make the string shorter so there is no need to worry about the modifiable
string passed in being too short and needing reallocated.
Trying to fix this in the jk/common code is, I think, a waste of effort.

-- Marc


A good reason to have delayed jk 1.2.5 ;)

Ok, I have seen Henri's commit for the in_addr build fix.
And I have seen Bill's patches for the uri mapping thread safe
bug.
If I don't hear about any more open items/bugs  for mod_jk 1.2.5 in the next
few days I will generate another test release distribution over the weekend.
Regards,

Glenn

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


Re: [PATCH] JDBCStore-howto.html Updated

2003-08-26 Thread Glenn Nielsen
Thanks for the patch Tom.

I don't see where we include this document in our release docs
anymore.  The JDBCStore is documented in /webapps/tomcat-docs/config/manager.xml .
And those docs are up to date.
Perhaps this file should be removed from CVS.

Regards,

Glenn

Tom Anderson wrote:
I noticed that the JDBCStore-howto.html no longer reflects reality so I 
updated it.   Here's my patch.

~Tom



Index: JDBCStore-howto.html
===
RCS file: /home/cvspublic/jakarta-tomcat-4.0/catalina/docs/JDBCStore-howto.html,v
retrieving revision 1.1
diff -u -r1.1 JDBCStore-howto.html
--- JDBCStore-howto.html27 Apr 2001 22:11:03 -  1.1
+++ JDBCStore-howto.html25 Aug 2003 21:46:33 -
@@ -44,6 +44,7 @@
 create table tomcat$sessions
 (
 id varchar(100) not null primary key,
+app varchar(100) not null,
 valid char(1) not null,
 maxinactive int not null,
 lastaccess bigint,
@@ -75,6 +76,7 @@
 mysql create table tomcat$sessions
 - (
 - id varchar(100) not null primary key,
+- app varchar(100) not null,
 - valid char(1) not null,
 - maxinactive int not null,
 - lastaccess bigint,
@@ -109,6 +111,7 @@
 connectionURL=jdbc:mysql://localhost/tomcat?user=testamp;amp;password=testbr
 sessionTable=tomcat$sessionsbr
 sessionIdCol=idbr
+sessionAppCol=appbr
 sessionDataCol=databr
 sessionValidCol=validbr
 sessionMaxInactiveCol=maxinactivebr
@@ -155,6 +158,11 @@
 tr
 td height=32sessionIdCol/td
 td The column in the session table that contains the session ID
+/td
+/tr
+tr
+td height=32sessionAppCol/td
+td The column in the session table that identifies the webapp (built 
from Engine, Host and Context).
 /td
 /tr
 tr


-
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: [VOTE] Release mod_jk 1.2.5

2003-08-26 Thread Glenn Nielsen
Henri Gomez wrote:
Joseph Shraibman a écrit :

Glenn Nielsen wrote:

No problems have been reported since the last test source distribution
of mod_jk 1.2.5 was made available for testing July 26.
ballot
Please vote on a release of mod_jk 1.2.5:
[ ] +1 release, and I will help build binaries for _ os/web 
server
[ ] +0 ok to release
[ ] -0 release, but I still have a problem with _
[ ] -1 don't release, there is a problem with _
/ballot

The votes will be counted Monday August 4 and the source dist
release made if the vote passes.


So whatever happened?  Why wasn't 1.2.5 released?


Glenn could you tag jk (with my latest jk_connect.c patch) for jk 1.2.5
and make the release ?
It will make jk compatible with OpenBSD/64

Yeah, I was waiting on that.  Plus there is that recent thread safe
issue which was raised with the uri mapping.
Glenn

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


[VOTE] Release mod_jk 1.2.5

2003-08-01 Thread Glenn Nielsen
No problems have been reported since the last test source distribution
of mod_jk 1.2.5 was made available for testing July 26.
ballot
Please vote on a release of mod_jk 1.2.5:
[ ] +1 release, and I will help build binaries for _ os/web server
[ ] +0 ok to release
[ ] -0 release, but I still have a problem with _
[ ] -1 don't release, there is a problem with _
/ballot
The votes will be counted Monday August 4 and the source dist
release made if the vote passes.
Regards,

Glenn

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


Re: [VOTE] Release mod_jk 1.2.5

2003-08-01 Thread Glenn Nielsen
I can confirm what Henri said, laddr had always been a ulong and
was only type in_addr_t for a short period of time.
Does mod_jk 1.2.4 build and work correctly?  It used a ulong for laddr.

What web server are you building this for?

If you are building for Apache 2 it may be a problem with the APR code.

Regards,

Glenn

Kurt Miller wrote:
From: Glenn Nielsen [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, August 01, 2003 6:39 AM
Subject: [VOTE] Release mod_jk 1.2.5


No problems have been reported since the last test source distribution
of mod_jk 1.2.5 was made available for testing July 26.


I've found one problem on the OpenBSD/sparc64 platform in jk_resolve. The
recent change of the datatype of laddr from in_addr_t to u_long has broken
this function. Could this be reverted back before release? Below is a copy
of the commit that caused the problem:
hgomez  2003/07/25 07:58:22

  Modified:jk/native/common jk_connect.c
  Log:
  Use u_long instead of in_addr_t which make unhappy some platforms like
iSeries
  Revision  ChangesPath
  1.10  +2 -3
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.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- jk_connect.c 24 Jul 2003 08:17:10 - 1.9
  +++ jk_connect.c 25 Jul 2003 14:58:22 - 1.10
  @@ -110,8 +110,7 @@
   int x;
   /* TODO: Should be updated for IPV6 support. */
  -/* for now use the correct type, in_addr_t */
  -in_addr_t laddr;
  +u_long laddr;
   rc-sin_port   = htons((short)port);
   rc-sin_family = AF_INET;
-Kurt

-
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: [VOTE] Release mod_jk 1.2.5

2003-08-01 Thread Glenn Nielsen
Kurt Miller wrote:
From: Henri Gomez [EMAIL PROTECTED]

It was u_long before I change it in in_addr_t and then change
it back to u_long.


Oh. I guess I should have done a bit more research.;-) I just started
attempting to get mod_jk going on sparc64 a few days ago. However, using a
u_long for laddr is the cause of jk_resolve failing on OpenBSD/sparc64. The
memcpy at the end copies all zeros into rc-sin_addr when u_long is used.
There are some other issues going on with mod_jk OpenBSD/sparc64, so its not
yet working even with this corrected. Given that, it may not make sense to
hold up the release for this. I will need to put in more time to investigate
the next issue.
OpenBSD-3.3/sparc64 uses Apache 1.3.27 so this is not an issue with the new
APR code. I tested releases 1.2.1 - 1.2.5 on OpenBSD/sparc64 and they all
don't work. It wasn't until recently that I had time to start investigating
it. I'll post patches here as I make progress.
Yes, please send us the patches when they are available.  The more OS/web servers,
the better. :-)
Thanks Kurt

Glenn

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


Re: [5.0] Connector default configuration + connection timeout

2003-07-29 Thread Glenn Nielsen
Bill Barker wrote:
- Original Message -
From: Remy Maucherat [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Monday, July 28, 2003 8:16 AM
Subject: [5.0] Connector default configuration + connection timeout


Hi,

What would be the best connector default configuration ?

I switched HTTP/1.1 to be:
maxThreads: 100
minSpare: 1
maxSpare: 10
That should be ok for a small/medium site, and bad for a large site. It
should be decent for benchmarking if there's a warmup period. Should the
default config be large site compliant ?


Jk-Coyote should probably match the Apache2 defaults, since with the
pre-fork MPM, connections are 1-1 with Apache2 children.

Also, in order to conserve processors for useful tasks when the load
increases (and also twart DoS attacks), I was thinking about introducing
 dynamic scaling for the HTTP connection timeout for keepalive.
The formula would be something like this.
ratio = maxThreads / currentBusyThreads;

if (ratio between 0 and 0.33) {
normal timeout
} else if (ratio between 0.33 and 0.66) {
half timeout
} else if (ratio between 0.66 and 1) {
no keepalive (so only one request is processed per connection),
timeout / 4 (or maybe more)
}


No keepalive sounds like a bad idea:  You are going to free-up connections
much faster if you get the image files out the pipe then if the browser is
immediately turning around and re-establishing a connection.  It might also
be a good idea if there was an option to disable this, for the few cases
where you care more about the the connected user's experience then the
new-connection speed (Applet classloading comes to mind).
I found the opposite to be true, turning keepalive off is a better solution
for the server.  There was a very good explanation why this is so at the
last ApacheCon in an Apache httpd performance tuning session.
Regards,

Glenn



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


  1   2   3   4   5   6   >