commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Carman <ja...@carmanconsulting.com>
Subject Re: [pool] Interceptors
Date Sun, 09 Aug 2015 20:52:40 GMT
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.

On Sun, Aug 9, 2015 at 4:46 PM Phil Steitz <phil.steitz@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 <james@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 <
> james@carmanconsulting.com>
> >> wrote:
> >>
> >>> I lean toward listeners instead. Much simpler
> >>> On Sun, Aug 9, 2015 at 11:35 AM Phil Steitz <phil.steitz@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.steitz@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.steitz@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-unsubscribe@commons.apache.org
> >>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>>>
> ---------------------------------------------------------------------
> >>>>>>>
> >>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>>>>
> >>>>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>
> >>>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message