[Mondrian] Mondrian Query Timeout
jhyde at pentaho.com
Tue Aug 9 02:27:57 EDT 2011
> 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.
>> 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.
>> 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.
More information about the Mondrian