Grzegorz Kokosiński
Grzegorz Kokosiński
Even that below query fails: ``` select nodes_count, case nodes_count when 9 then 1 else 1/0 end from ( select count(*) nodes_count from system.runtime.nodes where state = 'active' ) ```...
CC: @fiedukow
In case of an error that causes the test to stuck, timeout should break the query execution and mark the benchmark as failed.
``` 00:24:53.068 Exception in thread "defaultTaskExecutor-2" java.lang.NullPointerException 00:24:53.068 at com.teradata.benchto.driver.graphite.GraphiteClient$GraphiteEventRequest$GraphiteEventRequestBuilder.when(GraphiteClient.java:149) 00:24:53.068 at com.teradata.benchto.driver.listeners.GraphiteEventExecutionListener.executionFinished(GraphiteEventExecutionListener.java:80) 00:24:53.068 at com.teradata.benchto.driver.listeners.benchmark.BenchmarkStatusReporter.lambda$reportExecutionFinished$3(BenchmarkStatusReporter.java:60) 00:24:53.068 at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 00:24:53.068 at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 00:24:53.068 at java.lang.Thread.run(Thread.java:745) ```
If a benchmark is running query multiple times, there is no need to log them each time. It clutters the log file without any new value. Instead, there could be...
See: ``` 00:16:57.976 Exception in thread "defaultTaskExecutor-1" 06:45:10.548 ERROR [defaultTaskExecutor-2] c.t.b.d.l.LoggingBenchmarkExecutionListener - Query failed: q15 (0/6), execution error: SQL is not an update statement: /* TPC_H Query 15 - Create...
It is already known that benchmark execution failed so there is not much sense to continue, CC: @fiedukow
Idea is to add simple mechanism which would set some test benchto environment so we could run benchto-driver with sample benchmarks and check that benchmarks were collected properly by benchto-service....
Go here to see more details: https://groups.google.com/forum/#!msg/presto-users/7DytyTsRG0Y/-mcXA3PkBgAJ > Hello, > I've recently stood up presto-yarn. I've run into a problem while querying a table that makes use of a custom...
As we do not support this we should prevent slider (yarn) somehow to not allocate two containers on the same node as it causes eventually whole presto cluster to fail...