Return-Path: X-Original-To: apmail-jackrabbit-users-archive@minotaur.apache.org Delivered-To: apmail-jackrabbit-users-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 119DE9DE7 for ; Mon, 20 Feb 2012 15:23:21 +0000 (UTC) Received: (qmail 63325 invoked by uid 500); 20 Feb 2012 15:23:20 -0000 Delivered-To: apmail-jackrabbit-users-archive@jackrabbit.apache.org Received: (qmail 63241 invoked by uid 500); 20 Feb 2012 15:23:19 -0000 Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@jackrabbit.apache.org Delivered-To: mailing list users@jackrabbit.apache.org Received: (qmail 63231 invoked by uid 99); 20 Feb 2012 15:23:19 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 20 Feb 2012 15:23:19 +0000 X-ASF-Spam-Status: No, hits=-2.3 required=5.0 tests=RCVD_IN_DNSWL_MED,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of christian.stocker@liip.ch designates 207.126.144.137 as permitted sender) Received: from [207.126.144.137] (HELO eu1sys200aog114.obsmtp.com) (207.126.144.137) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 20 Feb 2012 15:23:11 +0000 Received: from mail-wi0-f180.google.com ([209.85.212.180]) (using TLSv1) by eu1sys200aob114.postini.com ([207.126.147.11]) with SMTP ID DSNKT0JlSpoCmf2yneQSpB5L41qO0da1FBMi@postini.com; Mon, 20 Feb 2012 15:22:51 UTC Received: by mail-wi0-f180.google.com with SMTP id hm6so3648469wib.11 for ; Mon, 20 Feb 2012 07:22:50 -0800 (PST) Received-SPF: pass (google.com: domain of christian.stocker@liip.ch designates 10.216.134.134 as permitted sender) client-ip=10.216.134.134; Authentication-Results: mr.google.com; spf=pass (google.com: domain of christian.stocker@liip.ch designates 10.216.134.134 as permitted sender) smtp.mail=christian.stocker@liip.ch Received: from mr.google.com ([10.216.134.134]) by 10.216.134.134 with SMTP id s6mr4560792wei.27.1329751370480 (num_hops = 1); Mon, 20 Feb 2012 07:22:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:x-enigmail-version:openpgp :content-type:content-transfer-encoding:x-gm-message-state; bh=vylGRt9yNcZA8LcaJPbKFHJQCKROAsyYeifRPKic4gk=; b=A0UbZ7UdvhUfSNlmIz0MFXexhOGOjJpa2Hzi4BFoTRWW6gVwYbaukbmXks/SXYDDn8 E9OcSLVTVRr0dPNZqslA5Z+LMbQb8MRMFmSsA82fqwfixQaRFK9h95eS0S5Nkuww5yKR 5VPJIWH0pChIoC5PR+cch/j6Qa8LOCkjac7ww= Received: by 10.216.134.134 with SMTP id s6mr3765191wei.27.1329751370348; Mon, 20 Feb 2012 07:22:50 -0800 (PST) Received: from pri7.local (77-58-253-248.dclient.hispeed.ch. [77.58.253.248]) by mx.google.com with ESMTPS id gd8sm16396937wib.2.2012.02.20.07.22.47 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 20 Feb 2012 07:22:48 -0800 (PST) Message-ID: <4F426546.3010303@liip.ch> Date: Mon, 20 Feb 2012 16:22:46 +0100 From: Christian Stocker 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 CC: Lukas Kahwe Smith Subject: Re: cpu load issues with 2.3.6 References: <8E6EA65C-1050-43CD-B6D4-6DF8EF475DF9@pooteeweet.org> In-Reply-To: X-Enigmail-Version: 1.3.5 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 X-Gm-Message-State: ALoCoQmxL+XIQc4m2bi/5KYCRyP4VRm0vCynpYJbH7Z2d+bv2eCztldx4G+UK84iGDA+SOodlI3n X-Virus-Checked: Checked by ClamAV on apache.org 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 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 > > -- Liip AG // Feldstrasse 133 // CH-8004 Zurich Tel +41 43 500 39 81 // Mobile +41 76 561 88 60 www.liip.ch // blog.liip.ch // GnuPG 0x0748D5FE