Ok suit yourself. On Sun, Aug 9, 2015 at 5:08 PM Phil Steitz <phil.ste...@gmail.com> wrote:
> On 8/9/15 1:52 PM, James Carman wrote: > > Sorry, on my phone and can't see how to post online. My point is that it > > seems silly to reinvent the wheel when it comes to proxies and > > interceptors. That's precisely what Commons Proxy is designed to do. It > > already has pluggable proxy factories. Just use that. > > I don't see (yet) how we need a lot more than we already have in > [pool]; but if you can, patches welcome! > > I will go ahead and try to get a simple extension of what we have > now to work so we have something concrete to talk about. > > Phil > > > > On Sun, Aug 9, 2015 at 4:46 PM Phil Steitz <phil.ste...@gmail.com> > wrote: > > > >> Can we please not top-post. Gets hard to follow. > >> > >> On 8/9/15 10:17 AM, James Carman wrote: > >>> Okay, how about this for a proposal? We create a new module in > >>> commons-proxy called commons-proxy-pool which has a nice base class for > >>> folks to be able to create proxy objects to be members of their pool. > We > >>> could call it ProxiedPoolableObjectFactory or something like that. > >> Have you looked at the ProxiedObjectPool already in [pool]. It > >> pretty much does what we need. > >> > >>> This > >>> class would have helper methods or whatever to make it easy to create > >> proxy > >>> objects which can include interceptors and what not. Then, > commons-pool > >>> doesn't have to know anything about proxies at all. It just continues > to > >>> manage a pool of objects of a certain type. The objects just happen to > >> be > >>> proxies that (may or may not) have interceptors. We don't have to > worry > >>> about synchronization either. > >> I think there is value in having a configurable interceptor > >> construct integrated with the pool, having access to the pool as > >> well as the pooled object. Have a look at tomcat's jdbc-pool for > >> some examples. That pool *is* a proxy object pool (they don't use > >> delegatingXxx constructs like jdbc does). For [pool] (and [dbcp]) I > >> would like to keep the proxying configurable (so no registered > >> interceptors means no proxies). > >>> As for the logging (and metrics, etc) solution, I still think a > listener > >>> pattern is the way to go. Furthermore, I would suggest we deliver the > >>> "events" asynchronously to avoid slowing down the pool. The events > would > >>> be stuff like "object borrowed", "object returned", etc. > >> Agreed, some of that is already in place. Some interceptors may > >> gather stats, though, as part of their function. > >>> > >>> On Sun, Aug 9, 2015 at 11:53 AM James Carman < > ja...@carmanconsulting.com > >>> > >>> wrote: > >>> > >>>> If you want to decorate the calls to the pooled objects, then use > >> commons > >>>> proxy and a delegator proxy. Let's not bleed into other areas. Let > pool > >>>> concentrate on what it does best. > >> Right now, the proxying in ProxiedObjectPool is done by a pluggable > >> proxy source. Currently, a jdk proxy source is provided and a > >> source based on cglib. If you think that the setup there could be > >> improved somehow using Commons Proxy, we can certainly look at it. > >> > >> Phil > >> > >> > >>>> On Sun, Aug 9, 2015 at 11:45 AM James Carman < > >> ja...@carmanconsulting.com> > >>>> wrote: > >>>> > >>>>> I lean toward listeners instead. Much simpler > >>>>> On Sun, Aug 9, 2015 at 11:35 AM Phil Steitz <phil.ste...@gmail.com> > >>>>> wrote: > >>>>> > >>>>>> On 8/9/15 8:07 AM, Oliver Heger wrote: > >>>>>>> On 09.08.2015 02:49, James Carman wrote: > >>>>>>>> Yep, same thing I said back in the day. Would we want it to be a > >>>>>>>> true > >>>>>>>> "interceptor" or more of a "listener"? > >>>>>>> Sounds like a usual and interesting feature. IIUC the proposal of > >>>>>>> Phil, it goes more in the direction of interceptors. > >>>>>>> > >>>>>>> A point to keep in mind is how does this feature impact > >>>>>>> synchronization? Can interceptors be invoked outside of > >>>>>>> synchronized blocks? Otherwise, there is a certain risk of > >>>>>>> introducing subtle bugs. Bloch calls this "calling an alien method > >>>>>>> with a lock held". > >>>>>> Thanks, Oliver and very good point on synchronization. This would > >>>>>> require care. The nice thing about pool2 is that we have vastly > >>>>>> reduced the scope of synchronization. Most importantly (actually > >>>>>> since about pool 1.5), factory methods are all outside of sync > >>>>>> blocks and no locks are held on objects checked out by the pool > >>>>>> [1]. That said, we would need to be careful not to create liveness > >>>>>> or performance issues and we would have to provide good > >>>>>> documentation on things to look out for when implementing > >> interceptors. > >>>>>> Phil > >>>>>> > >>>>>> [1] The pool maintenance thread and borrow / return operations do > >>>>>> acquire locks on the PooledObject wrappers used by the pool, but not > >>>>>> on the objects that the interceptors would be working with. > >>>>>> Thread-safety of pool methods should ensure that use of pool > >>>>>> references in interceptors would also be safe. > >>>>>> > >>>>>> > >>>>>>> My 2 cents > >>>>>>> Oliver > >>>>>>> > >>>>>>>> On Sat, Aug 8, 2015 at 8:18 PM Phil Steitz > >>>>>>>> <phil.ste...@gmail.com> wrote: > >>>>>>>> > >>>>>>>>> On 8/8/15 5:04 PM, James Carman wrote: > >>>>>>>>>> We talked about this a while back with respect to logging,, > >>>>>>>>>> having a > >>>>>>>>>> PoolListener interface or something. > >>>>>>>>> Right. That could be one use. The nice thing there is the > >>>>>>>>> interceptor could bring in whatever logging / event propagation > >>>>>>>>> infrastructure it wanted to use. > >>>>>>>>> > >>>>>>>>> Phil > >>>>>>>>>> On Sat, Aug 8, 2015 at 7:36 PM Phil Steitz < > phil.ste...@gmail.com > >>>>>>>>> wrote: > >>>>>>>>>>> Tomcat's jdbc-pool has an interceptor feature that allows > custom > >>>>>>>>>>> code to be inserted into methods called on connections managed > by > >>>>>>>>>>> the pool. In [pool], we have the core infrastructure to > support > >>>>>>>>>>> this in a generic way via the ProxiedObjectPool. I propose > >>>>>>>>>>> that we > >>>>>>>>>>> extend this to allow users to configure interceptors to be > called > >>>>>>>>>>> when registered methods are invoked on checked out objects. I > >>>>>>>>>>> haven't really thought through how configuration would work, > but > >>>>>>>>>>> basically clients would register methods and possibly > interceptor > >>>>>>>>>>> properties and the interceptors would get references to the > >>>>>>>>>>> method, > >>>>>>>>>>> arguments, pool and pooled object. Configuring interceptors > in a > >>>>>>>>>>> GOP or GKOP would cause it to be wrapped in a > ProxiedObjectPool. > >>>>>>>>>>> Eventually, we could use this [pool] capability to enable the > >>>>>>>>>>> kind > >>>>>>>>>>> of thing that jdbc-pool provides with its interceptors in DBCP. > >>>>>>>>>>> With [pool] itself, I could see providing method stats > >>>>>>>>>>> collectors, > >>>>>>>>>>> abandoned timer reset (avoiding having to implement use()) and > >>>>>>>>>>> maybe > >>>>>>>>>>> a pooled object properties cache. If there are no > objections, I > >>>>>>>>>>> will open a JIRA and start experimenting. > >>>>>>>>>>> > >>>>>>>>>>> Phil > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>> > --------------------------------------------------------------------- > >>>>>>>>>>> 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 > >
