On 8/9/15 2:08 PM, Phil Steitz 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). Sorry, s/jdbc/dbcp above.
Phil >>> 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
