concurrent 'schedule' rules cause incorrect span relationships

[randallt]

I just debugged an issue that ended up being caused by one of the 'schedule' rules found in the concurrent package.

In this particular case, we have a server serving requests. The first request starts a job that renews an authorization session every five minutes. Spans from this scheduled job should NOT have the span that was active at the time these jobs were scheduled to be their parent span FOREVER going forward. These jobs should just be independent spans (no parent).

Is there a specific use case where a repeating scheduled job should retain a parent span for each of its executions? If not, I would argue to just remove these 'schedule' rules in the concurrent package. Or at least provide some easy mechanism to disable them (or to enable them if you decide to disable them by default).

I lost almost a whole day trying to figure out how I had a dangling scope/span that was getting picked up by something else.

[randallt]

To be clear, I meant to disable the ones that schedule a periodic execution:

• io.opentracing.contrib.specialagent.concurrent.FixedDelayAgentRule
• io.opentracing.contrib.specialagent.concurrent.FixedRateAgentRule

[safris]

Hi @randallt, this is a great use-case! I agree that the Concurrent Plugin needs to be corrected to accommodate your use-case. I have implemented a new pattern that will allow you to disable individual AgentRules.

[safris]

Hi @randallt, I'm reviewing this issue again, and wanted to know if you were able to use the aforementioned pattern to work around your issue. Also, if you could, please file an issue with the java-concurrent plugin, as the behavior you've identified as problematic belongs to the plugin and not to SpecialAgent.

[randallt]

Hi. No, I did not try the exclusion pattern mentioned above. I have opened

opentracing-contrib/java-concurrent#17