[
https://issues.apache.org/jira/browse/HTTPCORE-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13459031#comment-13459031
]
Oleg Kalnichevski commented on HTTPCORE-311:
--------------------------------------------
(1) The problem with volatile variables is while all of them are perfectly
thread-safe individually, as a collection they are not. There is always a time
window, however small, that these values can be out of sync with the actual
state of the pool. I still think they should be guarded by a mutex
(2) Your life might be much easier if you update the stats at the end of each
mutation (lease / release methods and so on) by copying them from the internal
collections. This method could be invoked to update immediately before
releasing the pool lock in each method.
Oleg
> Retrieval of primitive connection pool stat values
> --------------------------------------------------
>
> Key: HTTPCORE-311
> URL: https://issues.apache.org/jira/browse/HTTPCORE-311
> Project: HttpComponents HttpCore
> Issue Type: New Feature
> Components: HttpCore
> Affects Versions: 4.2.1
> Reporter: Seth Weiner
> Attachments: httpcomponents-monitoring-patch2.diff,
> httpcomponents-monitoring-patch3.diff, httpcomponents-monitoring-patch.diff,
> PollingPrimitivePoolControl.java, PollingPrimitivePoolControlTest.java,
> PrimitiveConnPoolControl.java
>
>
> The org.apache.http.pool.ConnPoolControl interface exposes valuable runtime
> metrics for a connection pool's individual routes and global values. However,
> it uses a bean class, org.apache.http.pool.PoolStats, to exposes the global
> values. This is problematic when trying to monitor these connection pool
> values at runtime since PoolStats is not Serializable and many jmx monitoring
> agents only support primitive values well. The value of the PoolStats class
> seems to be in trying to minimize the amount of locking of the pool required
> to get stats.
> The attached patch includes an interface that extends ConnPoolControl to add
> four methods to return the primitive value for global pool stats. There's an
> implementation of this interface that will delegate all of the
> ConnPoolControl methods to a delegate instance, and support retrieving the
> primitive global values by periodically retrieving and caching a PoolStats
> instance internally. This minimizes the amount of locking required while also
> making it easy to monitor these values.
> It would probably be ideal to incorporate this functionality directly into
> the existing ConnPoolControl interface, but the attached code provides a
> non-invasive way to achieve the desired effect.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
