Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@jackrabbit.apache.org
Received-SPF: pass (athena.apache.org: domain of christian.stocker@liip.ch
 designates 207.126.144.145 as permitted sender)
Received-SPF: pass (google.com: domain of christian.stocker@liip.ch designates
 10.180.92.71 as permitted sender) client-ip=10.180.92.71;
Message-ID: <4F428821.9030207@liip.ch>
Date: Mon, 20 Feb 2012 18:51:29 +0100
From: Christian Stocker <christian.stocker@liip.ch>
Organization: Liip AG
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
 rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: users@jackrabbit.apache.org
Subject: Re: cpu load issues with 2.3.6
References: <8E6EA65C-1050-43CD-B6D4-6DF8EF475DF9@pooteeweet.org>
 <CAOFYJNbNcRn-7Wf9Z4twrFan4=nc_ddCTM_YJNRck2sdhokAcg@mail.gmail.com>
 <B040CDB6-C013-48CD-91E1-A8808C607376@pooteeweet.org>
 <4F426546.3010303@liip.ch>
In-Reply-To: <4F426546.3010303@liip.ch>
OpenPGP: id=0748D5FE;
	url=http://gpg-keyserver.de/pks/lookup?op=get&search=0xC2BAFBC30748D5FE
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Hi

After looking at it further, it's mainly the

LOCK
PUT
REPORT
...

which is the culprit. The PUT request changes the list of referenced
nodes in one node, and the REPORT request tries to resolve one of the
referenced UUIDs to an absolute path. It's a bug in the PHP Library
Jackalope that it makes that REPORT call at al (which we will get rid of
soon), but I guess, jackalope shouldn't end up using 100% CPU, if
someone does that.

Greetings

chregu

On 20.02.12 16:22, Christian Stocker wrote:
> Hi
> 
> I discovered the same issue (on the same project as lukas, but on a
> totally different task). It has nothing to do with clustering, but with
> adding and removing references to a Weak Reference Multi-Value property
> within the same session.
> 
> In PHPCR/Jackalope, I do the following:
> ***
> // remove the weakreference property if one was there
> $m->setProperty("refs",null);
> $session->save();
> 
> //add some references
> $m->setProperty("refs",$refs,10);
> $session->save();
> 
> //remove one and set the others again
> array_pop($refs);
> $m->setProperty("refs",$refs,10);
> $session->save();
> ***
> 
> If I do the last setProperty() with a new session, then it works.
> 
> On the HTTP level it looks like this:
> 
> https://gist.github.com/1869626
> 
> The last REPORT (where we try to resolve the UUID to a path), it hangs.
> 
> (I actually don't know, why there's a REPORT there, I have to dig into
> that, but the fact that it stops is nevertheless a bad sign)
> 
> Any help is really appreciated
> 
> chregu
> 
> 
> 
> 
> On 16.02.12 15:27, Lukas Kahwe Smith wrote:
>>
>> On Feb 16, 2012, at 12:02 , Jukka Zitting wrote:
>>
>>> Hi,
>>>
>>> On Thu, Feb 16, 2012 at 11:49 AM, Lukas Kahwe Smith <mls@pooteeweet.org> wrote:
>>>> just wanted to check if anyone else is seeing issues with 2.3.6 (or later).
>>>> we are using Jackrabbit standalone in a 2 node cluster.
>>>> we are frequently seeing one node in the cluster using 100% CPU.
>>>
>>> I don't recall such issues. Getting a few thread dumps of a process in
>>> such a state should help identify what's keeping it busy.
>>
>>
>> here it is:
>> http://pastie.org/private/jyorgp7qyhchckiyfzja
>>
>> just FYI, we have a very similar configuration in production using jackrabbit 2.3.1 with our old getNodes() patch, where we do not have this issue. well we do see the CPU load increasing there as well .. but at a much much much slower pace to the point where its not a concern for us.
>>
>> so it seems to be caused by something that was done between 2.3.1 and 2.3.6
>>
>> regards,
>> Lukas Kahwe Smith
>> mls@pooteeweet.org
>>
>>
>