Comments (8)
I wrote some docs on it, and some patches, but they aren't merged and I can't maintain them if they won't be merged upstream. The case for merging them is weakened by the fact that:
- There's an Apache Thrift bug that means jaeger-cpp needs a specific Thrift version and a patch on top of the generated code (#45 and https://issues.apache.org/jira/browse/THRIFT-4484), so in practice you need your own Thrift
- It needs a quite new nlohmann-json that nothing packages, so it has to be bundled via git submodule + "make dist" sources or similar
- Same for gtest
so it's not worth it.
Instead you might want to look at using the opentracing-c++ API and its dynamic loading support, then load a jaeger-cpp that's been compiled to statically link the needed libs, so it's just a simple .so . So long as the C++ ABI is compatible you will be fine. It's totally unacceptable for distribution packaging, and really bad for continuous integration workflows, reproducible builds, etc, but it'll likely meet your needs.
When I get the chance to resume this, I'll be adding a C-adapter over the opentracing c++ API, and using its dynloader. But I'm waiting on a patch for opentracing c++ API to make span contexts copyable; see opentracing/opentracing-cpp#74 . And I have no time presently due to Other Work Stuff.
So I don't plan on working further on making jaeger-cpp offline-buildable, reproducible-buildable, or able to use distro dependencies. Someone else can if they want, but I don't think it's viable unless the Thrift bug is fixed at least. (Even if you changed Jaeger to apply a patch on top of the generated output, the patch has to differ depending on the underlying Thrift version, so you don't gain much).
This isn't any complaint at @isaachier btw, they've been super helpful and given their time on things that aren't really their own priorities to help me out. Including even working on a c-client. It's just how it is. I don't see any good answers without major changes including to Jaeger IDL etc.
I haven't closed the issue, but it might as well be.
from jaeger-client-cpp.
Sorry about this. I agree overall I need to beef up the docs here (see #33). Do you have an issue using Hunter or you just want to avoid a tool that isn't used in Postgres?
from jaeger-client-cpp.
I can't use Hunter.
If I even try to suggest adding support for downloading random things off the Internet in the PostgreSQL build system I'll be run out of town. There's increasing work being done for reproducible builds, and offline builds are a hard non-negotiable requirement for many if not most PostgreSQL users and deployments. Package builders would have a heart attack; you're not likely to see the Jaeger cpp agent landing up in Fedora, Debian/Ubuntu, etc without an offline build that can use locally installed dependencies.
Not to mention that it's autotools based still (alas), which probably makes using Hunter "fun" even if it were an option.
I'm trying to do what I can with limited time because I'm really excited by what opentracing and jeager looks like it can offer. But I bet the great majority would've already gone "too hard basket". Maybe I'm just a reactionary old fogie, though, after all I work with a community that still requires Perl 5.8.8 support in its test harness 🤮.
I wrote you a draft README anyway, to try to record what I've figured out so far or had pointed out to me on the chat channel. You'll see it on #33.
The above separate commit ringerc@f6ebf97 adds support for local package finding using typical CMake find package modules. It's not quite there yet:
- It's trying to link to
thrift::thrift_static
despite:
if(HUNTER_ENABLED)
list(APPEND LIBS thrift::thrift_static)
else()
list(APPEND LIBS ${THRIFT_LIBRARIES})
endif()
and the fact that cmake/Findthrift.cmake
just does FIND_LIBRARY(THRIFT_LIBRARIES thrift)
. Where's thrift_static
coming from?
- jaeger-cpp seems to fail to compile against nlohmann json 2.0.x but that's the only one packaged pretty much anywhere. Fedora 27 has 2.0.2. Debian Stretch has 2.0.6. Debian unstable has 2.1.x but Fedora Rawhide seems to have 2.0.5. Fixing this is beyond my c++-foo. I expect I'll just do a manual install of a newer build from source, but that's another barrier for a user to cross before they get to the good stuff, so....
Haven't sent you a PR due to the above.
from jaeger-client-cpp.
@isaachier Forgot to @ mention you, see above
from jaeger-client-cpp.
Figured out what was wrong with the test builds, fixed.
Now having difficulty because the source tree seems to contain generated files from Apache Thrift. But:
-
Thrift expects/advises that you use a matching Thrift compiler and Thrift library version, and jaeger-cpp does nothing to ensure that's the case; and
-
There doesn't seem to be any tooling in the cmake build to regenerate them. I don't see where they came from in the sources, for that matter; can they be regenerated?
Without that I don't see how I can compile it.
The specific error is:
/home/craig/projects/2Q/opentracing-jaeger-cpp-client/src/jaegertracing/thrift-gen/Agent.cpp: In member function ‘uint32_t jaegertracing::agent::thrift::Agent_emitZipkinBatch_args::write(apache::thrift::protocol::TProtocol*) const’:
/home/craig/projects/2Q/opentracing-jaeger-cpp-client/src/jaegertracing/thrift-gen/Agent.cpp:70:10: error: ‘class apache::thrift::protocol::TProtocol’ has no member named ‘incrementRecursionDepth’
oprot->incrementRecursionDepth();
^~~~~~~~~~~~~~~~~~~~~~~
/home/craig/projects/2Q/opentracing-jaeger-cpp-client/src/jaegertracing/thrift-gen/Agent.cpp:87:10: error: ‘class apache::thrift::protocol::TProtocol’ has no member named ‘decrementRecursionDepth’
oprot->decrementRecursionDepth();
^~~~~~~~~~~~~~~~~~~~~~~
and it's because my local Thrift is 0.9.1, but the Jaeger files were generated with 0.9.2.
Where are the inputs for the Thrift generator?
from jaeger-client-cpp.
I can help with the non-Hunter build. Sorry you are having so many issues with that.
from jaeger-client-cpp.
I'm looking into building the jaeger-client-cpp in an air gap system, do you have some documentation around this point? are you planning on merging your fork into upstream? I can try to vendor Hunter dependencies, but not really elegant.
from jaeger-client-cpp.
I do owe this repo more documentation, although I have plans for an overhaul of this project soon. As of now, there are no plans to merge @ringerc's work upstream (it would be outdated by now anyway). He has helped me recognize this issue, and I appreciate the effort, but it won't be possible right now.
Regarding your issues building, I believe this is better addressed in the Hunter documentation. Look at the HUNTER_ENABLED
variable and the git submodule solution described. Hopefully, that will help you build with your set-up. For questions about Hunter, you can also visit the Hunter chat on https://gitter.im.
Sorry about the lack of documentation and I hope this helps you.
from jaeger-client-cpp.
Related Issues (20)
- Provide access to context HTTP Header name
- Jaeger 32 bit C/C++ client required
- QUESTION: Can not use with hunter manager
- how to release version to real scene
- Unit test: Socket.testFailBind fails when run as "root" HOT 6
- Can we please ditch hunter HOT 1
- Enable ppc64le arch for jaeger-client-cpp
- Unable to build windows in a pipeline.
- Add support for adding tracer tags via config yaml HOT 1
- My jaeger version is 1.23, and the jaeger-collector component has enabled --sampling.strategies-reload-interval, but the collected logs show that the sampling strategy is still old HOT 4
- Envoy - failed to load dynamic library opentracing versions are incomptable
- `RemoteReporter::report()` is blocked
- Default queue size & buffer flush interval are not used when reading configuration from YAML
- Issue facing while trying to build jaeger-client-cpp
- Compilation issue on Ubuntu 20.04 HOT 2
- When the sampling type is rate, the number of actual results is equal to the number of threads multiplied by the configured rate parameter
- warning const' was hidden [-Woverloaded-virtual] when using jaeger client with opentracing libraries
- Enablement TravisCI integration for IBM ppc64le architecture HOT 1
- Deprecate Jaeger C++ SDK HOT 3
- [Bug]: W3C Propagation is wrongfully encoding debug span flag into traceparent HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from jaeger-client-cpp.