RE: [JK2 Enhancement] modify behavior when max_endpoints have bee n reached

2003-12-03 Thread Scott, Sean

> > -Original Message-
> > From: Scott, Sean
> > > -1 on mutex/wait approach.
> > > 
> > > Using that we would reinvent the wheel.
> > > 
> > > There is an excellent API in the APR-UTILS that will allow 
> > us to do a 
> > > non-blocking approach.
> > > Take a look at apr_reslist API.
> > > Since we agreed to use the apr _and_ apr_util as mandatory, take a
> > 
> > Being fairly new to this list... does this mean that you plan 
> > on doing away with the jk wrappers? Is apr fair game in any module?
> > 
> 
> Seems that I miss you here...

Meaning that the endpoint cache would no longer be a jk_objCache but be an
apr reslist instead.


> 
> > > look at those. The reslist is meant to be used for such purposes.
> > > 
> > > MT.
> > 
> > These methods do in fact do the functionality that I require, 
> > however it doesnt appear that it is possible to achieve the 
> > current behavior which is to error out when the 
> > max_connections have been reached. However, I dont think 
> > returning an error is desirable behavior anyway.
> > 
> 
> That true.
> Unfortunately the reslist doesn't have the acquire timeout.
> That is the reason that I didn't try to implement that by myself.
> There is apr_queue api that has the trypop call returning APR_EAGAIN
> if there is no free entries.
> The only drawback is that this is static list giving the 
> fixed number of
> connections.
> What we want is the initial number of connections with the peek limit,
> and that is what apr_reslist provides.
> 
> 
> If we persuade the apr guys to add the timeout option to apr_reslist,
> it would satisfy all our needs.
> 
> I have a pending apr patch that resolves that issue, so 
> hopefully this will
> get committed.
> 
> If that doesn't pass (knowing how fast the guys are :-), we can simply
> duplicate the
> apr_reslist code using apr_thread_cond_timedwait with 
> configurable timeout,
> where
> the value of zero would immediately return the server_busy.
> 
> 
> MT.
> 

Personally I dont see a problem with waiting for the next endpoint to be
returned. 

CONFIDENTIALITY NOTICE - This e-mail transmission, and any documents, files or 
previous e-mail messages attached to it may contain information that is confidential 
or legally privileged. If you are not the intended recipient, or a person responsible 
for delivering it to the intended recipient, you are hereby notified that you must not 
read this transmission and that any disclosure, copying, printing, distribution or use 
of any of the information contained in or attached to this transmission is STRICTLY 
PROHIBITED. If you have received this transmission in error, please immediately notify 
the sender by telephone or return e-mail and delete the original transmission and its 
attachments without reading or saving in any manner. Thank you

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



RE: [JK2 Enhancement] modify behavior when max_endpoints have bee n reached

2003-12-03 Thread Scott, Sean
> > From: Scott, Sean
> > 
> > I have locally modified the head revision of the jk2 project 
> > and would like some feedback before submitting the 
> > enhancements for review.
> > 
> > The change in behavior that we desired was that rather than 
> > returning an error when the max_connections for the endpoint 
> > cache were reached, the worker would wait for an endpoint to 
> > be returned to the cache.  
> > 
> > To implement this functionality I modified the 
> > jk_mutex_thread.c module to include a wait and a notify 
> > method (using the apr_thread_cond routines).  I then modified 
> > the ajp13 worker to wait (forever) when the max_endpoints are 
> > reached. I also modified the "jk2_worker_ajp13_done" method 
> > to "notify" when an endpoint was returned to the cache.
> > 
> 
> -1 on mutex/wait approach.
> 
> Using that we would reinvent the wheel.
> 
> There is an excellent API in the APR-UTILS that will allow us to do
> a non-blocking approach.
> Take a look at apr_reslist API.
> Since we agreed to use the apr _and_ apr_util as mandatory, take a

Being fairly new to this list... does this mean that you plan on doing away
with the jk wrappers? Is apr fair game in any module?

> look at those. The reslist is meant to be used for such purposes.
> 
> MT.

These methods do in fact do the functionality that I require, however it
doesnt appear that it is possible to achieve the current behavior which is
to error out when the max_connections have been reached. However, I dont
think returning an error is desirable behavior anyway.

 

CONFIDENTIALITY NOTICE - This e-mail transmission, and any documents, files or 
previous e-mail messages attached to it may contain information that is confidential 
or legally privileged. If you are not the intended recipient, or a person responsible 
for delivering it to the intended recipient, you are hereby notified that you must not 
read this transmission and that any disclosure, copying, printing, distribution or use 
of any of the information contained in or attached to this transmission is STRICTLY 
PROHIBITED. If you have received this transmission in error, please immediately notify 
the sender by telephone or return e-mail and delete the original transmission and its 
attachments without reading or saving in any manner. Thank you

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



[JK2 Enhancement] modify behavior when max_endpoints have been re ached

2003-12-03 Thread Scott, Sean
I have locally modified the head revision of the jk2 project and would like
some feedback before submitting the enhancements for review.

The change in behavior that we desired was that rather than returning an
error when the max_connections for the endpoint cache were reached, the
worker would wait for an endpoint to be returned to the cache.  

Consider the scenario where apache is configured to have lots ( lets say 900
) of worker threads, but we want to limit the connections to tomcat to just
a few ( lets say 15 ). Without the enhancement I am proposing, we had to
configure the AJP connector in tomcat as follows. 
connection timeout = 1 ( problematic as testing using a slow connection
would drop connections ), 
accept count 1000 ( needed so that we could queue up requests from apache )
max threads = 30 ( We determined that jdk/tomcat we spend more time waiting
than working with more threads than this )
And configure jk2 not to limit the connections to tomcat.

This configuration allowed us to handle the desired load. We test with 1000
virtual users, which maps to about 2000 real users for our tests. We could
handle the load but the log files filled with error messages, apparently to
JK2 its an error when tomcat closes the connection on its end. The test also
had a couple hundred errors after about 1 page views.

To implement this functionality I modified the jk_mutex_thread.c module to
include a wait and a notify method (using the apr_thread_cond routines).  I
then modified the ajp13 worker to wait (forever) when the max_endpoints are
reached. I also modified the "jk2_worker_ajp13_done" method to "notify" when
an endpoint was returned to the cache.

After load testing the resulting code, after close to 11000 page views we
had 0 errors and response times remained at about .2 seconds (no slower than
jk2 without my mods).

I didnt add a wait timeout because I didnt feel in our case that an error
should be returned to the client. But perhaps the option to specify a
timeout could be useful to someone else.

Comments?

-sean


CONFIDENTIALITY NOTICE - This e-mail transmission, and any documents, files or 
previous e-mail messages attached to it may contain information that is confidential 
or legally privileged. If you are not the intended recipient, or a person responsible 
for delivering it to the intended recipient, you are hereby notified that you must not 
read this transmission and that any disclosure, copying, printing, distribution or use 
of any of the information contained in or attached to this transmission is STRICTLY 
PROHIBITED. If you have received this transmission in error, please immediately notify 
the sender by telephone or return e-mail and delete the original transmission and its 
attachments without reading or saving in any manner. Thank you

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



RE: I would like to contribute to the jakarta-tomcat-connectors p roject

2003-12-03 Thread Scott, Sean
What if what I am proposing is an enhancement, not just a patch?

-Original Message-
From: Shapira, Yoav [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 03, 2003 9:32 AM
To: Tomcat Developers List
Subject: RE: I would like to contribute to the jakarta-tomcat-connectors
project


Howdy,
You start by discussing and sending patches to the list.  Commit status
possibly comes later. http://jakarta.apache.org/site/getinvolved.html

Yoav Shapira
Millennium ChemInformatics


>-Original Message-
>From: Scott, Sean [mailto:[EMAIL PROTECTED]
>Sent: Wednesday, December 03, 2003 11:26 AM
>To: '[EMAIL PROTECTED]'
>Subject: I would like to contribute to the jakarta-tomcat-connectors
>project
>
>How do I go about getting commit status to that project?
>
>Thanks
>
>-sean
>
>
>
>CONFIDENTIALITY NOTICE - This e-mail transmission, and any documents,
files
>or previous e-mail messages attached to it may contain information that
is
>confidential or legally privileged. If you are not the intended
recipient,
>or a person responsible for delivering it to the intended recipient,
you
>are hereby notified that you must not read this transmission and that
any
>disclosure, copying, printing, distribution or use of any of the
>information contained in or attached to this transmission is STRICTLY
>PROHIBITED. If you have received this transmission in error, please
>immediately notify the sender by telephone or return e-mail and delete
the
>original transmission and its attachments without reading or saving in
any
>manner. Thank you
>
>-
>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]

CONFIDENTIALITY NOTICE - This e-mail transmission, and any documents, files or 
previous e-mail messages attached to it may contain information that is confidential 
or legally privileged. If you are not the intended recipient, or a person responsible 
for delivering it to the intended recipient, you are hereby notified that you must not 
read this transmission and that any disclosure, copying, printing, distribution or use 
of any of the information contained in or attached to this transmission is STRICTLY 
PROHIBITED. If you have received this transmission in error, please immediately notify 
the sender by telephone or return e-mail and delete the original transmission and its 
attachments without reading or saving in any manner. Thank you

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



I would like to contribute to the jakarta-tomcat-connectors proje ct

2003-12-03 Thread Scott, Sean
How do I go about getting commit status to that project?

Thanks

-sean



CONFIDENTIALITY NOTICE - This e-mail transmission, and any documents, files or 
previous e-mail messages attached to it may contain information that is confidential 
or legally privileged. If you are not the intended recipient, or a person responsible 
for delivering it to the intended recipient, you are hereby notified that you must not 
read this transmission and that any disclosure, copying, printing, distribution or use 
of any of the information contained in or attached to this transmission is STRICTLY 
PROHIBITED. If you have received this transmission in error, please immediately notify 
the sender by telephone or return e-mail and delete the original transmission and its 
attachments without reading or saving in any manner. Thank you

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



JK2 Endpoint cache comment/question

2003-11-26 Thread Scott, Sean
I am curious as to why the endpoint cache for the ajp 1.3 worker is not in
shared memory. It seems that if you want to limit the number of connections
to tomcat you would want to it across all of apache, not per process. Is
there a reason why it is implemented this way?

Example:

httpd.conf

StartServers 1
MaxClients 640
MinSpareThreads  5
MaxSpareThreads640
ThreadsPerChild 64
MaxRequestsPerChild  0

To satisfy this configuration, apache would create 10 processes under heavy
load.  

How would I configure a worker in workers2.properties If I wanted to limit
the number of threads that this server can use in a particular tomcat
instance to 15. ( We have 2 webservers, and we have found through testing
that tomcat/java has thrashing issues above 30 threads )

Thanks

CONFIDENTIALITY NOTICE - This e-mail transmission, and any documents, files or 
previous e-mail messages attached to it may contain information that is confidential 
or legally privileged. If you are not the intended recipient, or a person responsible 
for delivering it to the intended recipient, you are hereby notified that you must not 
read this transmission and that any disclosure, copying, printing, distribution or use 
of any of the information contained in or attached to this transmission is STRICTLY 
PROHIBITED. If you have received this transmission in error, please immediately notify 
the sender by telephone or return e-mail and delete the original transmission and its 
attachments without reading or saving in any manner. Thank you

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