<br>Good. That's exactly what I had in mind.<br><br>As for b), we are using backport-util-concurrent so I think we're good.I'll make sure to test thoroughly.<br><br>Luc<br><br><br><br><div class="gmail_quote">On Mon, Jul 11, 2011 at 6:21 PM, Julian Hyde <span dir="ltr"><<a href="mailto:jhyde@pentaho.com">jhyde@pentaho.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><u></u>
<div>
<div><span><font color="#000080" face="Lucida Sans" size="2">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" target="_blank"><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</span></font></font></u></a></font></span> )
is perfect for this.</div>
<div><span><font color="#000080" face="Lucida Sans" size="2"></font></span> </div>
<div><span><font color="#000080" face="Lucida Sans" size="2">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><font color="#000080" face="Lucida Sans" size="2"></font></span> </div>
<div><span><font color="#000080" face="Lucida Sans" size="2">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><font color="#000080" face="Lucida Sans" size="2"></font></span> </div>
<div><span><font color="#000080" face="Lucida Sans" size="2">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><font color="#000080" face="Lucida Sans" size="2"></font></span> </div>
<div><span><font color="#000080" face="Lucida Sans" size="2">Let me be clear that this is a "nice to have". And
t</font></span><span><font color="#000080" face="Lucida Sans" size="2">here are some implementation details I haven't
solved:</font></span></div>
<div><span><font color="#000080" face="Lucida Sans" size="2"></font></span> </div>
<div><span><font color="#000080" face="Lucida Sans" size="2">(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><font color="#000080" face="Lucida Sans" size="2"></font></span> </div>
<div><span><font color="#000080" face="Lucida Sans" size="2">(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><font color="#000080" face="Lucida Sans" size="2"></font></span> </div>
<div><span><font color="#000080" face="Lucida Sans" size="2">(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><font color="#000080" face="Lucida Sans" size="2"></font></span> </div>
<div><span><font color="#000080" face="Lucida Sans" size="2">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" align="left" lang="en-us">
<hr>
<font face="Tahoma" size="2"><b>From:</b> Luc Boudreau
[mailto:<a href="mailto:lucboudreau@gmail.com" target="_blank">lucboudreau@gmail.com</a>] <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></div><div class="h5">
<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"><span><span style="font:7pt 'Times New Roman'"></span></span></span>Stop all SQL
statements currently associated to this Execution.
</li><li>Do house cleaning.
</li><li>Bake a cake. (optional)<br>
</li><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> </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></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></div></div></blockquote></div>
</blockquote></div><br>