Cleanup when server is stopped vs reconfigured
I have a DSO module which establishes a custom handler. The handle fires up external process which perform the work for certain requests. Those processes contain a lot of state information for user application sessions. We want to have some cleanup code that will shutdown those processes cleanly if the Apache server is stopped. I thought I had solved this problem by registering my cleanup handler on the pool which is passed to my register_hooks function. This does get called when the server is stopped. The problem is, it also gets called when the server is reconfigured (i.e. with apachectl graceful). Our system administrators want to use graceful to update minor configuration directives or rotate log files from time to time and feel strongly that they should be able to do so without disrupting our user sessions. So after a few hours of reviewing the source code, I am throwing in the towel. I am going to ask the geniuses: Is there a way to run some cleanup code in a module when the server is being stopped, but not being restarted? Or, can a cleanup handler in a loaded module determine whether the server is being shut down or restarted? Thanks very much
RE: Close HTTP connection callback/hook
From: Evgeny Shvidky [mailto:evg...@skyfence.com]
Sent: Wednesday, 17 October 2012 12:50 AM
To: modules-dev@httpd.apache.org
Subject: Close HTTP connection callback/hook
Hi,
I am implementing a new module on C.
I need to perform some functionality when a user closes a HTTP
connection before he received any response for his request.
How can I know when a HTTP user request state has been changed/closed?
Is there any callback/hook for this functionality I can register?
Thanks,
Evgeny
Hi, I am usually the one asking questions, but I think I have had and solved a
similar problem to yours.
I have a module with a handler that sometimes does a lot of processing before
sending a response. It needs to check periodically whether the browser
connection is still there so that it can stop the processing (and cleanup a
bunch of resources) if the user gives up.
The problem I found is that tcp/ip sockets are not particularly proactive in
telling you that the other end has closed the connection. I found that the only
reliable way to test a socket is to attempt to read from it. (Yes, I have found
that send() can appear to succeed even though the remote end has already closed
the socket.) So in fact, once apache has read the request successfully, it will
not even know if the connection has been closed because it will not be trying
to read the socket anymore (or in fact do anything with the socket until the
handler begins to send a response).
What I found useful is doing a recv() with the MSG_PEEK flag on the socket.
That seems to always detect the closed socket and return an error. It is good
because it does not do anything to change the state of the socket if it is
still open.
The next problem is finding the actual socket to test. By the time my handler
is running, the socket is buried in apache's data structures where it is
difficult to find reliably. The solution (suggested by the gurus on this list)
was to use the pre_connection hook to get the socket of each new connection and
store in a place that the handler can find it. So basically:
ap_hook_pre_connection(PreConnection, NULL, NULL, APR_HOOK_MIDDLE);
...
static int PreConnection(conn_rec *c, void *csd)
{
apr_os_sock_t *p_os_fd = apr_palloc( c-pool, sizeof(apr_os_sock_t) );
/* Retrieve the new connection's socket number */
apr_os_sock_get(p_os_fd, (apr_socket_t *)csd);
/* Store it for CheckConnected */
ap_set_module_config( c-conn_config, my_module, p_os_fd );
return OK;
}
/* This is called by the handler periodically to see of the browser is still
waiting */
Static int CheckConnected( request_rec *r )
{
int *pnSocket;
char acBuffer[1];
int nResult;
/* connected socket was conveniently stored away in out conn_configuration
in pre_connection */
pnSocket = ap_get_module_config( r-connection-conn_config, my_module );
nResult = recv( *pnSocket, acBuffer, 1, MSG_PEEK );
return nResult 0 || (nResult == -1 errno == EAGAIN);
}
So, if the socket is still connected, recv() will return either some number of
bytes that can be read, or an EAGAIN error indicating that no data is
available. Any other error implies that there was a problem reading the socket,
which I construe as meaning that the socket is closed. This now seems to be
working reliably on several Unix and Linux platforms, with Apache 2.0.x and
2.2.x servers.
I hope that you find this helpful.
RE: mod_proxy_fdpass + httpd-2.2.19
From: Henrik Strand [mailto:henrik.str...@axis.com] Sent: Wednesday, 3 August 2011 5:10 PM To: modules-dev@httpd.apache.org Subject: mod_proxy_fdpass + httpd-2.2.19 Hi, I'm trying to back-port Apache Module mod_proxy_fdpass to httpd-2.2.19, and building from source, but are getting the following error message when starting apachectl: httpd: Module (null) is not compatible with this version of Apache (found 0, need 20051115). Please contact the vendor for the correct version. I've been googling an answer but only found that I should contact the module vendor, which in this case would be me?! =) How can I fix this? Thanks in advance. Best Regards, Henrik Does the module data that you pass to ap_get_module_config() have the constants MODULE_MAGIC_NUMBER_MAJOR and MODULE_MAGIC_NUMBER_MINOR in the first two elements? I think that is where the 20051115 should be coming from. The module name should be in that structure too. Maybe you are using compiler switches that are making int be 32 bit instead of 64 bit--thus confusing the data in the structure?
RE: How to test if request has been aborted
On Fri, Jul 29, 2011 at 02:35, Tony Abo t...@hitech.com wrote:
I need to cut the processing short if the user decides to press
the
stop button on the browser. I cant seem to figure out how to test
for
that condition from inside the handler. Can anyone help me?
Thanks in advance,
Tony
r-connection-aborted
Cheers
Tom
Thanks Tom
Will that value get updated asynchronously if the connection closes
while my handler does its processing (I.e without calling any Apache
functions)?
My testing shows that connection-aborted is not being set
asynchronously when the connection is closed by the client. I need one
of the following:
- Some Apache function I can call that will attempt to touch the open
socket and either set connection-aborted or return an error status so I
can know it is no longer connected.
Or
- Access to the actual socket buried somewhere in the connection
structure. I can't seem to find it. If I had that, I could test it
myself.
The earliest hook that is passed the socket is create_connection. The
socket is passed in the third argument. Use apr_os_sock_get to get the
OS-specific socket descriptor.
If you do not place your own callback on the create_connection hook in
order to save the socket in your own structures, then you can use the
method below, but it's a hack, as I guess the core_module structure is
not supposed to be visible to modules. The method works after the
pre_connection hook.
#define CORE_PRIVATE 1
#include http_core.h
apr_socket_t *sock = (apr_socket_t
*)ap_get_module_config(r-connection-conn_config, core_module);
apr_os_sock_t fd; // int for Unix
apr_os_sock_get(fd, sock);
#undef CORE_PRIVATE
Thanks Sorin, that works. I found another approach, but I'm not sure how safe
it is.
int CheckConnected(request_rec r)
{
int nSocket;
char acBuffer[1];
int nResult;
core_net_rec *cnr = pConnID-pRequestRecord-connection-output_filters-ctx;
if ( apr_os_sock_get( nSocket, cnr-client_socket ) != APR_SUCCESS )
return FALSE;
nResult = recv( nSocket, acBuffer, 1, MSG_PEEK | MSG_DONTWAIT );
return nResult 0 || (nResult == -1 errno == EWOULDBLOCK);
}
Any thoughts?
Thanks again,
Tony
How to test if request has been aborted
I am working on a custom request handler that works with Apache 2.x. There are times that the request may take a considerable amount of time to process. I need to cut the processing short if the user decides to press the stop button on the browser. I cant seem to figure out how to test for that condition from inside the handler. Can anyone help me? Thanks in advance, Tony
Re: How to test if request has been aborted
Sent from my iPhone On 28/07/2011, at 7:18 PM, Tom Evans tevans...@googlemail.com wrote: On Thu, Jul 28, 2011 at 7:26 AM, ... I need to cut the processing short if the user decides to press the stop button on the browser. I cant seem to figure out how to test for that condition from inside the handler. Can anyone help me? Thanks in advance, Tony r-connection-aborted Cheers Tom Thanks Tom Will that value get updated asynchronously if the connection closes while my handler does its processing (I.e without calling any Apache functions)?
RE: How to test if request has been aborted
I need to cut the processing short if the user decides to press the stop button on the browser. I cant seem to figure out how to test for that condition from inside the handler. Can anyone help me? Thanks in advance, Tony r-connection-aborted Cheers Tom Thanks Tom Will that value get updated asynchronously if the connection closes while my handler does its processing (I.e without calling any Apache functions)? My testing shows that connection-aborted is not being set asynchronously when the connection is closed by the client. I need one of the following: - Some Apache function I can call that will attempt to touch the open socket and either set connection-aborted or return an error status so I can know it is no longer connected. Or - Access to the actual socket buried somewhere in the connection structure. I can't seem to find it. If I had that, I could test it myself. Thanks again, Tony
