On 8/9/15 1:52 PM, James Carman wrote:
> Sorry, on my phone and can't see how to post online. My point is that it
> seems silly to reinvent the wheel when it comes to proxies and
> interceptors. That's precisely what Commons Proxy is designed to do. It
> already has pluggable proxy factories. Just use that.

I don't see (yet) how we need a lot more than we already have in
[pool]; but if you can, patches welcome!

I will go ahead and try to get a simple extension of what we have
now to work so we have something concrete to talk about.

Phil
>
> On Sun, Aug 9, 2015 at 4:46 PM Phil Steitz <phil.ste...@gmail.com> wrote:
>
>> Can we please not top-post.  Gets hard to follow.
>>
>> On 8/9/15 10:17 AM, James Carman wrote:
>>> Okay, how about this for a proposal?  We create a new module in
>>> commons-proxy called commons-proxy-pool which has a nice base class for
>>> folks to be able to create proxy objects to be members of their pool.  We
>>> could call it ProxiedPoolableObjectFactory or something like that.
>> Have you looked at the ProxiedObjectPool already in [pool].  It
>> pretty much does what we need.
>>
>>>   This
>>> class would have helper methods or whatever to make it easy to create
>> proxy
>>> objects which can include interceptors and what not.  Then, commons-pool
>>> doesn't have to know anything about proxies at all.  It just continues to
>>> manage a pool of objects of a certain type.  The objects just happen to
>> be
>>> proxies that (may or may not) have interceptors.  We don't have to worry
>>> about synchronization either.
>> I think there is value in having a configurable interceptor
>> construct integrated with the pool, having access to the pool as
>> well as the pooled object.  Have a look at tomcat's jdbc-pool for
>> some examples.  That pool *is* a proxy object pool (they don't use
>> delegatingXxx constructs like jdbc does).  For [pool] (and [dbcp]) I
>> would like to keep the proxying configurable (so no registered
>> interceptors means no proxies).
>>> As for the logging (and metrics, etc) solution, I still think a listener
>>> pattern is the way to go. Furthermore, I would suggest we deliver the
>>> "events" asynchronously to avoid slowing down the pool.  The events would
>>> be stuff like "object borrowed", "object returned", etc.
>> Agreed, some of that is already in place.  Some interceptors may
>> gather stats, though, as part of their function.
>>>
>>> On Sun, Aug 9, 2015 at 11:53 AM James Carman <ja...@carmanconsulting.com
>>>
>>> wrote:
>>>
>>>> If you want to decorate the calls to the pooled objects, then use
>> commons
>>>> proxy and a delegator proxy. Let's not bleed into other areas. Let pool
>>>> concentrate on what it does best.
>> Right now, the proxying in ProxiedObjectPool is done by a pluggable
>> proxy source.  Currently, a jdk proxy source is provided and a
>> source based on cglib.  If you think that the setup there could be
>> improved somehow using Commons Proxy, we can certainly look at it.
>>
>> Phil
>>
>>
>>>> On Sun, Aug 9, 2015 at 11:45 AM James Carman <
>> ja...@carmanconsulting.com>
>>>> wrote:
>>>>
>>>>> I lean toward listeners instead. Much simpler
>>>>> On Sun, Aug 9, 2015 at 11:35 AM Phil Steitz <phil.ste...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> On 8/9/15 8:07 AM, Oliver Heger wrote:
>>>>>>> On 09.08.2015 02:49, James Carman wrote:
>>>>>>>> Yep, same thing I said back in the day. Would we want it to be a
>>>>>>>> true
>>>>>>>> "interceptor" or more of a "listener"?
>>>>>>> Sounds like a usual and interesting feature. IIUC the proposal of
>>>>>>> Phil, it goes more in the direction of interceptors.
>>>>>>>
>>>>>>> A point to keep in mind is how does this feature impact
>>>>>>> synchronization? Can interceptors be invoked outside of
>>>>>>> synchronized blocks? Otherwise, there is a certain risk of
>>>>>>> introducing subtle bugs. Bloch calls this "calling an alien method
>>>>>>> with a lock held".
>>>>>> Thanks, Oliver and very good point on synchronization.  This would
>>>>>> require care.  The nice thing about pool2 is that we have vastly
>>>>>> reduced the scope of synchronization.  Most importantly (actually
>>>>>> since about pool 1.5), factory methods are all outside of sync
>>>>>> blocks and no locks are held on objects checked out by the pool
>>>>>> [1].  That said, we would need to be careful not to create liveness
>>>>>> or performance issues and we would have to provide good
>>>>>> documentation on things to look out for when implementing
>> interceptors.
>>>>>> Phil
>>>>>>
>>>>>> [1] The pool maintenance thread and borrow / return operations do
>>>>>> acquire locks on the PooledObject wrappers used by the pool, but not
>>>>>> on the objects that the interceptors would be working with.
>>>>>> Thread-safety of pool methods should ensure that use of pool
>>>>>> references in interceptors would also be safe.
>>>>>>
>>>>>>
>>>>>>> My 2 cents
>>>>>>> Oliver
>>>>>>>
>>>>>>>> On Sat, Aug 8, 2015 at 8:18 PM Phil Steitz
>>>>>>>> <phil.ste...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> On 8/8/15 5:04 PM, James Carman wrote:
>>>>>>>>>> We talked about this a while back with respect to logging,,
>>>>>>>>>> having a
>>>>>>>>>> PoolListener interface or something.
>>>>>>>>> Right.  That could be one use.  The nice thing there is the
>>>>>>>>> interceptor could bring in whatever logging / event propagation
>>>>>>>>> infrastructure it wanted to use.
>>>>>>>>>
>>>>>>>>> Phil
>>>>>>>>>> On Sat, Aug 8, 2015 at 7:36 PM Phil Steitz <phil.ste...@gmail.com
>>>>>>>>> wrote:
>>>>>>>>>>> Tomcat's jdbc-pool has an interceptor feature that allows custom
>>>>>>>>>>> code to be inserted into methods called on connections managed by
>>>>>>>>>>> the pool.  In [pool], we have the core infrastructure to support
>>>>>>>>>>> this in a generic way via the ProxiedObjectPool.  I propose
>>>>>>>>>>> that we
>>>>>>>>>>> extend this to allow users to configure interceptors to be called
>>>>>>>>>>> when registered methods are invoked on checked out objects.  I
>>>>>>>>>>> haven't really thought through how configuration would work, but
>>>>>>>>>>> basically clients would register methods and possibly interceptor
>>>>>>>>>>> properties and the interceptors would get references to the
>>>>>>>>>>> method,
>>>>>>>>>>> arguments, pool and pooled object.  Configuring interceptors in a
>>>>>>>>>>> GOP or GKOP would cause it to be wrapped in a ProxiedObjectPool.
>>>>>>>>>>> Eventually, we could use this [pool] capability to enable the
>>>>>>>>>>> kind
>>>>>>>>>>> of thing that jdbc-pool provides with its interceptors in DBCP.
>>>>>>>>>>> With [pool] itself, I could see providing method stats
>>>>>>>>>>> collectors,
>>>>>>>>>>> abandoned timer reset (avoiding having to implement use()) and
>>>>>>>>>>> maybe
>>>>>>>>>>> a pooled object properties cache.   If there are no objections, I
>>>>>>>>>>> will open a JIRA and start experimenting.
>>>>>>>>>>>
>>>>>>>>>>> Phil
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>>>>>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>>>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>>>>
>>>>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Reply via email to