Return-Path: Delivered-To: apmail-felix-dev-archive@www.apache.org Received: (qmail 71714 invoked from network); 26 Feb 2009 14:59:34 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 26 Feb 2009 14:59:34 -0000 Received: (qmail 74504 invoked by uid 500); 26 Feb 2009 14:59:31 -0000 Delivered-To: apmail-felix-dev-archive@felix.apache.org Received: (qmail 74451 invoked by uid 500); 26 Feb 2009 14:59:31 -0000 Mailing-List: contact dev-help@felix.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@felix.apache.org Delivered-To: mailing list dev@felix.apache.org Received: (qmail 74439 invoked by uid 99); 26 Feb 2009 14:59:31 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 26 Feb 2009 06:59:31 -0800 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 26 Feb 2009 14:59:23 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id C8AFA234C48C for ; Thu, 26 Feb 2009 06:59:01 -0800 (PST) Message-ID: <1304815235.1235660341804.JavaMail.jira@brutus> Date: Thu, 26 Feb 2009 06:59:01 -0800 (PST) From: "Richard S. Hall (JIRA)" To: dev@felix.apache.org Subject: [jira] Commented: (FELIX-961) 100% CPU looping inside uses calculation In-Reply-To: <1246850231.1235545501832.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/FELIX-961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12677012#action_12677012 ] Richard S. Hall commented on FELIX-961: --------------------------------------- Looking at TESTCASE2, it does indeed lead to long delays, although it does appear to be making progress in all cases. Interestingly, some executions do finish quickly, which is dependent upon the ordering we get when we iterate over the entries in a hash map. In short, the algorithm is working as expected, which can be slow in some scenarios. I am looking into implementing some heuristics that may help us out, but worst case will always be bad unless we come up with a completely different algorithm. Hopefully, I can improve this case. > 100% CPU looping inside uses calculation > ---------------------------------------- > > Key: FELIX-961 > URL: https://issues.apache.org/jira/browse/FELIX-961 > Project: Felix > Issue Type: Bug > Components: Framework > Affects Versions: felix-1.4.1 > Reporter: Stuart McCulloch > Attachments: USES_TESTCASE.zip, USES_TESTCASE2.zip > > > While investigating a problem report against pax-runner (http://article.gmane.org/gmane.comp.java.ops4j.general/6778) I found it was actually caused by a 100% CPU loop inside the "uses" calculation code. In Felix 1.4.1 this was stopping the shell bundle from activating, hence the lack of console. Using the trunk build I can get a console, but the looping still occurs with the testcase. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.