Skip to content
This repository was archived by the owner on Aug 30, 2022. It is now read-only.

Add an HTTP Sender (#165) #171

Merged
merged 3 commits into from
Sep 29, 2019
Merged

Conversation

mdouaihy
Copy link
Contributor

Support an HTTP Sender that allows to connect directly to a Collector.
For instance, authentication is not supported.

Signed-off-by: FR-MUREX-COM\mchaikhadouaihy mehrez.douaihy@gmail.com

Which problem is this PR solving?

  • Missing HTTP sender to connect directly to the jaeger collector

Short description of the changes

  • Add the HTTP sender
  • refactor UDPTransport to ThriftTransport
  • refactor UDPClient to UDPSender

@AppVeyorBot
Copy link

@mdouaihy
Copy link
Contributor Author

@yurishkuro

Copy link
Member

@yurishkuro yurishkuro left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.


} // anonymous namespace

ThriftTransport::ThriftTransport(const net::IPAddress& ip,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure about this renaming. Thrift is an encoding, not a transport. UDP vs. HTTP are the transports (although we call the "senders").

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree, Thrift is just the encoding.

Knowing that it creates a thrift::Batch from a span and sends it to a sender to be sent. What do you suggest as naming? ThriftSender?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I renamed it to ThriftSender because it takes and Span and transform it to ThriftSpan and flush it via a UDP/Http sender.

What do you think?

{
}

ThriftTransport::ThriftTransport(const net::URI& endpoint,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks like an unnecessary abstraction leak of the sender implementation into this class. Why not just accept sender as a ctor argument?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed. You're right. The config will now build the actual sender and pass it as argument to the ctor.

uint8_t* data = nullptr;
uint32_t size = 0;
_buffer->getBuffer(&data, &size);
if (static_cast<int>(size) > _maxPacketSize) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

a) how is _maxPacketSize defined for HTTP?
b) does it matter if it's exceeded?

Also, I haven't looked into Sender implementation here, but in other clients (e.g. Go), senders simply don't reach the state where a buffer is overflowed and spans must be dropped, because sender would flush previous spans if append(span) exceeds msg size. But again, this only makes sense for UDP because of fragmentation, it's not very relevant to HTTP (i.e. +/- extra span, who cares)

Copy link
Contributor Author

@mdouaihy mdouaihy Sep 14, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed, this should not happen.

As for the max value, it's the same as the Java implementation.

This limit is now used only to know when to flush.

@AppVeyorBot
Copy link

@mdouaihy
Copy link
Contributor Author

Integration test added.

@AppVeyorBot
Copy link

@@ -14,4 +14,4 @@
* limitations under the License.
*/

#include "jaegertracing/Transport.h"
#include "jaegertracing/Sender.h"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what's the purpose of this Transport.cpp?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, this file was not renamed automatically when I renamed the class. should be fixed.

@AppVeyorBot
Copy link

@AppVeyorBot
Copy link

@mdouaihy
Copy link
Contributor Author

@yurishkuro. any additional remarks on this PR?

@yurishkuro
Copy link
Member

@mdouaihy could you resolve the conflicts / merge master?

Support an HTTP Sender that allows to connect directly to a Collector.
For instance, authentication is not supported.

Signed-off-by: FR-MUREX-COM\mchaikhadouaihy <mehrez.douaihy@gmail.com>
* Rename ThriftTransporter to ThriftSender
* Add Integration Test for http

Signed-off-by: FR-MUREX-COM\mchaikhadouaihy <mehrez.douaihy@gmail.com>
Signed-off-by: FR-MUREX-COM\mchaikhadouaihy <mehrez.douaihy@gmail.com>
@AppVeyorBot
Copy link

@mdouaihy
Copy link
Contributor Author

Hi @yurishkuro, I rebased the PR to the latest commit.

@mdouaihy
Copy link
Contributor Author

hi @yurishkuro, anything missing to merge this PR?

@yurishkuro yurishkuro merged commit 4ee8a66 into jaegertracing:master Sep 29, 2019
@yurishkuro
Copy link
Member

@mdouaihy the readme only seems to mention a file-based configuration. Does this support env var configuration like JAEGER_ENDPOINT, per https://www.jaegertracing.io/docs/1.14/client-features/ ?

@mdouaihy
Copy link
Contributor Author

@yurishkuro, this implementation does not support configuration via the env variable, neither for the agent nor for the collector.

We can work on supporting that if you think it's important.

@mdouaihy mdouaihy deleted the httpsender branch September 29, 2019 19:07
@yurishkuro
Copy link
Member

Not sure how critical it is if nobody asked so far. I booked a ticket anyway: #178

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants