# Lost exception traces **URL:** \ **Category:** Elasticsearch\ **Created:** [January 3, 2012, 8:20pm UTC](https://discuss.elastic.co/t/lost-exception-traces/6274 "2012-01-03T20:20:03Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![Lorrin\_Nelson](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/lorrin_nelson/32/3018_2.png) [@Lorrin\_Nelson](https://discuss.elastic.co/u/Lorrin_Nelson)\ **Post date:** [January 3, 2012, 8:20pm UTC](https://discuss.elastic.co/t/lost-exception-traces/6274/1 "2012-01-03T20:20:03Z")
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) -Lorrin ---
**Author:** ![kimchy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/kimchy/32/44952_2.png) [@kimchy](https://discuss.elastic.co/u/kimchy)\ **Post date:** [January 3, 2012, 8:44pm UTC](https://discuss.elastic.co/t/lost-exception-traces/6274/2 "2012-01-03T20:44:39Z")
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](mailto: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) > > -Lorrin ---
**Author:** ![Lorrin\_Nelson](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/lorrin_nelson/32/3018_2.png) [@Lorrin\_Nelson](https://discuss.elastic.co/u/Lorrin_Nelson)\ **Post date:** [January 3, 2012, 9:43pm UTC](https://discuss.elastic.co/t/lost-exception-traces/6274/3 "2012-01-03T21:43:01Z")
Yes, exactly. On Jan 3, 12:44 pm, Shay Banon [kim...@gmail.com](mailto:kim...@gmail.com) 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](mailto: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) > > > -Lorrin ---
**Author:** ![kimchy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/kimchy/32/44952_2.png) [@kimchy](https://discuss.elastic.co/u/kimchy)\ **Post date:** [January 4, 2012, 11:08am UTC](https://discuss.elastic.co/t/lost-exception-traces/6274/4 "2012-01-04T11:08:27Z")
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](mailto:lhn@lorrin.org) wrote: > Yes, exactly. > > On Jan 3, 12:44 pm, Shay Banon [kim...@gmail.com](mailto:kim...@gmail.com) 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](mailto: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) > > > > > -Lorrin ---
**Author:** ![Lorrin\_Nelson](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/lorrin_nelson/32/3018_2.png) [@Lorrin\_Nelson](https://discuss.elastic.co/u/Lorrin_Nelson)\ **Post date:** [January 13, 2012, 5:25am UTC](https://discuss.elastic.co/t/lost-exception-traces/6274/5 "2012-01-13T05:25:54Z")
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\) 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? -Lorrin On 4 Jan., 03:08, Shay Banon [kim...@gmail.com](mailto:kim...@gmail.com) wrote: > 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](mailto:l...@lorrin.org) wrote: > > > Yes, exactly. > > > On Jan 3, 12:44 pm, Shay Banon [kim...@gmail.com](mailto:kim...@gmail.com) 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](mailto: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) > > > > > -Lorrin ---
**Author:** ![kimchy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/kimchy/32/44952_2.png) [@kimchy](https://discuss.elastic.co/u/kimchy)\ **Post date:** [January 13, 2012, 8:31am UTC](https://discuss.elastic.co/t/lost-exception-traces/6274/6 "2012-01-13T08:31:55Z")
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](mailto: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\) 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? > > -Lorrin > > On 4 Jan., 03:08, Shay Banon [kim...@gmail.com](mailto:kim...@gmail.com) wrote: > > > 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](mailto:l...@lorrin.org) wrote: > > > > > Yes, exactly. > > > > > On Jan 3, 12:44 pm, Shay Banon [kim...@gmail.com](mailto:kim...@gmail.com) 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](mailto: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) > > > > > > > -Lorrin ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 6, 2017, 3:42am UTC](https://discuss.elastic.co/t/lost-exception-traces/6274/7 "2017-07-06T03:42:51Z")