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
