Vert.x Core 3.x Plugin

[BFergerson]

• Why submit this pull request?

• Bug fix

• New feature provided

• Improve performance

• Related issues: Support plugin for Vert.x #2341

---

New feature or improvement

Basic Vert.x Core 3.x support. This includes support for the event bus and HTTP clients and servers.

[wu-sheng]

I am flighting to SF today. 😄

[BFergerson]

@wu-sheng, luck you :P. That's okay though. I'm sure this isn't ready yet. I wanted to ask you if I was doing the EntrySpan/ExitSpan pattern correctly for the event bus.

Basically, when you send a message through the event bus it could be going to another computer or it could be going to a consumer on the same computer. So there is a chance that it could be a message which is sent on the same-thread, cross-thread, or cross-process. My question is:

• should I be detecting if the message was same-thread, cross-thread, or cross-process and build the appropriate span based on that?

Should I have logic like:

If it was sent cross-thread:
 - Ignore ContextCarrier and work with ContextSnapshot

If it was sent cross-process
 - Use ContextCarrier

Currently sending a message always creates an ExitSpan and sends the ContextCarrier and receiving a message always creates a EntrySpan using the ContextCarrier sent.

[coveralls]

Coverage decreased (-0.0007%) to 15.607% when pulling 3538534 on BFergerson:master into 11212c4 on apache:master.

[wu-sheng]

If it was sent cross-thread:
 - Ignore ContextCarrier and work with ContextSnapshot

If it was sent cross-process
 - Use ContextCarrier

This is ideal status, but the more complex scenario is for span. If you call exit span, then the target ip would be required, and shown in topology if no entry span created. Also I doubt you would know when to create exit span or local span for in-process.

Currently sending a message always creates an ExitSpan and sends the ContextCarrier and receiving a message always creates a EntrySpan using the ContextCarrier sent.

This could be an easier way. But I have a question, if you don't know whether this event goes out-of-process or not, how set you set peer?

[BFergerson]

@wu-sheng, why do you think it will be hard to tell whether or not to make an exit span vs a local span? I'm able to detect whether the message is going over the wire or being routed locally pretty easily. If it's going over the wire I use ContextCarrier and if it's not I use ContextSnapshot.

I'm a bit confused on how I should be handling the local routing scenario. For an example scenario, let's say I have a local message flow of: A -> B -> C (where A sends a message to B and so on) and that in turn triggers a response flow of: C -> B -> A (where C responds to B and so on).

In this scenario, do I create any entry or exit spans or are they all supposed to be local? Your question about what I set the peer to set me down this path. Technically there wouldn't be a peer here because it's just communicating with itself. So should I just be creating a local spans?

If the answer is yes, would the process be:

• create async local span when A calls B
• create local span when B receives message from A (call continued with A context)
• create async local span when B calls C
• create local span when C receives message from B (call continued with B context)
• close async local span when C responds to B
• close async local span when B responds to A

I think I've got the over the wire scenario covered. It's the simple:

• create exit span when sending messages
• create entry span when receiving messages

[wu-sheng]

I'm able to detect whether the message is going over the wire or being routed locally pretty easily

If you can detect that, so you should do as you described above.

Just remind

1. In real local, ContextSnapshot is required between AsyncA and ReceiverB
2. In over the wire scenario, you also need async span.

My original questions are mostly about when you can't know it is local or remote when span is created. But look like you know. So, you could ignore my questions.

[BFergerson]

@wu-sheng, I think from adding the witness class there should not be any problems with Vert.x 3.0.0 and 3.1.0. I've also updated the documentation to state that for the eventbus only 3.2+ is supported.

I've also split the integration tests so now it tests the web and eventbus separately. The integration tests for the web module are working for all versions in 3.x and eventbus is 3.2+, of course.

[SkyWalkingRobot]

Here is the test report and validate logs

[SkyWalkingRobot]

Here is the test report and validate logs

[SkyWalkingRobot]

Here is the test report and validate logs

[SkyWalkingRobot]

Here is the test report and validate logs

[wu-sheng]

@BFergerson The PR includes a comment issue, causing CI fails, please fix.

[SkyWalkingRobot]

Here is the test report and validate logs

[wu-sheng]

@ascrutae The test results are good enough. You could review codes.

[wu-sheng]

@BFergerson We finally made this through 28 days.