Re: Issuing a client side HTTP request from a module
On 22 Apr 2010, at 15:14, Some Guy wrote: > I don't really need keepalive. Just a really basic http request. However, > this would be in a non request handler thread, so I'll have no initial > request_rec to create a subrequest from. It would also be in the parent > process via a monitor hook. In that case, you're probably the exception to the general advice to use mod_proxy. Simplest would probably be DIY with your choice of HTTP client library. -- Nick Kew
Re: Issuing a client side HTTP request from a module
check the thread "Doing a subrequest with ap_run_sub_req" in the same list From: Some Guy To: modules-dev@httpd.apache.org Sent: Thu, April 22, 2010 5:14:07 PM Subject: Re: Issuing a client side HTTP request from a module I don't really need keepalive. Just a really basic http request. However, this would be in a non request handler thread, so I'll have no initial request_rec to create a subrequest from. It would also be in the parent process via a monitor hook. I see the mod_proxy create_worker and initialize_worker, but the latter call requires a server_rec, which I won't have. SB On Thu, Apr 22, 2010 at 3:48 AM, Nick Kew wrote: > > On 22 Apr 2010, at 08:25, Sorin Manolache wrote: > > > As Nick says, the common solution are subrequests. However, note that > > subrequests are not kept alive. > > Backend connections may be kept alive or closed, as detailed in > the mod_proxy docs! > > If you want to implement keepalive without mod_proxy, that's a lot > of wheel to reinvent. > > -- > Nick Kew >
Re: Issuing a client side HTTP request from a module
I don't really need keepalive. Just a really basic http request. However, this would be in a non request handler thread, so I'll have no initial request_rec to create a subrequest from. It would also be in the parent process via a monitor hook. I see the mod_proxy create_worker and initialize_worker, but the latter call requires a server_rec, which I won't have. SB On Thu, Apr 22, 2010 at 3:48 AM, Nick Kew wrote: > > On 22 Apr 2010, at 08:25, Sorin Manolache wrote: > > > As Nick says, the common solution are subrequests. However, note that > > subrequests are not kept alive. > > Backend connections may be kept alive or closed, as detailed in > the mod_proxy docs! > > If you want to implement keepalive without mod_proxy, that's a lot > of wheel to reinvent. > > -- > Nick Kew >
Re: *** glibc detected *** double free or corruption (!prev) in cleanup function
On 4/22/2010 1:46 PM, Andrej van der Zee wrote: Hi Bronto, http://lmgtfy.com/?q=apache+httpd+valgrind Thank you for the tip :) You are funny! Cheers, Andrej Hi, yeah, i didn't mean no offense. I just thought that it's rather a FAQ ;)
Re: *** glibc detected *** double free or corruption (!prev) in cleanup function
Hi Bronto, > > http://lmgtfy.com/?q=apache+httpd+valgrind > Thank you for the tip :) You are funny! Cheers, Andrej
Re: *** glibc detected *** double free or corruption (!prev) in cleanup function
On 4/22/2010 1:09 PM, Andrej van der Zee wrote: Hi, This and try running httpd through valgrind. How can I do that? Thanks, Andrej http://lmgtfy.com/?q=apache+httpd+valgrind
Re: *** glibc detected *** double free or corruption (!prev) in cleanup function
Hi, > > This and try running httpd through valgrind. > How can I do that? Thanks, Andrej
Re: *** glibc detected *** double free or corruption (!prev) in cleanup function
Hi, > Do you create a background thread per apache process? Or do you have a > single background thread that is used by all apache processes? Which > hook creates the background thread? The background thread is created by ap_hook_child_init, thus every child process has one running background thread. > > It is possible that you create the thread once but you try to join it > several times. I don't know if this is sufficient to get the symptoms > that you see. Even when I do not join at all, but just attempt to connect to the database in the registered pool cleanup function for the child, I get the segfault. > > Try compiling both apache and apr with debug symbols and run it in a > debugger with -X (i.e. monoprocess). > Place a breakpoint on line 134 > and see how many times you reach it. Yes I'll try that soon. Thank you, Andrej
Re: *** glibc detected *** double free or corruption (!prev) in cleanup function
> Try compiling both apache and apr with debug symbols and run it in a > debugger with -X (i.e. monoprocess). Place a breakpoint on line 134 > and see how many times you reach it. This and try running httpd through valgrind.
Re: Issuing a client side HTTP request from a module
On 22 Apr 2010, at 08:25, Sorin Manolache wrote: > As Nick says, the common solution are subrequests. However, note that > subrequests are not kept alive. Backend connections may be kept alive or closed, as detailed in the mod_proxy docs! If you want to implement keepalive without mod_proxy, that's a lot of wheel to reinvent. -- Nick Kew
Re: Issuing a client side HTTP request from a module
On Wed, Apr 21, 2010 at 22:51, Nick Kew wrote: > > On 21 Apr 2010, at 20:42, Some Guy wrote: > >> Hi all, >> >> Is there any facility in the Apache libs that allows module developers to >> act as a client? > > The usual way would be to harness mod_proxy, commonly in a subrequest. > You don't have to do anything special, just request something configured > to proxy. As Nick says, the common solution are subrequests. However, note that subrequests are not kept alive. S
Re: *** glibc detected *** double free or corruption (!prev) in cleanup function
On Thu, Apr 22, 2010 at 05:47, Andrej van der Zee
wrote:
> Hi,
>
> I have a question about apr_pool_cleanup_register for a child's pool.
> I register a cleanup function that is called when the pool is
> destroyed. In the cleanup function, I join a background thread that
> first writes some log to a database:
>
> static void mbrace_child_init(apr_pool_t *pool, server_rec *s)
> {
> apr_pool_cleanup_register(pool, 0, &mbrace_bgthread_cleanup,
> apr_pool_cleanup_null);
> }
>
> static apr_status_t mbrace_bgthread_cleanup(void*)
> {
> req_log_mngr->stop()
> }
>
> But, when it connects to the database in the background thread, it
> sometimes ends up in the error below. I do not fully understand why,
> but are there any restrictions to what I can do in the cleanup
> function?
>
> When running gdb on the generated core-dump, you can see that it
> happens on line 134.
>
> 125 APR_DECLARE(void) apr_allocator_destroy(apr_allocator_t *allocator)
> 126 {
> 127 apr_uint32_t index;
> 128 apr_memnode_t *node, **ref;
> 129
> 130 for (index = 0; index < MAX_INDEX; index++) {
> 131 ref = &allocator->free[index];
> 132 while ((node = *ref) != NULL) {
> 133 *ref = node->next;
> 134 free(node); < here it happens!!
> 135 }
> 136 }
> 137
> 138 free(allocator);
> 139 }
>
> Hopefully somebody can push me in the right direction.
Do you create a background thread per apache process? Or do you have a
single background thread that is used by all apache processes? Which
hook creates the background thread?
It is possible that you create the thread once but you try to join it
several times. I don't know if this is sufficient to get the symptoms
that you see.
Try compiling both apache and apr with debug symbols and run it in a
debugger with -X (i.e. monoprocess). Place a breakpoint on line 134
and see how many times you reach it.
S
Re: Issuing a client side HTTP request from a module
Some Guy wrote: Hi all, Is there any facility in the Apache libs that allows module developers to act as a client? If not, I'll just use something like curl (or raw sockets), but wanted to know if there was an Apache way to do this. You'll have to co-opt a http client library or roll your own. -srp
