You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Phil Steitz <ph...@gmail.com> on 2015/08/09 01:35:14 UTC
[pool] Interceptors
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
Re: [pool] Interceptors
Posted by Phil Steitz <ph...@gmail.com>.
On 8/8/15 4:35 PM, Phil Steitz 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.
Something concrete to talk about is attached to POOL-301. The
example is something I could have used in an app I don't support any
more - an interceptor that invalidates an object that responds too
slowly. I would have needed something more sophisticated, but I
think the basic setup of getting the method, args and the pool to
the interceptor would have worked for me. The setup in the patch is
primitive - just before/after interceptors and no invocation-level
context (other than the method name, args, pooled object and pool).
I am happy to close my own issue as WONT_FIX if others don't think
this is a good idea. On the other hand, if people think it is a
good idea and anyone wants to improve the patch, I would be happy to
collaborate on this.
One thing I should fairly note is that careful analysis of the
interceptors provided with tomcat's jdbc-pool shows that only the
slow query reporter provides functionality not already present in
DBCP. The other interceptors all do things that DBCP can be
configured to do without adding interceptors.
Phil
>
> Phil
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [pool] Interceptors
Posted by Phil Steitz <ph...@gmail.com>.
On 8/8/15 5:49 PM, 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"?
Actually, we are probably talking about two different things here,
unless interceptors also get pool lifecycle events[1]. Most pool
logging should happen on events triggered by the pool itself
(destroying abandoned instances, validation / activation failures,
exceptions from factory methods, etc.). Interceptors would not be
involved in this, as they just proxy method calls on pooled
objects. They might do some logging as part of their function
(e.g., log method calls that take a long time or have certain
arguments); but I don't see interceptors (at least the way I am
looking at it now) as providing a full solution for pool logging. I
think pool event listeners are also worth investigating separately
from this.
Phil
[1] At first I thought interceptors should be able to register
interest in pool events as well as method invocations on pooled
objects. After playing with it a little, I concluded that that
would be mixing concerns. Also, there is no need for proxies for
the pool lifecycle invocations. If we want to enable this, we
should enable it directly - e.g., enable custom activators,
passivators, validators to be plugged in or chained.
>
> On Sat, Aug 8, 2015 at 8:18 PM Phil Steitz <ph...@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 <ph...@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
Re: [pool] Interceptors
Posted by James Carman <ja...@carmanconsulting.com>.
Ok suit yourself.
On Sun, Aug 9, 2015 at 5:08 PM Phil Steitz <ph...@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 <ph...@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 <ph...@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
> >>>>>>>> <ph...@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
>
>
Re: [pool] Interceptors
Posted by Phil Steitz <ph...@gmail.com>.
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 <ph...@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 <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 <ph...@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
>>>>>>>>> <ph...@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
Re: [pool] Interceptors
Posted by Phil Steitz <ph...@gmail.com>.
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 <ph...@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 <ph...@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
>>>>>>>> <ph...@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
Re: [pool] Interceptors
Posted by James Carman <ja...@carmanconsulting.com>.
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 <ph...@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 <ph...@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
> >>>>>> <ph...@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
>
>
Re: [pool] Interceptors
Posted by Phil Steitz <ph...@gmail.com>.
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 <ph...@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
>>>>>> <ph...@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 <ph...@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
Re: [pool] Interceptors
Posted by Matt Benson <gu...@gmail.com>.
On Aug 9, 2015 12:17 PM, "James Carman" <ja...@carmanconsulting.com> 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. 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.
>
+1 for dogfood and avoiding reinvention.
Matt
> 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.
>
>
> 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.
> > 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 <ph...@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
> >>> >> <ph...@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
> >>>
> >>>
Re: [pool] Interceptors
Posted by James Carman <ja...@carmanconsulting.com>.
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. 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.
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.
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.
> 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 <ph...@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
>>> >> <ph...@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 <ph...@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
>>>
>>>
Re: [pool] Interceptors
Posted by James Carman <ja...@carmanconsulting.com>.
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.
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 <ph...@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
>> >> <ph...@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 <ph...@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
>>
>>
Re: [pool] Interceptors
Posted by James Carman <ja...@carmanconsulting.com>.
I lean toward listeners instead. Much simpler
On Sun, Aug 9, 2015 at 11:35 AM Phil Steitz <ph...@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
> >> <ph...@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 <ph...@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
>
>
Re: [pool] Interceptors
Posted by Phil Steitz <ph...@gmail.com>.
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
>> <ph...@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 <ph...@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
Re: [pool] Interceptors
Posted by Oliver Heger <ol...@oliver-heger.de>.
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".
My 2 cents
Oliver
>
> On Sat, Aug 8, 2015 at 8:18 PM Phil Steitz <ph...@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 <ph...@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
Re: [pool] Interceptors
Posted by James Carman <ja...@carmanconsulting.com>.
Yep, same thing I said back in the day. Would we want it to be a true
"interceptor" or more of a "listener"?
On Sat, Aug 8, 2015 at 8:18 PM Phil Steitz <ph...@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 <ph...@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
>
>
Re: [pool] Interceptors
Posted by Phil Steitz <ph...@gmail.com>.
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 <ph...@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
Re: [pool] Interceptors
Posted by James Carman <ja...@carmanconsulting.com>.
We talked about this a while back with respect to logging,, having a
PoolListener interface or something.
On Sat, Aug 8, 2015 at 7:36 PM Phil Steitz <ph...@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
>
>