[
https://issues.apache.org/jira/browse/DRILL-5735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16574083#comment-16574083
]
ASF GitHub Bot commented on DRILL-5735:
---------------------------------------
kkhatua commented on a change in pull request #1279: DRILL-5735: Allow
search/sort in the Options webUI
URL: https://github.com/apache/drill/pull/1279#discussion_r208779203
##########
File path:
exec/java-exec/src/main/java/org/apache/drill/exec/server/rest/WebServer.java
##########
@@ -194,6 +220,16 @@ private ServletContextHandler
createServletContextHandler(final boolean authEnab
staticHolder.setInitParameter("pathInfoOnly", "true");
servletContextHandler.addServlet(staticHolder, "/static/*");
+ //Add Local path resource (This will allow access to dynamically created
files like JavaScript)
+ final ServletHolder dynamicHolder = new ServletHolder("dynamic",
DefaultServlet.class);
+ //Skip if unable to get a temp directory (e.g. during Unit tests)
+ if (getTmpJavaScriptDir() != null) {
Review comment:
@arina-ielchiieva I'm unable to reply to your comment on line 452, so doing
it here.
```
arina-ielchiieva on Jun 15 Contributor
I meant what if we fail to delete temp directory? May be use delete quietly.
```
The temp directory is already marked as `deleteOnExit()` , so the JVM should
also do that during shutdown. However, it didn't seem to work always, so an
explicit delete is fine.
```
arina-ielchiieva on Jun 15 Contributor
Again defending getTmpJavaScriptDir() usage is incorrect. Consider the case
when server start will fail before generating js temp dir, so in close method
you'll call getTmpJavaScriptDir() and it will generate js options since it did
not do it at start up since all we need is to delete the directory.
```
The creation of the JS options is a negligible cost, as long as we are
cleaning up correctly.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
> UI options grouping and filtering & Metrics hints
> -------------------------------------------------
>
> Key: DRILL-5735
> URL: https://issues.apache.org/jira/browse/DRILL-5735
> Project: Apache Drill
> Issue Type: Improvement
> Components: Web Server
> Affects Versions: 1.9.0, 1.10.0, 1.11.0
> Reporter: Muhammad Gelbana
> Assignee: Kunal Khatua
> Priority: Major
> Fix For: 1.15.0
>
>
> I'm thinking of some UI improvements that could make all the difference for
> users trying to optimize low-performing queries.
> h2. Options
> h3. Grouping
> We can organize the options to be grouped by their scope of effect, this will
> help users easily locate the options they may need to tune.
> h3. Filtering
> Since the options are a lot, we can add a filtering mechanism (i.e. string
> search or group\scope filtering) so the user can filter out the options he's
> not interested in. To provide more benefit than the grouping idea mentioned
> above, filtering may include keywords also and not just the option name,
> since the user may not be aware of the name of the option he's looking for.
> h2. Metrics
> I'm referring here to the metrics page and the query execution plan page that
> displays the overview section and major\minor fragments metrics. We can show
> hints for each metric such as:
> # What does it represent in more details.
> # What option\scope-of-options to tune (increase ? decrease ?) to improve the
> performance reported by this metric.
> # May be even provide a small dialog to quickly allow the modification of the
> related option(s) to that metric
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
