[
https://issues.apache.org/jira/browse/HTTPCORE-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13457120#comment-13457120
]
Oleg Kalnichevski commented on HTTPCORE-311:
--------------------------------------------
Seth
Just a few comments before we get to the essence of the issue.
* Generally change sets submitted as a single patch in udiff format are easier
to apply and review, which makes them more likely to get reviewed and accepted.
Usually it is recommended to check out the trunk either using SVN ot Git, make
changes locally, generate a single patch by running 'svn diff' or 'git diff
--staged' and attach it to the issue.
* While JodaTime is absolutely awesome, adding it as a dependency to HttpCore
is pretty much out of question.
As far as proposed changes are concerned polling for pool stats looks kind of
too hack-ish to me. I would be more in favor of adding this functionality
directly to the connection pool implementations and probably using a separate
mutex to guard pool stats in order to reduce lock contention with worker
threads. Would you be willing to invest a bit more of your time into reworking
your patch?
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: 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]
