Creating a pool returns a previously created instance

2011-05-17 Thread Alexander Broekhuis
Hi, I have a problem with APR which is related to creating pools. In my software (Apache Celix), a library can be loaded/unloaded at runtime. Before the library is loaded, I create a memory pool to use by the loaded library. After unloading a library, the pool gets destroyed. In a test scenario

Re: Creating a pool returns a previously created instance

2011-05-17 Thread Alexander Broekhuis
Hello, In reply to my own mail, I have found the problem. There was a duplicate apr_pool_destroy which resulted in this unexpected behavior. All works as expected now :). On 17 May 2011 18:36, Alexander Broekhuis a.broekh...@gmail.com wrote: Hi, I have a problem with APR which is related to

apr 1.4.4 breaks mod_jk

2011-05-17 Thread Mike Jakubik
Hello, I have recently discovered while updating my apache22 installation and subsequently apr1 from 1.4.2 to 1.4.4 that mod_jk now causes the apache server to consume 100% cpu and become unresponsive. I have tried recompiling mod_jk with the new apr but that did not help. Below is my environment

Re: apr 1.4.4 breaks mod_jk

2011-05-17 Thread Jeff Trawick
On Tue, May 17, 2011 at 5:33 PM, Mike Jakubik mike.jaku...@intertainservices.com wrote: Hello, I have recently discovered while updating my apache22 installation and subsequently apr1 from 1.4.2 to 1.4.4 that mod_jk now causes the apache server to consume 100% cpu and become unresponsive. I

Re: apr 1.4.4 breaks mod_jk

2011-05-17 Thread Mike Jakubik
On Tue, 2011-05-17 at 17:52 -0400, Jeff Trawick wrote: you updated Apache 2.2.x from 2.2.what to 2.2.what? 2.2.17 to 2.2.18. I can however also reproduce the problem in 2.2.17, it seems to be specific to the apr version. (you updated apr 1.4.2 to 1.4.4) PID USERNAMETHR PRI

Re: apr 1.4.4 breaks mod_jk

2011-05-17 Thread Rainer Jung
On 17.05.2011 23:33, Mike Jakubik wrote: Hello, I have recently discovered while updating my apache22 installation and subsequently apr1 from 1.4.2 to 1.4.4 that mod_jk now causes the apache server to consume 100% cpu and become unresponsive. I have tried recompiling mod_jk with the new apr

RE: apr 1.4.4 breaks mod_jk

2011-05-17 Thread Anthony J. Biacco
Just fyi, I have had no problems yet on apache 2.2.18 worker and apr 1.4.4 (centos 5.6 x86_64 and jk 1.2.31) -Tony --- Manager, IT Operations Format Dynamics, Inc. P: 303-228-7327 F: 303-228-7305 abia...@formatdynamics.com http://www.formatdynamics.com -Original

Re: apr 1.4.4 breaks mod_jk

2011-05-17 Thread Mike Jakubik
On Wed, 2011-05-18 at 00:07 +0200, Rainer Jung wrote: Thanks for the report. Would you mind opening an issues in Bugzilla? You can choose the Tomcat project and Tomcat Connectors as a component. If it turns out as an APR bug, we can move the issue there later. It would be very helpful, if

Re: apr 1.4.4 breaks mod_jk

2011-05-17 Thread Rainer Jung
On 18.05.2011 00:30, Mike Jakubik wrote: On Wed, 2011-05-18 at 00:07 +0200, Rainer Jung wrote: Thanks for the report. Would you mind opening an issues in Bugzilla? You can choose the Tomcat project and Tomcat Connectors as a component. If it turns out as an APR bug, we can move the issue

Re: apr 1.4.4 breaks mod_jk

2011-05-17 Thread Mike Jakubik
On Wed, 2011-05-18 at 00:53 +0200, Rainer Jung wrote: If you can find pstack, that will be easier. pstack just takes the process id and writes out the stacks for all threads. My quick search indicates it pstack should exist for FreeBSD. There is a port for this but it only support i386

Re: [patch] apr-1.4.4/Makefile.in ( top_builddir variable )

2011-05-17 Thread Rainer Jung
If noone beats me to it, I will care about this one (and checking for possible similar cases) over the weekend. Regards, Rainer On 16.05.2011 19:19, olli hauer wrote: Hi, I just run into an issue with the new apr_rules.mk The new top_builddir variable is not replaced like

Re: [patch] apr-1.4.4/Makefile.in ( top_builddir variable )

2011-05-17 Thread Bojan Smojver
On Wed, 2011-05-18 at 07:23 +0200, Rainer Jung wrote: If noone beats me to it, I will care about this one (and checking for possible similar cases) over the weekend. This has been fixed. http://svn.apache.org/viewvc?view=revisionrevision=1101301 -- Bojan