<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content="text/html; charset=us-ascii" http-equiv=Content-Type>
<META name=GENERATOR content="MSHTML 9.00.8112.16430"></HEAD>
<BODY>
<DIV><SPAN class=577454621-11072011><FONT color=#000080 size=2
face="Lucida Sans">However we solve this, we need a data structure that records
all SQL statements that are running in the service of a particular MDX
statement. The Execution class that I added on Friday (see <A
href="http://p4web.eigenbase.org/@md=d&c=6PU@/14436?ac=10"><U><FONT
color=#0000ff size=2><FONT color=#0000ff size=2><SPAN
lang=EN>http://p4web.eigenbase.org/@md=d&c=6PU@/14436?ac=10</U></FONT></FONT></SPAN></A> )
is perfect for this.</FONT></SPAN></DIV>
<DIV><SPAN class=577454621-11072011><FONT color=#000080 size=2
face="Lucida Sans"></FONT></SPAN> </DIV>
<DIV><SPAN class=577454621-11072011><FONT color=#000080 size=2
face="Lucida Sans">I couldn't tell whether you were suggesting this, but
just in case, let me state for the record: I think that killing Java
threads is a bad idea. It is very likely to make a mess. I think that Java code
under mondrian's control should continue to poll the 'canceled' flag. (Which on
Friday moved from Query to Execution.)</FONT></SPAN></DIV>
<DIV><SPAN class=577454621-11072011><FONT color=#000080 size=2
face="Lucida Sans"></FONT></SPAN> </DIV>
<DIV><SPAN class=577454621-11072011><FONT color=#000080 size=2
face="Lucida Sans">For SQL statements, mondrian should definitely call cancel.
If the JDBC driver of the database concerned is well-implemented, it
will do something sensible with the cancel request. (Probably three things:
cancel the synchronous call fairly quicky, throw a SQLException indicating that
the statement is canceled, and send a message to the deeper parts of the
infrastructure to cancel asynchronous processing, slower but more
exhaustively.)</FONT></SPAN></DIV>
<DIV><SPAN class=577454621-11072011><FONT color=#000080 size=2
face="Lucida Sans"></FONT></SPAN> </DIV>
<DIV><SPAN class=577454621-11072011><FONT color=#000080 size=2
face="Lucida Sans">Since Mondrian is itself an JDBC server (by virtue of olap4j
being an extension to JDBC), we should do something similar. It's worth asking:
what MondrianOlap4jStatement.executeOlapQuery() should do when canceled? I
expect that Execute.cancel will be polled every ~millisecond, so cancel the
statement should come back fairly quickly. We could make it come back quicker
still if executeOlapQuery were making a call to another thread. Then we could
interrupt that call without damaging either of the threads. </FONT></SPAN></DIV>
<DIV><SPAN class=577454621-11072011><FONT color=#000080 size=2
face="Lucida Sans"></FONT></SPAN> </DIV>
<DIV><SPAN class=577454621-11072011><FONT color=#000080 size=2
face="Lucida Sans">Let me be clear that this is a "nice to have". And
t</FONT></SPAN><SPAN class=577454621-11072011><FONT color=#000080 size=2
face="Lucida Sans">here are some implementation details I haven't
solved:</FONT></SPAN></DIV>
<DIV><SPAN class=577454621-11072011><FONT color=#000080 size=2
face="Lucida Sans"></FONT></SPAN> </DIV>
<DIV><SPAN class=577454621-11072011><FONT color=#000080 size=2
face="Lucida Sans">(a) I am speculating that there is an 'cancelable future' in
JDK 1.6 off-the-shelf. I mean: create a Future, have another thread (from an
ExecutionService presumably) do the work, and allow any 3rd thread to cancel
that call. Is this available in the JDK?</FONT></SPAN></DIV>
<DIV><SPAN class=577454621-11072011><FONT color=#000080 size=2
face="Lucida Sans"></FONT></SPAN> </DIV>
<DIV><SPAN class=577454621-11072011><FONT color=#000080 size=2
face="Lucida Sans">(b) If the calls you need are not available in JDK 1.4 or JDK
1.5, it's OK if they have inferior behavior. But it still needs to build &
run in those JDKs.</FONT></SPAN></DIV>
<DIV><SPAN class=577454621-11072011><FONT color=#000080 size=2
face="Lucida Sans"></FONT></SPAN> </DIV>
<DIV><SPAN class=577454621-11072011><FONT color=#000080 size=2
face="Lucida Sans">(c) MondrianOlap4jStatement.executeOlapQuery is not
necessarily the right place in the architecture to make the asynchronous
'slice'. Find the ideal place, maybe a little ways below it. But note that
Locus.peek() etc. uses a thread-local.</FONT></SPAN></DIV>
<DIV><SPAN class=577454621-11072011><FONT color=#000080 size=2
face="Lucida Sans"></FONT></SPAN> </DIV>
<DIV><SPAN class=577454621-11072011><FONT color=#000080 size=2
face="Lucida Sans">Julian</FONT></SPAN></DIV><BR>
<BLOCKQUOTE
style="BORDER-LEFT: #000080 2px solid; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px"
dir=ltr>
<DIV dir=ltr lang=en-us class=OutlookMessageHeader align=left>
<HR tabIndex=-1>
<FONT size=2 face=Tahoma><B>From:</B> Luc Boudreau
[mailto:lucboudreau@gmail.com] <BR><B>Sent:</B> Monday, July 11, 2011 8:57
AM<BR><B>To:</B> Julian Hyde<BR><B>Cc:</B> Mondrian developer mailing
list<BR><B>Subject:</B> Mondrian Query Timeout<BR></FONT><BR></DIV>
<DIV></DIV>
<P class=MsoNormal>Julian,</P>
<P class=MsoNormal> </P>
<P class=MsoNormal>Following your commit on the statements refactoring, I have
started to think about how we would now enforce a proper query timeout.
(MONDRIAN-415). </P>
<P class=MsoNormal> </P>
<P class=MsoNormal>What I had in mind is a simple system where, when creating
RolapResult objects (in RolapConnection.execute()) we fork the execution to a
second thread (let’s call it the execution thread). The first thread (let’s
call it the user thread) will wait a predetermined amount of time (the actual
timeout) and if the execution thread has not completed, the user thread will
perform the following.<SPAN style="FONT-FAMILY: Symbol"><SPAN><SPAN
style="FONT: 7pt 'Times New Roman'"></SPAN></SPAN></SPAN></P>
<UL>
<LI><SPAN
style="FONT-FAMILY: Symbol; mso-fareast-font-family: Symbol; mso-bidi-font-family: Symbol"><SPAN
style="mso-list: Ignore"><SPAN
style="FONT: 7pt 'Times New Roman'"></SPAN></SPAN></SPAN>Stop all SQL
statements currently associated to this Execution.
<LI>Do house cleaning.
<LI>Bake a cake. (optional)<BR>
<LI>Throw back a timeout exception.</LI></UL>
<P class=MsoNormal>This has several advantages. First off, we could remove all
checks for query timeout in the evaluator and centralize everything in a
single place.<SPAN style="mso-spacerun: yes"> </SPAN>Second, as it
stands now, there is no way to do a “hard stop” of any SQL statements running
for a given Execution as we sit in the same thread. As long as the SQL
Statement has not returned, we have no way to check for a timeout. As of now,
the best we can do is to set an arbitrary JDBC timeout, but since there is no
telling how many SQL statements will be issued, nor their priority, we cannot
determine the proper JDBC timeout value to apply. <SPAN
style="mso-spacerun: yes"></SPAN>By having the user thread overview the
execution process, it becomes much simpler to manage and cleanup all the
resources used by a query execution.</P>
<P class=MsoNormal><BR></P>
<P class=MsoNormal>Should I try this approach and submit a first POC?
<BR></P></BLOCKQUOTE></BODY></HTML>