Return-Path: Delivered-To: apmail-commons-dev-archive@www.apache.org Received: (qmail 85278 invoked from network); 6 Sep 2009 19:47:10 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 6 Sep 2009 19:47:10 -0000 Received: (qmail 82455 invoked by uid 500); 6 Sep 2009 19:47:10 -0000 Delivered-To: apmail-commons-dev-archive@commons.apache.org Received: (qmail 82324 invoked by uid 500); 6 Sep 2009 19:47:09 -0000 Mailing-List: contact dev-help@commons.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Commons Developers List" Delivered-To: mailing list dev@commons.apache.org Received: (qmail 82314 invoked by uid 99); 6 Sep 2009 19:47:09 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 06 Sep 2009 19:47:09 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of nour.mohammad@gmail.com designates 209.85.220.226 as permitted sender) Received: from [209.85.220.226] (HELO mail-fx0-f226.google.com) (209.85.220.226) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 06 Sep 2009 19:46:58 +0000 Received: by fxm26 with SMTP id 26so1724646fxm.42 for ; Sun, 06 Sep 2009 12:46:37 -0700 (PDT) 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 :content-transfer-encoding; bh=1VDqvBrGmKuP/8Q6fulgDcxdSudhAwt3gDZ00mPhIYw=; b=KN1aNvPezIuOinqsBPGV4m9woyxAuT3cOcB4HcGiyLOFhySRcdqfNXqXNHHnEugH6G EGOLnYudB2fgdWP1o/S1INoGZlhqMkjGF5soQSgoRZvRbJt2hTklNJ6ZPDupgeeEZUyV kRJgHygM3Lkk8ZNOjGOLwFwn+PIX98/t+4zXk= 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:content-transfer-encoding; b=so+45LiMl4y2xbkCgHs0tMexuTenh6gOt38i3yGfYZQY3CyDg9WdM+fLtgzI7ynCwT iyRHZ64qsf7Clv+mEFHgoWEgOuskZvbyF3WZHHgA1VFNZ+MQSGpg4v5RJcfmKbzvqrEC 0jfzXRfBX29UwNa3jj+EQf6ZLVrSQTJvbUldU= MIME-Version: 1.0 Received: by 10.223.56.154 with SMTP id y26mr5040885fag.78.1252266397346; Sun, 06 Sep 2009 12:46:37 -0700 (PDT) In-Reply-To: <4AA3DCD3.2030608@oliver-heger.de> References: <4AA2B275.30700@oliver-heger.de> <4AA3DCD3.2030608@oliver-heger.de> Date: Sun, 6 Sep 2009 21:46:37 +0200 Message-ID: Subject: Re: [lang] New synchronization primitive From: Mohammad Nour El-Din To: Commons Developers List Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org I agree with regarding the point that we should extend and enhance what we already have, either in standard Java API(s) or what is already provided in other frameworks. For the class that you proposed, we can consider it like a utility class that is going to be provided instead of re-writing it. On Sun, Sep 6, 2009 at 6:01 PM, Oliver Heger wrote: > AIUI the mission of commons-lang is to provide extensions and improvement= s > for existing Java API classes. The concurrent package in Java 5 is a grea= t > step forward in supporting multi-threaded programming in Java, neverthele= ss > there is certainly still room for improvements. The proposed concurrent > utilities for lang are not intended to reinvent the wheel, but to impleme= nt > additional and convenience functionality on top of the existing API. > > @Ted: The proposed class is not high-sophisticated, but given the additio= nal > timing aspect it is not trivial either. Of course, it can be implemented > using standard Java means (that's what I did), but having something that > works out of the box is surely preferable than having to create your own > implementation. This is the purpose of a library, isn't it? > > Oliver > > Ted Dunning schrieb: >> >> In particular, why can this not be implemented using the Java 5 >> primitives? >> >> For instance, a thread could be created that adds tokens at a fixed rate >> to >> a blocking queue up to a small maximum. =A0Threads wishing to consume th= e >> load >> bounded resource would request a token before sending a query. =A0This w= ould >> enforce a maximum use rate. >> >> I could imagine a similar use of a semaphore as well. >> >> On Sat, Sep 5, 2009 at 3:03 PM, Mohammad Nour El-Din < >> nour.mohammad@gmail.com> wrote: >> >>> Sorry for the question, but why we need a new *concurrent* utils in >>> commons-lang while we have =A0the concurrent package in Java SE 5 ? >>> >>> On Sat, Sep 5, 2009 at 9:48 PM, Oliver >>> Heger wrote: >>>> >>>> In my day job I have written a synchronization primitive that may be o= f >>>> interest for the proposed concurrent package of the new version of >>>> commons-lang. I first want to check whether there is interest in this >>> >>> stuff, >>>> >>>> then I can talk to my employer about the code donation (which hopefull= y >>>> should not be a problem). >>>> >>>> Now to the synchronization primitive: It is a class called "LoadBarrie= r" >>>> that is somewhat similar to a semaphor in that it allows a configurabl= e >>>> number of locks to be hold. But there is also a timing aspect: The lim= it >>> >>> of >>>> >>>> locks is enforced in a configurable time unit. If a thread requests >>> >>> another >>>> >>>> lock when the maximum number of locks is already reached, it gets >>>> blocked >>>> until the time unit is over. After that all blocked threads are freed >>>> and >>>> can again try to aquire a lock. >>>> >>>> The background of this class is that it provides an easy way of >>> >>> controlling >>>> >>>> the load produced by a process or enforcing a threashold. In our use >>>> case >>> >>> we >>>> >>>> had a background process running queries on a database for statistical >>>> evaluations. To ensure that the database load does not affect the syst= em >>> >>> a >>>> >>>> LoadBarrier was used that enforced a limit of database queries per >>> >>> second. >>>> >>>> WDYT? If there is interest, I am going to address my employer and then >>>> create a JIRA enhancement ticket. >>>> >>>> Oliver >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org >>>> For additional commands, e-mail: dev-help@commons.apache.org >>>> >>>> >>> >>> >>> -- >>> Thanks >>> - Mohammad Nour >>> - LinkedIn: http://www.linkedin.com/in/mnour >>> ---- >>> "Life is like riding a bicycle. To keep your balance you must keep >>> moving" >>> - Albert Einstein >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org >>> For additional commands, e-mail: dev-help@commons.apache.org >>> >>> >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org > For additional commands, e-mail: dev-help@commons.apache.org > > --=20 Thanks - Mohammad Nour - LinkedIn: http://www.linkedin.com/in/mnour ---- "Life is like riding a bicycle. To keep your balance you must keep moving" - Albert Einstein --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org For additional commands, e-mail: dev-help@commons.apache.org