In process propagation #20

jcchavezs · 2017-09-21T09:30:53Z

This is related to the in_process_propagation.

Ping @beberlei @felixfbecker @yurishkuro @tPl0ch

tedsuo · 2017-09-22T19:08:21Z

Any reason startActiveSpan can't be called startSpan, rather than deprecate the method?

jcchavezs · 2017-09-28T17:42:45Z

@tedsuo we are following other implementations like python

tedsuo · 2017-10-30T20:35:11Z

Fair enough. I'd prefer we hadn't called it StartActiveSpan there either, but perhaps that ship has sailed...

jcchavezs · 2017-10-30T21:10:43Z

Ping @jonahgeorge

jcchavezs · 2017-11-05T07:43:25Z

We have two options here:

We remove the startSpan method and notify all the implementors about this or
We keep the startSpan as deprecated.

Whatever we choose I believe we will be ready to release 1.0.0. Please react with 1️⃣ or 2️⃣ wether you prefer the first one or the second one. Otherwise drop a comment expressing your concerns.

Ping @tPl0ch @tedsuo @felixfbecker @beberlei @yurishkuro @lvht @jonahgeorge @reimertz

jcchavezs · 2017-11-05T07:47:47Z

1️⃣

taoso · 2017-11-05T09:09:14Z

@jcchavezs In my opinion, only startSpan is really needed.

taoso · 2017-11-05T09:10:53Z

I think we should only offer the most essential API. Less is more, and less is better.

The opentracing specific even does not define a trace-id!!! It only defined span, tag, context, and reference. It's enough. How to trace all spans with different references is all about implementation. So should our php interface.

taoso · 2017-11-07T03:32:41Z

@jcchavezs Any thing not specified in the OT spec should never be part of our opentracing-php API.

Thank you.

jonahgeorge · 2017-11-07T19:37:23Z

I would also prefer renaming startActiveSpan to startSpan rather than deprecating startSpan or removing it.

felixfbecker · 2017-11-07T22:00:04Z

I would like to keep a method for manual span creation around as a fallback to use in an environment that needs to rely on manual span propagation. For example, I currently use https://github.com/sabre-io/event as an event loop, which doesn't have hooks to make sure the active span is correctly set for each event loop tick / context. So I have to resort back to passing around the Span objects as parameters, which I have no problem with, so I don't see any harm in keeping this functionality.

beberlei

I like the changes so far, really looking forward for this pull request as it will make OT-PHP usable for many more automatically instrumented scenarios.

beberlei · 2017-11-08T09:12:59Z

src/OpenTracing/Tracer.php

@@ -14,6 +14,39 @@
 interface Tracer
 {
    /**
+     * @deprecated use either startActiveSpan or startManualSpan instead.


We are not yet 1.0, so I would just go and remove this instead of deprecating.

So you think we should use startActiveSpan or startSpan making the active condition by default @beberlei?

In my opinion it makes it consistent with other language APIs.

cc @felixfbecker

Nice. I just changed it.

beberlei · 2017-11-08T09:14:16Z

src/OpenTracing/ActiveSpanSource.php

+     * must not be changed (idempotency).
+     *
+     * Do not confuse it with the finish concept:
+     *  - $span->deactivate() the span is not active but still "running"


You mention Span#deactivate here but this method does not exist. Should it? I don't think so, the comment must probably be adjusted to:

- $tracer->getActiveSpanSource()->deactivate($span); the span is not active anymore but still "running"

Nice one. I just fixed it.

…cer.

taoso · 2017-11-05T09:01:01Z

src/OpenTracing/Tracer.php

@@ -25,7 +58,26 @@
     * @throws InvalidSpanOption for invalid option
     * @throws InvalidReferencesSet for invalid references set
     */
-    public function startSpan($operationName, $options = []);
+    public function startActiveSpan($operationName, $options = []);


What's the reference type between the new created active span and the current active span?

Ping @jcchavezs

When creating a new activeSpan it becomes automatically the child of the existing one: https://github.com/opentracing/opentracing-php/pull/45/files#diff-bd85a3792bd64b152939e0b1b78086e2R19

What about other span relations than child_of?

@felixfbecker that is what startManualSpan is for.

taoso · 2017-11-05T09:06:57Z

src/OpenTracing/Tracer.php

+    /**
+     * @return ActiveSpanSource
+     */
+    public function getActiveSpanSource();


The introduction of ActiveSpanSource is not bad. Because, I implemented the same function in my company's php framework yesterday.

However, the opentracing specification only defines the references. And how to trace the reference is all business of user.

taoso · 2017-11-05T09:18:42Z

src/OpenTracing/ActiveSpanSource.php

+/**
+ * Keeps track of the current active `Span`.
+ */
+interface ActiveSpanSource


If we shift the ActiveSpanSource interface, why not shift a ActiveSpanSource implementation?

In my opinion, the ActiveSpanSource is only like a container. And only one implementation is enough.

As I understand it this interface would be important to implement for event loops

@jcchavezs is that correct?

I simplified this piece in #45

taoso · 2017-11-16T01:34:03Z

I need to make a summary of my consideration. @beberlei @felixfbecker @yurishkuro @tPl0ch @jcchavezs @tedsuo @jonahgeorge

My Opinion

I think we should only offer the most essential API. Less is more, and less is better.
Any thing not specified in the OT spec should never be part of our opentracing-php API.

I have said these words again and again.

In my opinion, the job to maintain the reference between span should leave to the user, even not the OT vendor.

However, if we really like to shift this feature, there still some issue in this PR.

The current issues

`startSpan` API name

The current startSpan is the very startManualSpan. Why introduce another startManualSpan and rename the current startSpan to startActiveSpan?

I propose to introduce the startActiveSpan API only.

The finish behavior of the `finish` API of the active span

With the startActiveSpan API, we get a span that has a parent of the current span and then become the new current span. It sounds great. However, what will happen if we call the new generated span's finish method?

In my opinion, the tracer should finish the span normally, and restore the current span with the stoped span's parent span. But I can not see any requirements in the API's doc.

The `getActiveSpanSource` API

Why people use the startManualSpan API? I think they use the API because they have their own infrastructure to maintain the reference of there span. It seems no need to use the getActiveSpanSource API to get the shifted ActiveSpanSouce for them. If they can use our ActiveSpanSource, why not use the getActiveSpanSource directly?

So I propose leave the ActiveSpanSource for internal use only, and drop the getActiveSpanSource API. As a result, the ActiveSpanSource interface can be dropped as well.

The `getActiveSpan` API

Please offer more detail about the getActiveSpan API.

If user use the startActiveSpan API, the Tracer will trace span automatically. If they trace span themselves, the will use the startSpan(or your startManualSpan), and the getActiveSpan will return nothing.

I can not see any need to use this API.

taoso · 2017-11-16T01:43:59Z

@tedsuo we are following other implementations like python

@jcchavezs Please following the OT spec.

jcchavezs · 2017-11-16T11:16:04Z

Unfortunately the implementation details changed and the Python PR (which is the one I based this PR on) has been closed in favour of opentracing/opentracing-python#63.

I am closing this PR for now. I created an issue for this matter and I will open a new PR by this week.

beberlei · 2017-11-19T01:02:54Z

@jcchavezs the only thing that changed in the new python implementation is this weird with something as scope change, which PHP doesn't have in the language (blocks), so we should keep this PR.

jcchavezs · 2018-01-09T16:21:58Z

@lvht, thanks for the feedback. Please let's follow up further questions in #45

startSpan API name
The current startSpan is the very startManualSpan. Why introduce another startManualSpan and rename the current startSpan to startActiveSpan?
I propose to introduce the startActiveSpan API only.

In some cases you don't want to create a scope for in-process context propagation. For example in concurrency situations, after pcntl_fork you don't want to open a scope for internal spans created in both parent and child process.

The finish behavior of the finish API of the active span
With the startActiveSpan API, we get a span that has a parent of the current span and then become the new current span. It sounds great. However, what will happen if we call the new generated span's finish method?
In my opinion, the tracer should finish the span normally, and restore the current span with the stoped span's parent span. But I can not see any requirements in the API's doc.

This is a valid concern an a good question. We discussed this a long time ago and we decided to decouple the behaviour, that is why we added this note: https://github.com/opentracing/opentracing-php/pull/45/files#diff-e01221a8e1fafbccea47b6bc2f5f9f28R33

The getActiveSpanSource API
Why people use the startManualSpan API? I think they use the API because they have their own infrastructure to maintain the reference of there span. It seems no need to use the getActiveSpanSource API to get the shifted ActiveSpanSouce for them. If they can use our ActiveSpanSource, why not use the getActiveSpanSource directly?
So I propose leave the ActiveSpanSource for internal use only, and drop the getActiveSpanSource API. As a result, the ActiveSpanSource interface can be dropped as well.

I did a change in this direction. To be honest having the scope control inside the tracer make things more understandable. I had the opportunity to try the separated objects approach and it was quite inconvinient.

The getActiveSpan API
Please offer more detail about the getActiveSpan API.
If user use the startActiveSpan API, the Tracer will trace span automatically. If they trace span themselves, the will use the startSpan(or your startManualSpan), and the getActiveSpan will return nothing.
I can not see any need to use this API.

You might want to add specific tags or logs to the current span and that is not possible without accessing the currentSpan.

beberlei · 2018-02-02T12:54:38Z

README.md

@@ -42,7 +42,7 @@ The simplest starting point is to set the global tracer. As early as possible, d

 ### Creating a Span given an existing Request

-To start a new `Span`, you can use the `StartSpanFromContext` method.
+To start a new `Span`, you can use the `startActiveSpan` method.


You name it startActiveSpan here and then the example uses startManualSpan though. Is this right?

beberlei · 2018-02-02T12:57:03Z

src/OpenTracing/Tracer.php

@@ -25,7 +58,26 @@
     * @throws InvalidSpanOption for invalid option
     * @throws InvalidReferencesSet for invalid references set
     */
-    public function startSpan($operationName, $options = []);
+    public function startActiveSpan($operationName, $options = []);


@felixfbecker that is what startManualSpan is for.

beberlei · 2018-02-02T12:58:15Z

src/OpenTracing/Tracer.php

-     * or use the call to fastcgi_finish_request in order to not to delay the end
-     * of the request to the client.
+     * As an implementor, a good idea would be to use register_shutdown_function
+     * or fastcgi_finish_request in order to not to delay the end of the request to the client.


This is not an "or" imho, since you can use both. register_shutdown_function is still waiting to finish the communication with the Webserver if you don't use fastcgi_finish_request.

jcchavezs · 2018-02-06T11:28:59Z

Closing in favor of #47

jcchavezs force-pushed the in_process_propagation branch from 4e58204 to a0e7d6d Compare September 23, 2017 15:29

jcchavezs force-pushed the in_process_propagation branch from a0e7d6d to 2dd6fda Compare November 5, 2017 07:38

jcchavezs mentioned this pull request Nov 5, 2017

Do we really need the Carriers? #31

Closed

jcchavezs added this to the 1.0.0 milestone Nov 5, 2017

opentracing deleted a comment from taoso Nov 5, 2017

beberlei suggested changes Nov 8, 2017

View reviewed changes

Adds activeSpanSource interface and include it as a dependency on tra…

0879abd

…cer.

jcchavezs force-pushed the in_process_propagation branch from 2dd6fda to 0879abd Compare November 12, 2017 12:21

taoso reviewed Nov 15, 2017

View reviewed changes

jcchavezs closed this Nov 16, 2017

jcchavezs reopened this Dec 8, 2017

jcchavezs mentioned this pull request Jan 9, 2018

[#43] Adds in process context propagation. #45

Closed

1 task

beberlei suggested changes Feb 2, 2018

View reviewed changes

jcchavezs closed this Feb 6, 2018

In process propagation #20

In process propagation #20

Conversation

jcchavezs commented Sep 21, 2017

tedsuo commented Sep 22, 2017

jcchavezs commented Sep 28, 2017

tedsuo commented Oct 30, 2017

jcchavezs commented Oct 30, 2017

jcchavezs commented Nov 5, 2017

jcchavezs commented Nov 5, 2017

taoso commented Nov 5, 2017

taoso commented Nov 5, 2017 • edited Loading

taoso commented Nov 7, 2017

jonahgeorge commented Nov 7, 2017 • edited Loading

felixfbecker commented Nov 7, 2017

beberlei left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jcchavezs Nov 8, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

taoso commented Nov 16, 2017 • edited Loading

My Opinion

The current issues

startSpan API name

The finish behavior of the finish API of the active span

The getActiveSpanSource API

The getActiveSpan API

taoso commented Nov 16, 2017 • edited Loading

jcchavezs commented Nov 16, 2017

beberlei commented Nov 19, 2017

jcchavezs commented Jan 9, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jcchavezs commented Feb 6, 2018

taoso commented Nov 5, 2017 •

edited

Loading

jonahgeorge commented Nov 7, 2017 •

edited

Loading

jcchavezs Nov 8, 2017 •

edited

Loading

taoso commented Nov 16, 2017 •

edited

Loading

`startSpan` API name

The finish behavior of the `finish` API of the active span

The `getActiveSpanSource` API

The `getActiveSpan` API

taoso commented Nov 16, 2017 •

edited

Loading

jcchavezs commented Jan 9, 2018 •

edited

Loading