Re: [reSIProcate] Handling StatisticsMessage
This has been committed as a stack-level stats handler, see
StatisticsHandler.hxx for details. This does not change the current default
stats handling and does not require any changes by users of stats messages.
Thanks,
-justin
-----Original Message-----
From: Justin Matthews [mailto:jmatthewsr@xxxxxxxxx]
Sent: Monday, October 16, 2006 12:03 PM
To: 'Jason Fischl'
Cc: 'resiprocate-devel@xxxxxxxxxxxxxxxxxxx'
Subject: RE: [reSIProcate] Handling StatisticsMessage
I like this way as well, but would like to go with the callback handler for
the following reasons:
* A stack level statistics message assigned to a TU seems inconsistent if
there are no TU-specific elements to the stats message. Right now this is a
stack-level gathering of stats.
* The callback is lighter weight than the TU handler as it doesn't need to
be posted to the TU FIFO. Most notably bypassing the locking, dynamic
casting required if sent via the TU.
In the end it really doesn't matter to me which way, I am just leaning
towards the callback. Unless other users would really like to see this
implemented as a TU level message then I would like to commit this as a
callback.
Thanks,
Justin
-----Original Message-----
From: jason.fischl@xxxxxxxxx [mailto:jason.fischl@xxxxxxxxx] On Behalf Of
Jason Fischl
Sent: Thursday, October 12, 2006 1:00 PM
To: Justin Matthews
Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [reSIProcate] Handling StatisticsMessage
An alternative would be to specify which TransactionUser you want the
stats messages posted to. This could be a method on the SipStack. Then
the StatisticsManager::poll method would just pass this TU into the
mStack.post method.
Jason
On 10/11/06, Justin Matthews <jmatthewsr@xxxxxxxxx> wrote:
> Ok, let me propose the following solution:
>
> Add a callback handler to the SipStack->StatisticsManager. The default
> behavior can be disabled/enabled using the return value from the handler
> (similar to ExternalLogger).
>
> Comments?
>
> Thanks,
>
> -Justin
>
> /** Interface functor for external stats handling. */
> class ExternalStatsHandler
> {
> public:
> virtual ~ExternalStatsHandler()=0;
> /** return true to also do default handling, false to supress
default
> handling. */
> virtual bool operator()(StatisticsMessage &statsMessage) = 0;
> };
>
> void
> StatisticsManager::poll()
> {
> ...
>
> bool postToStack = true;
> StatisticsMessage msg(appStats);
>
> if( mHandler )
> {
> postToStack = mHandler(msg);
> }
>
> if( postToStack )
> {
> mStack.post(msg);
> }
> }
> -----Original Message-----
> From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx
> [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Justin
> Matthews
> Sent: Wednesday, October 11, 2006 8:53 AM
> To: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> Subject: [reSIProcate] Handling StatisticsMessage
>
> Hello,
>
> Is it possible to handle the StatisticsMessage generated by the stack?
> Right now it looks like the message is being sent to the TuSelector by the
> stack and then just output to the logger. I know there was some earlier
> discussion on this but it looks like the code was never implemented or the
> ideas changed.
>
> Would a StatisticsMessage handler be a good solution, or maybe a mechanism
> to allow the StatisticsMessage to find a TU (DUM) to post the message to?
>
> Thanks,
>
> -Justin
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
>