It was a relatively minor change, so I put up a PR for it here:
https://github.com/locationtech/geomesa/pull/2557
Please test it out if you have time. I'm not planning on
back-porting a fix to earlier releases, but if you would like to do
so feel free to submit a PR.
Thanks,
Emilio
On 5/29/20 1:38 PM, Amit Srivastava
wrote:
Hi Emilio,
Thanks for quick reply. I will prefer to re-throw the
exception to the main thread. What is your suggestion? Are
you planning to fix it in a branch? Please let me know next
action items?
Hello,
Interesting, I would expect unhandled exceptions in the
executor service to at least be logged or dumped to
stderr. We could catch exceptions and re-throw them back
to the main thread (killing the whole scan), or just log
them. Which do you think would be preferable?
Thanks,
Emilio
On 5/29/20 3:41 AM, Amit Srivastava wrote:
Hi Emilio,
It looks like we found the issue behind the
partial response from Geomesa. I added multiple
logs in geomesa code and found at the time of
CallTimeoutException over here [1], this [2]
ExecutorService is swallowing the exception since
the code is not checking exception for future. Any
suggestions?
It depends on the indices you've created for
your data. Since the primary z3 index has a date
prefix, if you specify a one-sided date query
like below, then it has to scan all date
prefixes that come before that date. You could
mitigate this by adding a geometry only index
(i.e. z2) or by specifying a start date in your
filter.
Thanks,
Emilio
Regards,
Amit Kumar Srivastava
--
Regards,
Amit Kumar Srivastava