[Mondrian] Mapping user requests to mondrian MDX and SQL

Wright, Jeff jeff.s.wright at truvenhealth.com
Fri Apr 4 10:32:57 EDT 2014


Luc, the monitor API sounds like a window into what’s going on right now. I think the spirit of Bob’s request is for analysis after the fact. We have Mondrian embedded in an application, and would like to correlate the Mondrian logs to the specific report request in the surrounding app, and to have that in an slf4j log.

The JIRA for JMX has 14 votes right now ☺
http://jira.pentaho.com/browse/MONDRIAN-1448

--jeff

From: mondrian-bounces at pentaho.org [mailto:mondrian-bounces at pentaho.org] On Behalf Of Baldwin, Bob
Sent: Friday, April 04, 2014 10:28 AM
To: Mondrian developer mailing list
Subject: Re: [Mondrian] Mapping user requests to mondrian MDX and SQL

Thanks Luc for the quick response!

I’ll investigate the monitor and see if it fits our needs. We would also be interested in the JMX support if that feature were to be resurrected.

Bob

From: mondrian-bounces at pentaho.org<mailto:mondrian-bounces at pentaho.org> [mailto:mondrian-bounces at pentaho.org] On Behalf Of Luc Boudreau
Sent: Friday, April 04, 2014 10:22 AM
To: Mondrian developer mailing list
Subject: Re: [Mondrian] Mapping user requests to mondrian MDX and SQL

There's an easier way to track them.

In Mondrian 3.3.X, we have introduced the Mondrian monitor API.

    final Monitor monitor =
            MondrianServer.forConnection(rolapConnection)
            .getMonitor();
Through the monitor, you can get all sorts of interesting metrics, like the MDX queries running, which SQL statements they have created, how many cells from the cache were hits & misses, and much more. Would that be of help?
We also have a branch with JMX support, but we haven't had much traction for that feature so it stayed on the back burner for a while now. Maybe now's the time to resurrect it.
Luc

On Fri, Apr 4, 2014 at 10:02 AM, Baldwin, Bob <robert.w.baldwin at truvenhealth.com<mailto:robert.w.baldwin at truvenhealth.com>> wrote:
We are currently trying to map a user request for a report to the MDX and the SQL generated by Mondrian.

To do this we are intercepting the “mondrian.mdx” and “mondrian.sql” loggers with a new slf4j appender (we are bridging log4j to slf4j) to write the MDX and subsequent SQL to a database log. In an attempt to map the MDX and SQL to a specific request by user, we are setting MDC values to be used by the appender when Mondrian kicks off the log. This works fine if enough time occurs between requests to Mondrian as a new executor thread is created.

The problem, for us, occurs when a the executor thread is reused. Instead of the new MDC values being propagated to the executor, they are persisting because it’s the same thread, instead of a new one which would inherit the new MDC properties from the parent thread.

Is there a way to accurately track the MDX and SQL ran per request to Mondrian and map that back to the requesting thread? I suspect forcing a new executor thread every time would solve this (if possible) but I worry about the performance implications of doing that.

Thanks for any help/direction.

Truven Health Analytics
Bob Baldwin
Software Engineer

Truven Health Analytics
O: 734.786.5365<tel:734.786.5365>
robert.w.baldwin at truvenhealth.com<mailto:robert.w.baldwin at truvenhealth.com>
truvenhealth.com<http://truvenhealth.com>

[Truven Health Analytics]


_______________________________________________
Mondrian mailing list
Mondrian at pentaho.org<mailto:Mondrian at pentaho.org>
http://lists.pentaho.org/mailman/listinfo/mondrian

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.pentaho.org/pipermail/mondrian/attachments/20140404/1a748d8c/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 3803 bytes
Desc: image001.gif
Url : http://lists.pentaho.org/pipermail/mondrian/attachments/20140404/1a748d8c/attachment-0001.gif 


More information about the Mondrian mailing list