# Java agent warns of improper deactivation of span **URL:** \ **Category:** APM\ **Created:** [March 15, 2019, 12:31am UTC](https://discuss.elastic.co/t/java-agent-warns-of-improper-deactivation-of-span/172444 "2019-03-15T00:31:50Z")\ **Posts on this page:** 1\ **Showing post:** 4

**Author:** ![fredericogalvao](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/fredericogalvao/32/33093_2.png) [@fredericogalvao](https://discuss.elastic.co/u/fredericogalvao)\ **Post date:** [March 16, 2019, 1:59am UTC](https://discuss.elastic.co/t/java-agent-warns-of-improper-deactivation-of-span/172444/4 "2019-03-16T01:59:26Z")

Good(?) news: - Using `elastic.apm.disable_instrumentations=concurrent,executor` **partially fixes** the issue. Spans are not deactivated with delay anymore, the warning is gone, but I still have _some \_render\_ spans not being registered_. Maybe those two are different issues? - some _render_ spans are not being captured properly - `concurrent,executor` instrumentations are causing span references to be left around and manipulated on other threads/transactions Something else I noticed, is that everytime the issue (delayed deactivation) happened, the first part of the internal id (I can see it when I `.dump()` the span/transaction object in groovy): ```auto co.elastic.apm.api.SpanImpl@39eec638 span='SimpleGrailsController' 00-6e5df9c349ec25a7cb1f13e3f538def9-ca62deb08bf83a8a-01 ``` which in this example is `6e5df9c349ec25a7cb1f13e3f538def9` (and corresponds the `trace.id` on the raw doc on elastic) is **all zeroes** , like in: ```auto co.elastic.apm.api.SpanImpl@433b89cc span='' 00-00000000000000000000000000000000-f57c7c7a7f92ad90-00 ``` and the span name is always an empty string too. I can reproduce this specific pattern when I press F5 on the _front-end_ service twice (without waiting for the first one to finish). Whenever I do this, a **new issue** comes into play: pretty much all future transactions with the same name (or some other similar characteristics) will be stuck on this ghost transaction and won't appear on elastic/kibana at all (they seem to be arriving at the `apm-server` though, based on the logs, but it could be just metrics). ```auto /*around here I did a quick double-F5, and the second one got into ghost-mode*/ /*note that the transaction.id leaks from one to the other*/ [2019-03-15T21:29:59.856-0300] currentSpan=co.elastic.apm.api.SpanImpl@6d2c961d:: [2019-03-15T21:30:00.399-0300] currentSpan=co.elastic.apm.api.SpanImpl@2947804c:: /*each one of these logs is one F5 after it was triggered, 12/15 ghost ones with no trace.id, and a lot of duplicate/leaked transaction.ids */ [2019-03-15T21:30:04.004-0300] currentSpan=co.elastic.apm.api.SpanImpl@3de838ea:: [2019-03-15T21:30:09.480-0300] currentSpan=co.elastic.apm.api.SpanImpl@40555a5e:: [2019-03-15T21:30:13.715-0300] currentSpan=co.elastic.apm.api.SpanImpl@61417412:: [2019-03-15T21:30:16.085-0300] currentSpan=co.elastic.apm.api.SpanImpl@4a706651:: [2019-03-15T21:30:18.613-0300] currentSpan=co.elastic.apm.api.SpanImpl@2674300:: [2019-03-15T21:30:20.714-0300] currentSpan=co.elastic.apm.api.SpanImpl@3e84a30c:: [2019-03-15T21:30:22.301-0300] currentSpan=co.elastic.apm.api.SpanImpl@3fc080ca:: [2019-03-15T21:30:22.756-0300] currentSpan=co.elastic.apm.api.SpanImpl@36bb420b:: [2019-03-15T21:30:26.279-0300] currentSpan=co.elastic.apm.api.SpanImpl@60f0f959:: [2019-03-15T21:30:26.438-0300] currentSpan=co.elastic.apm.api.SpanImpl@5a777ed5:: [2019-03-15T21:30:26.641-0300] currentSpan=co.elastic.apm.api.SpanImpl@234c8568:: [2019-03-15T21:30:27.017-0300] currentSpan=co.elastic.apm.api.SpanImpl@126c400a:: [2019-03-15T21:30:27.108-0300] currentSpan=co.elastic.apm.api.SpanImpl@1761cba2:: [2019-03-15T21:32:15.840-0300] currentSpan=co.elastic.apm.api.SpanImpl@28d01e71:: [2019-03-15T21:34:24.377-0300] currentSpan=co.elastic.apm.api.SpanImpl@79dffda9:: ``` I have reproduced this behavior (ghost transactions stuck "forever") regardless of my custom Apache HTTP async, custom span creation or render instrumentation. Leaving only public-api and servlet-api (for the simplest shell of a transaction and custom spans) still gave me a messed up scenario from time to time. I tried setting up log\_level=TRACE and was able to see that a correct transaction has logs all over specifying when it starts/ends, but a ghost one doesn't (it only has span starts/ends). Please let me know if there's anything else I can provide to help understand (and hopefully fix) this. --- _[View the full topic](https://discuss.elastic.co/t/java-agent-warns-of-improper-deactivation-of-span/172444)._