Return-Path: Delivered-To: apmail-jackrabbit-dev-archive@www.apache.org Received: (qmail 92716 invoked from network); 19 Mar 2007 08:59:29 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 19 Mar 2007 08:59:29 -0000 Received: (qmail 11463 invoked by uid 500); 19 Mar 2007 08:59:34 -0000 Delivered-To: apmail-jackrabbit-dev-archive@jackrabbit.apache.org Received: (qmail 11436 invoked by uid 500); 19 Mar 2007 08:59:34 -0000 Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@jackrabbit.apache.org Delivered-To: mailing list dev@jackrabbit.apache.org Received: (qmail 11415 invoked by uid 99); 19 Mar 2007 08:59:34 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 19 Mar 2007 01:59:34 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of marcel.reutegger@gmx.net designates 213.165.64.20 as permitted sender) Received: from [213.165.64.20] (HELO mail.gmx.net) (213.165.64.20) by apache.org (qpsmtpd/0.29) with SMTP; Mon, 19 Mar 2007 01:59:25 -0700 Received: (qmail invoked by alias); 19 Mar 2007 08:59:03 -0000 X-Provags-ID: V01U2FsdGVkX18saE9z4jMs4EaScI4JqZIYHBM6oOZ2+ntNMcKJP8 bBFMN7PmrHPb8/ Message-ID: <45FE50D6.1060007@gmx.net> Date: Mon, 19 Mar 2007 09:59:02 +0100 From: Marcel Reutegger User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: dev@jackrabbit.apache.org Subject: Re: ConcurrenModificationException References: <34B0CDC6176518459F3A96E8C09196B80585B791@darth-vader.nijmegen.gx.nl> <45FAB5D9.6030906@gmx.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Virus-Checked: Checked by ClamAV on apache.org Hi Martijn, Martijn Hendriks wrote: > The second scenario that I sketched in my previous message is > possible: I now can reproduce that values of an ItemStateReferenceMap > are evicted by garbage collection during the iteration over that map > in the LocalItemStateManager.dispose method (with Jackrabbit 1.2.1). > On my local system, however, I did not get the ConcurrentModification > exception (Java 5 doc says that it is thrown on a best-effort basis). > Anyway, it seems like this is a possible cause of it. thank you for sharing this info. another scenario I can think of is the following: - session A reads some items I - session B transiently removes items in I - session A logs out and starts to iterate over I in LocalItemStateManager (LISM) - session B saves changes and removed items are evicted from A's LISM - session A gets concurrent modification exception regards marcel