Oliver Heger wrote: > AIUI the mission of commons-lang is to provide extensions and > improvements for existing Java API classes. The concurrent package in > Java 5 is a great step forward in supporting multi-threaded programming > in Java, nevertheless there is certainly still room for improvements. > The proposed concurrent utilities for lang are not intended to reinvent > the wheel, but to implement additional and convenience functionality on > top of the existing API. +1 > > @Ted: The proposed class is not high-sophisticated, but given the > additional 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?
Agree on characterization of [lang]. I wonder though whether what you have in mind might quickly grow to be too large for [lang]. How about starting in the sandbox (once you have the grant) so we have something concrete to talk about? Looks useful and interesting to me. Phil > > 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. Threads wishing to consume >> the load >> bounded resource would request a token before sending a query. This >> would >> 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.moham...@gmail.com> wrote: >> >>> Sorry for the question, but why we need a new *concurrent* utils in >>> commons-lang while we have the concurrent package in Java SE 5 ? >>> >>> On Sat, Sep 5, 2009 at 9:48 PM, Oliver >>> Heger<oliver.he...@oliver-heger.de> wrote: >>>> In my day job I have written a synchronization primitive that may be of >>>> 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 hopefully >>>> should not be a problem). >>>> >>>> Now to the synchronization primitive: It is a class called >>>> "LoadBarrier" >>>> that is somewhat similar to a semaphor in that it allows a configurable >>>> number of locks to be hold. But there is also a timing aspect: The >>>> limit >>> 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 >>>> system >>> 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-unsubscr...@commons.apache.org >>>> For additional commands, e-mail: dev-h...@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-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
