Hi --
It seems to me that AdapterActionFuture.rethrowExecutionException is
failing to capture the local side of the trace. In practice, if my
code calls actionGet and causes an ElasticSearchException, what gets
thrown an exception containing a trace of org.elasticsearch classes
and the ThreadPool it is running inside. There's nothing that
indicates which of my code invoked actionGet, which makes debugging
painful if the exception isn't caught and dealt with immediately.
I'd rather get something like:
org.elasticsearch.indices.IndexMissingException:
(my trace)
at
at <... my code ...>
caused by:
(remote trace)
at org.elasticsearch....
...
at org.elasticsearch.common.netty.util.internal.DeadLockProofWorker
$1.run(DeadLockProofWorker.java:44)
at java.util.concurrent.ThreadPoolExecutor
$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor
$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:680)
There isn't really a local side of a trace, its the (potentially remote)
exception that you get, the stack trace was initialized there. Are you
suggesting that we create a new exception in
the rethrowExecutionException to capture the stack trace of the actual
calling code? Something like setting its own stack trace with a new
initialized stack elements and moving the stack trace (can be remote, or
can be just one from a different thread) to an inner cause?
On Tue, Jan 3, 2012 at 10:20 PM, Lorrin Nelson lhn@lorrin.org wrote:
Hi --
It seems to me that AdapterActionFuture.rethrowExecutionException is
failing to capture the local side of the trace. In practice, if my
code calls actionGet and causes an ElasticSearchException, what gets
thrown an exception containing a trace of org.elasticsearch classes
and the ThreadPool it is running inside. There's nothing that
indicates which of my code invoked actionGet, which makes debugging
painful if the exception isn't caught and dealt with immediately.
I'd rather get something like:
org.elasticsearch.indices.IndexMissingException:
(my trace)
at
at <... my code ...>
caused by:
(remote trace)
at org.elasticsearch....
...
at org.elasticsearch.common.netty.util.internal.DeadLockProofWorker
$1.run(DeadLockProofWorker.java:44)
at java.util.concurrent.ThreadPoolExecutor
$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor
$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:680)
There isn't really a local side of a trace, its the (potentially remote)
exception that you get, the stack trace was initialized there. Are you
suggesting that we create a new exception in
the rethrowExecutionException to capture the stack trace of the actual
calling code? Something like setting its own stack trace with a new
initialized stack elements and moving the stack trace (can be remote, or
can be just one from a different thread) to an inner cause?
On Tue, Jan 3, 2012 at 10:20 PM, Lorrin Nelson l...@lorrin.org wrote:
Hi --
It seems to me that AdapterActionFuture.rethrowExecutionException is
failing to capture the local side of the trace. In practice, if my
code calls actionGet and causes an ElasticSearchException, what gets
thrown an exception containing a trace of org.elasticsearch classes
and the ThreadPool it is running inside. There's nothing that
indicates which of my code invoked actionGet, which makes debugging
painful if the exception isn't caught and dealt with immediately.
I'd rather get something like:
org.elasticsearch.indices.IndexMissingException:
(my trace)
at
at <... my code ...>
caused by:
(remote trace)
at org.elasticsearch....
...
at org.elasticsearch.common.netty.util.internal.DeadLockProofWorker
$1.run(DeadLockProofWorker.java:44)
at java.util.concurrent.ThreadPoolExecutor
$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor
$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:680)
Its problematic, because you can't change the cause of an exception (while,
without using reflection), and then there is the question of how to
construct the stack trace. You can call "get" which will return
ExecutionException with the relevant stack trace. I will think a bit more
of how this can be enhanced, but its problematic.
On Tue, Jan 3, 2012 at 11:43 PM, Lorrin Nelson lhn@lorrin.org wrote:
There isn't really a local side of a trace, its the (potentially remote)
exception that you get, the stack trace was initialized there. Are you
suggesting that we create a new exception in
the rethrowExecutionException to capture the stack trace of the actual
calling code? Something like setting its own stack trace with a new
initialized stack elements and moving the stack trace (can be remote, or
can be just one from a different thread) to an inner cause?
On Tue, Jan 3, 2012 at 10:20 PM, Lorrin Nelson l...@lorrin.org wrote:
Hi --
It seems to me that AdapterActionFuture.rethrowExecutionException is
failing to capture the local side of the trace. In practice, if my
code calls actionGet and causes an ElasticSearchException, what gets
thrown an exception containing a trace of org.elasticsearch classes
and the ThreadPool it is running inside. There's nothing that
indicates which of my code invoked actionGet, which makes debugging
painful if the exception isn't caught and dealt with immediately.
I'd rather get something like:
org.elasticsearch.indices.IndexMissingException:
(my trace)
at
at <... my code ...>
caused by:
(remote trace)
at org.elasticsearch....
...
at org.elasticsearch.common.netty.util.internal.DeadLockProofWorker
$1.run(DeadLockProofWorker.java:44)
at java.util.concurrent.ThreadPoolExecutor
$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor
$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:680)
Hrm, yes, I see what you mean. setStackTrace for the location doing
the munging is probably sufficient (anything that shows the calling
code, really). You could override Throwable.getCause; it's not final
and even within Throwable the cause is always accessed through the
accessor. But what to override it with? Need to something which is
equivalent to "this" in all respects except that it's getCause is
equivalent to super.getCause(). Don't see an easy way to do that.
Maybe simpler is better in this case. Give ElasticSearchException an
accessor to a List of places (e.g. a List<StackElement>) the
exception has passed through, kind of like the Received: headers on an
email. Just add to that in the
AdapterActionFuture.rethrowExecutionException method. What do you
think?
Its problematic, because you can't change the cause of an exception (while,
without using reflection), and then there is the question of how to
construct the stack trace. You can call "get" which will return
ExecutionException with the relevant stack trace. I will think a bit more
of how this can be enhanced, but its problematic.
On Tue, Jan 3, 2012 at 11:43 PM, Lorrin Nelson l...@lorrin.org wrote:
There isn't really a local side of a trace, its the (potentially remote)
exception that you get, the stack trace was initialized there. Are you
suggesting that we create a new exception in
the rethrowExecutionException to capture the stack trace of the actual
calling code? Something like setting its own stack trace with a new
initialized stack elements and moving the stack trace (can be remote, or
can be just one from a different thread) to an inner cause?
On Tue, Jan 3, 2012 at 10:20 PM, Lorrin Nelson l...@lorrin.org wrote:
Hi --
It seems to me that AdapterActionFuture.rethrowExecutionException is
failing to capture the local side of the trace. In practice, if my
code calls actionGet and causes an ElasticSearchException, what gets
thrown an exception containing a trace of org.elasticsearch classes
and the ThreadPool it is running inside. There's nothing that
indicates which of my code invoked actionGet, which makes debugging
painful if the exception isn't caught and dealt with immediately.
I'd rather get something like:
org.elasticsearch.indices.IndexMissingException:
(my trace)
at
at <... my code ...>
caused by:
(remote trace)
at org.elasticsearch....
...
at org.elasticsearch.common.netty.util.internal.DeadLockProofWorker
$1.run(DeadLockProofWorker.java:44)
at java.util.concurrent.ThreadPoolExecutor
$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor
$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:680)
Thats possible, though then you need to serialize them properly as well.
Note, using StackElement is not performant since some exceptions can happen
a lot of time (version conflict for example).
On Fri, Jan 13, 2012 at 7:25 AM, Lorrin Nelson lhn@lorrin.org wrote:
Hrm, yes, I see what you mean. setStackTrace for the location doing
the munging is probably sufficient (anything that shows the calling
code, really). You could override Throwable.getCause; it's not final
and even within Throwable the cause is always accessed through the
accessor. But what to override it with? Need to something which is
equivalent to "this" in all respects except that it's getCause is
equivalent to super.getCause(). Don't see an easy way to do that.
Maybe simpler is better in this case. Give ElasticSearchException an
accessor to a List of places (e.g. a List<StackElement>) the
exception has passed through, kind of like the Received: headers on an
email. Just add to that in the
AdapterActionFuture.rethrowExecutionException method. What do you
think?
Its problematic, because you can't change the cause of an exception
(while,
without using reflection), and then there is the question of how to
construct the stack trace. You can call "get" which will return
ExecutionException with the relevant stack trace. I will think a bit more
of how this can be enhanced, but its problematic.
On Tue, Jan 3, 2012 at 11:43 PM, Lorrin Nelson l...@lorrin.org wrote:
There isn't really a local side of a trace, its the (potentially
remote)
exception that you get, the stack trace was initialized there. Are
you
suggesting that we create a new exception in
the rethrowExecutionException to capture the stack trace of the
actual
calling code? Something like setting its own stack trace with a new
initialized stack elements and moving the stack trace (can be
remote, or
can be just one from a different thread) to an inner cause?
On Tue, Jan 3, 2012 at 10:20 PM, Lorrin Nelson l...@lorrin.org
wrote:
Hi --
It seems to me that AdapterActionFuture.rethrowExecutionException
is
failing to capture the local side of the trace. In practice, if my
code calls actionGet and causes an ElasticSearchException, what
gets
thrown an exception containing a trace of org.elasticsearch classes
and the ThreadPool it is running inside. There's nothing that
indicates which of my code invoked actionGet, which makes debugging
painful if the exception isn't caught and dealt with immediately.
I'd rather get something like:
org.elasticsearch.indices.IndexMissingException:
(my trace)
at
at <... my code ...>
caused by:
(remote trace)
at org.elasticsearch....
...
at
org.elasticsearch.common.netty.util.internal.DeadLockProofWorker
$1.run(DeadLockProofWorker.java:44)
at java.util.concurrent.ThreadPoolExecutor
$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor
$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:680)
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.