[Mondrian] Mondrian Query Timeout

Joe Barnett thejoe at gmail.com
Tue Aug 9 12:59:49 EDT 2011


On Mon, Aug 8, 2011 at 11:27 PM, Julian Hyde <jhyde at pentaho.com> wrote:
>
>> On Mon, Aug 8, 2011 at 2:04 PM, Joe Barnett <thejoe at gmail.com> wrote:
>>> Ok, I've had a little bit of time to play with a trunk snapshot (up to
>>> perforce changelist 14501 right now).  Seems like a configurable
>>> ThreadFactory is, in fact, what we need, so I've attached a quick
>>> patch to allow this.  Let me know if you'd rather it be in JIRA, or if
>>> we need more discussion first (here or in JIRA) instead.
>
>
> I'm trying to get away from thread-locals. (They're the new global variables, you know!)
>
> So I'd rather find a solution to this problem that doesn't involve creating new threads. That's why I created the new classes Execution and Locus -- contexts that can be passed around, regardless of what thread is using them.
>
> RolapConnection.execute(Execution) ensures that the Execution is passed to executeInternal. I think that Execution object is sufficient context.
>
> If you still want to weave associations between threads, you should be able to use Execution.id as key to a hashmap.
>

Ok, going to have to think about this a bit more; main problem being
that our existing db access layer (DataSource implementation) is what
relies on the ThreadLocal, and I'm not comfortable having it rely on
any mondrian specific code.  May be able to think of a good way to
bridge the two somehow though.  I wonder if anyone else using
something like spring's thread bound transactions (ie.
TransactionSynchronizationManager) will run into similar issues, or
has any ideas that might help?

>>>
>>> A couple of questions I've come across not directly related to the
>>> shepherd thread:
>>>
>>> 1) We're still using mondrian.olap.* rather than the olap4j API, and
>>> are starting to get some deprecation warnings with 3.3 code.  Fine for
>>> now, but looking into moving over to olap4j instead, I don't see an
>>> obvious replacement for m.o.DriverManager#getConnection(PropertyList,
>>> CatalogLocator, DataSource).  We basically want to get an
>>> OlapConnection and pass it an existing, configured JDBC DataSource to
>>> use for db access.
>
> Pentaho BI server had the same problem. See how RolapConnection.createDataSource creates a javax.sql.DataSource from a name. It is usually the name of a class, but not necessarily. You can store a DataSource instance in a LockBox, pass its moniker (a string) as one of the properties of the olap4j connection, then resolve the object inside mondrian.
>
> Also note the interface DataSourceResolver, and its implementation JndiDataSourceResolver. Rather than using LockBox, you could stash your data source object in JNDI.
>
> Sorry it's so hairy. But it's JDBC's fault -- it only allows string-valued properties.
>

ok, looks like a DataSourceResolver (either JNDI or a simpler/custom
one) might be the easiest way for us.  Looks like LockBox is only
really used for Roles at this point if I'm reading the code correctly,
and not sure worth modifying to support DataSources if a DSResolver
can do what we need.


>>>
>>> 2) What's the best way to get the QueryTiming information after a
>>> result has been returned?  Right now, I'm casting the
>>> mondrian.olap.Result into a RolapResult and calling
>>> RolapResult#getExecution().getQueryTiming(), but seems like there
>>> might be a more elegant way of accessing it without needing a cast?
>
> Call MondrianOlap4jStatement.enableProfiling(ProfileHandler). The ProfileHandler will be called back after the statement has completed.
>
> Julian

ok great.  It looks like this enables alternate profiling code paths
which I would imagine would have some performance degradation, does it
make sense to have a more limited impact way to get just the
QueryTiming information without fully enabling the profiling
evaluator/explain plan/etc?

-Joe

ps.  congratulations on the new arrival!


More information about the Mondrian mailing list