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

["Scott, Sean" <Se...@mdx.com>]

> > 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: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org

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

[Mladen Turk <mt...@apache.org>]

 

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

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


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org