Return-Path: X-Original-To: apmail-cxf-dev-archive@www.apache.org Delivered-To: apmail-cxf-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id DAB1C11D52 for ; Mon, 14 Jul 2014 10:05:51 +0000 (UTC) Received: (qmail 89189 invoked by uid 500); 14 Jul 2014 10:05:51 -0000 Delivered-To: apmail-cxf-dev-archive@cxf.apache.org Received: (qmail 89120 invoked by uid 500); 14 Jul 2014 10:05:51 -0000 Mailing-List: contact dev-help@cxf.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cxf.apache.org Delivered-To: mailing list dev@cxf.apache.org Received: (qmail 89109 invoked by uid 99); 14 Jul 2014 10:05:51 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 14 Jul 2014 10:05:51 +0000 X-ASF-Spam-Status: No, hits=-5.0 required=5.0 tests=RCVD_IN_DNSWL_HI,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of asoldano@redhat.com designates 209.132.183.28 as permitted sender) Received: from [209.132.183.28] (HELO mx1.redhat.com) (209.132.183.28) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 14 Jul 2014 10:05:48 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s6EA5GxE031542 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Mon, 14 Jul 2014 06:05:16 -0400 Received: from localhost.localdomain (vpn1-4-215.ams2.redhat.com [10.36.4.215]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s6EA5Ent022178 for ; Mon, 14 Jul 2014 06:05:15 -0400 Message-ID: <53C3AB55.9050408@redhat.com> Date: Mon, 14 Jul 2014 12:05:09 +0200 From: Alessio Soldano User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130805 Thunderbird/17.0.8 MIME-Version: 1.0 To: dev@cxf.apache.org Subject: Re: Performance issue with Content-ID computation of multipart MTOM/XOP messages References: <53C38CA1.7040308@redhat.com> <53C39ECD.7020509@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Virus-Checked: Checked by ClamAV on apache.org On 14/07/14 11:58, Aki Yoshida wrote: > I'm not sure whether it is really necessary to make the cid part > depend on the namespace string. > > If we only need to guarantee uniquness within a document, a single > thread calling the createContentID method will get a series of unique > IDs. However, as the static variable counter is not synchronously > updated, currently two threads may get the same ID value but this > situation is not relevant as long as these two threads are working on > two different documents. And even if two threads may be working on the > same document, using the namespace depending value for the cid part > won't decrease the collision chance very much as they are likely to be > using the same namespace value. If we need to guarantee uniqueness > among multiple documents, we will need a different mechanism anyway. > So, I see not much benefit in using the namespace depending variable > here. Thanks for the consideration Aki. This is basically my first question; the reason why I asked about existing spec requirement is also that in most cases the namespace there will simply be null, so we're already skipping the if block very often... I see not much benefit in the namespace usage here too. Cheers Alessio -- Alessio Soldano Web Service Lead, JBoss