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
