Return-Path: Delivered-To: apmail-click-dev-archive@www.apache.org Received: (qmail 91761 invoked from network); 4 Mar 2010 20:57:05 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 4 Mar 2010 20:57:05 -0000 Received: (qmail 50293 invoked by uid 500); 4 Mar 2010 20:56:53 -0000 Delivered-To: apmail-click-dev-archive@click.apache.org Received: (qmail 50274 invoked by uid 500); 4 Mar 2010 20:56:53 -0000 Mailing-List: contact dev-help@click.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@click.apache.org Delivered-To: mailing list dev@click.apache.org Received: (qmail 50267 invoked by uid 99); 4 Mar 2010 20:56:53 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 04 Mar 2010 20:56:53 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of henry.saputra@gmail.com designates 209.85.211.180 as permitted sender) Received: from [209.85.211.180] (HELO mail-yw0-f180.google.com) (209.85.211.180) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 04 Mar 2010 20:56:46 +0000 Received: by ywh10 with SMTP id 10so1137915ywh.18 for ; Thu, 04 Mar 2010 12:56:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=Od4NTFiTaFZTlIcoAiegT7AQPcXpNrefXbiTKytjNPc=; b=OWYGrgGbdhpwYPjYIC4JOerO2bEoSmK20aVlxdJlyH06vIGjo75O90biXvVOFvx1Oc YyaQVQ5X4DiBaCDVS228lqwrbjchqmHgIhUKUak4F1wVolu5TruJ2fz2a82xUgUeTVch +xPm8NlkVUVLMpodnL2mD8yYAd3oxnXMZjqE8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=T5A4ocC8zKeVvx64RgWBxSrzw9qFscM7DILdpwdY3QQbzpclntOr1d2mYF1pIqjQYh 4yqBOcDmgSYuGdvDlmlG3iFShmOn+eWXonyKXZ5llxAkz3+b81MxuUTy5X2RoRcfCMDP 3OFkLqdR70+MxU8wrS0/lcSQIka/GBS5UhYHY= MIME-Version: 1.0 Received: by 10.90.14.14 with SMTP id 14mr263586agn.34.1267736185815; Thu, 04 Mar 2010 12:56:25 -0800 (PST) In-Reply-To: <31bb1a8b1003041114x36ef9696xaa65d509c19acbd3@mail.gmail.com> References: <1661363576.4611267525047193.JavaMail.jira@brutus.apache.org> <115591113.66621267704687919.JavaMail.jira@brutus.apache.org> <31bb1a8b1003041114x36ef9696xaa65d509c19acbd3@mail.gmail.com> Date: Thu, 4 Mar 2010 12:56:25 -0800 Message-ID: <31bb1a8b1003041256p432cdfebo3c06c3a65e8600be@mail.gmail.com> Subject: Re: [jira] Closed: (CLK-636) Replace EDU.oswego.cs.dl.util.concurrent.ConcurrentReaderHashMap with java.util.concurrent.ConcurrentHashMap From: Henry Saputra To: dev@click.apache.org Content-Type: multipart/alternative; boundary=0016361e7b3206448b0480ffd57a --0016361e7b3206448b0480ffd57a Content-Type: text/plain; charset=UTF-8 HI Malcolm, If you think the risk is too high for now could we just leave it open so it could be revisited later? Sorry about keep pushing about this but maintaining legacy code is a pain and could have impact on performance. Thanks, - Henry On Thu, Mar 4, 2010 at 11:14 AM, Henry Saputra wrote: > Hi Malcolm, > > Thanks for your input for this bug. > > I understand the risk but I dont think this is the right solution since the > more Java move to better concurrency support, sticking with the "deprecated" > class will make the framework to be sluggish. > > Removing this dependency on Doug's concurrency package to Java EE > concurrency package and supporting Java generics should make the Click > framework to be more faster and efficient. > > I have used Spring 2.5 before with Java concurrent package before and never > see any problem. > > - Henry > > > On Thu, Mar 4, 2010 at 4:11 AM, Malcolm Edgar (JIRA) wrote: > >> >> [ >> https://issues.apache.org/jira/browse/CLK-636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel] >> >> Malcolm Edgar closed CLK-636. >> ----------------------------- >> >> Resolution: Won't Fix >> >> I appreciate the though around this issue but risk to production >> applications using various Spring version is too high for the reward of >> removing this class. >> >> regards Malcolm Edgar >> >> > Replace EDU.oswego.cs.dl.util.concurrent.ConcurrentReaderHashMap with >> java.util.concurrent.ConcurrentHashMap >> > >> ------------------------------------------------------------------------------------------------------------ >> > >> > Key: CLK-636 >> > URL: https://issues.apache.org/jira/browse/CLK-636 >> > Project: Click >> > Issue Type: Improvement >> > Components: core >> > Affects Versions: 2.2.0 >> > Reporter: Henry Saputra >> > Attachments: concurrentreader_patch.diff >> > >> > >> > Since Click required Java SDK 1.5 or later, we could leverage the >> java.util.concurrent.ConcurrentHashMap class to replace >> EDU.oswego.cs.dl.util.concurrent.ConcurrentReaderHashMap class so reducing >> the Click runtime dependency. >> > In my opinion here are some good reasons why: >> > 1. The ConcurrentHashMap class in Java SDK is more efficient since it >> utilizes internal hash classes to support better granularity and concurrency >> compare to simple syncrhonized on the instance like in >> DU.oswego.cs.dl.util.concurrent.ConcurrentReaderHashMap. >> > 2. Looking at the use case ConcurrentReaderHashMap in Click, it used to >> cache the OGNL expression (please correct me if I am wrong). This scenario >> does not need exclusive lock on update which is the intended/ preferred use >> case for ConcurrentReaderHashMap. If there is a miss on OGNL expression on a >> name in the cache, it will cerate one and put it to the map if no other >> thread has not. So it will still perform as well as or better locking entire >> table. However, if we do need exclusive lock on update, we can simulate >> ConcurrentReaderHashMap with ConcurrentHashMap by setting concurrencyLevel >> to one. >> > 3. The ConcurrentHashMap support generic which is part of task being >> done to move Click code to Java generics. >> > 4. Looks like the >> EDU.oswego.cs.dl.util.concurrent.ConcurrentReaderHashMap class is created by >> Doug Lea before contributions to java.util.concurrent packages in Java 1.5 >> SDK so the code may no longer optimized. >> >> -- >> This message is automatically generated by JIRA. >> - >> You can reply to this email to add a comment to the issue online. >> >> > --0016361e7b3206448b0480ffd57a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
HI Malcolm,

If you think the risk is too high= for now could we just leave it open so it could be revisited later?
<= div>
Sorry about keep pushing about this but maintaining lega= cy code is a pain and could have impact on performance.

Thanks,

- Henry

On Thu, Mar 4, 2010 at 11:14 AM, Henry Saputra <= henry.saputra@gmail.com> wrote:
Hi Malcolm,

Thanks for yo= ur input for this bug.

I understand the risk but I= dont think this is the right solution since the more Java move to better c= oncurrency support, sticking with the "deprecated" class will mak= e the framework to be sluggish.

Removing this dependency on Doug's concurrency pack= age to Java EE concurrency package and supporting Java generics should make= the Click framework to be more faster and efficient.

I have used Spring 2.5 before with Java concurrent package before and = never see any problem.

- H= enry


On Thu, Mar 4, 2010 at 4:11 AM, Malcolm Edgar (JIRA) <= jira@apache.org>= ; wrote:

=C2=A0 =C2=A0 [ https://issues.apache.org/jira/browse/CLK-636?page=3Dcom.atlass= ian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Malcolm Edgar closed CLK-636.
-----------------------------

=C2=A0 =C2=A0Resolution: Won't Fix

I appreciate the though around this issue but risk to production applicatio= ns using various Spring version is too high for the reward of removing this= class.

regards Malcolm Edgar

> Replace EDU.oswego.cs.dl.util.concurrent.ConcurrentReaderHashMap with = java.util.concurrent.ConcurrentHashMap
> ----------------------------------------------------------------------= --------------------------------------
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Key: CLK-636 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 URL: https:= //issues.apache.org/jira/browse/CLK-636
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Project: Click
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Issue Type: Improvement
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Components: core
> =C2=A0 =C2=A0Affects Versions: 2.2.0
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Reporter: Henry Saputra
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Attachments: concurrentreader_patch.diff >
>
> Since Click required Java SDK 1.5 or later, we could leverage the java= .util.concurrent.ConcurrentHashMap class to replace EDU.oswego.cs.dl.util.c= oncurrent.ConcurrentReaderHashMap class so reducing the Click runtime depen= dency.
> In my opinion here are some good reasons why:
> 1. The ConcurrentHashMap class in Java SDK is more efficient since it = utilizes internal hash classes to support better granularity and concurrenc= y compare to simple syncrhonized on the instance like in DU.oswego.cs.dl.ut= il.concurrent.ConcurrentReaderHashMap.
> 2. Looking at the use case ConcurrentReaderHashMap in Click, it used t= o cache the OGNL expression (please correct me if I am wrong). This scenari= o does not need exclusive lock on update which is the intended/ preferred u= se case for ConcurrentReaderHashMap. If there is a miss on OGNL expression = on a name in the cache, it will cerate one and put it to the map if no othe= r thread has not. So it will still perform as well as or better locking ent= ire table. However, if we do need exclusive lock on update, we can simulate= ConcurrentReaderHashMap with ConcurrentHashMap by setting concurrencyLevel= to one.
> 3. The ConcurrentHashMap support generic which is part of task being d= one to move Click code to Java generics.
> 4. Looks like the EDU.oswego.cs.dl.util.concurrent.ConcurrentReaderHas= hMap class is created by Doug Lea before contributions to java.util.concurr= ent packages in Java 1.5 SDK so the code may no longer optimized.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



--0016361e7b3206448b0480ffd57a--