On 12/12/11 1:08 PM, Simone Tripodi wrote: > Hi Phil, > I haven't kept up-to-date to GKOP and GOP development for a while, so > if you feel confident about current state, I trust you :)
Please do dive in and have a look. This is all new code for 2.0 and we could really use more eyeballs and testing on it. Thanks! Phil > I'll certainly give a help to work toward the release! > All the best, have a nice day! > -Simo > > http://people.apache.org/~simonetripodi/ > http://simonetripodi.livejournal.com/ > http://twitter.com/simonetripodi > http://www.99soft.org/ > > > > On Mon, Dec 12, 2011 at 8:42 PM, Phil Steitz <phil.ste...@gmail.com> wrote: >> On 12/12/11 12:29 PM, Simone Tripodi wrote: >>> Hi Phil, >>> thanks for the feedbacks! I would put some energies on [pool2] since I >>> am currently in the situation I need it - of course in the meantime I >>> can work with snapshots, but having a release would be definitively >>> better :) >>> >>> So I start filling an issue and update synchronized pools in >>> PoolUtils, then IMHO we should back speaking about implementing >>> Read/Write policy in Pools implementation. Thoughts? >> Personally, I think the 2.0 implementations in GKOP and GOP are good >> and would prefer to focus on making the final preparations for >> release rather than reworking the - very tricky - locking and >> synchronization semantics in those implementations. That said, if >> you or anyone else has better ideas, we can certainly look at them. >> Performance and intensive concurrency testing of the code in trunk >> would also be very helpful. >> >> Phil >>> -Simo >>> >>> http://people.apache.org/~simonetripodi/ >>> http://simonetripodi.livejournal.com/ >>> http://twitter.com/simonetripodi >>> http://www.99soft.org/ >>> >>> >>> >>> On Mon, Dec 12, 2011 at 7:21 PM, Phil Steitz <phil.ste...@gmail.com> wrote: >>>> On 12/12/11 10:56 AM, Phil Steitz wrote: >>>>> On 12/12/11 10:26 AM, Simone Tripodi wrote: >>>>>> Hi all guys, >>>>>> time ago we spoke about replacing the synchronized blocks inside >>>>>> pools, maybe using different strategies like Java5 Read/Write lock (I >>>>>> remind you Pool2 requires Java5) and I just started playing with >>>>>> PoolUtils with the SynchronizedObjectPool[1] inner class... >>>>>> Can we discuss about introducing such modifications inside pool >>>>>> implementations? >>>>> I would say go for it in PoolUtils. Assuming we keep these pools, >>>>> we should update them as we have GOP, GKOP. Regarding the pool you >>>>> mention specifically, it is a little funny in that it is designed to >>>>> be fully synchronized. Make sure that whatever implementation >>>>> changes you propose maintain the contract. >>>> Looking at the github code, I think there may be a problem. Borrow >>>> is as much a "write" operation as return - both modify the state of >>>> the pool. >>>> >>>> Phil >>>>> Phil >>>>>> Many thanks in advance, all the best! >>>>>> -Simo >>>>>> >>>>>> [1] https://gist.github.com/1468252 >>>>>> >>>>>> http://people.apache.org/~simonetripodi/ >>>>>> http://simonetripodi.livejournal.com/ >>>>>> http://twitter.com/simonetripodi >>>>>> http://www.99soft.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 >>>> >>> --------------------------------------------------------------------- >>> 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
