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 21:10:25 GMT
Ok suit yourself.
On Sun, Aug 9, 2015 at 5:08 PM Phil Steitz <phil.steitz@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.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
> >>
> >>
>
>
> ---------------------------------------------------------------------
> 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