Support nlohmann json 2.0.x?

[jaegertracing]

Support nlohmann json 2.0.x?

[isaachier]

Interesting. I'm strongly considering another approach for you instead of using system-wide packages. The few I can think of are: wget/curl from archives and submodules. Any reason not to do that instead?

[ringerc]

On 29 January 2018 at 02:49, isaachier ***@***.***> wrote: Interesting. I'm strongly considering another approach for you instead of using system-wide packages. The few I can think of are: wget/curl from archives and submodules. Any reason not to do that instead?

Packaging support. Reproducibility. Offline builds. Inclusion in Linux distros. Stability and predictability. Verifiability - downloading things means needing a mechanism for validating that they're untampered with, signature checks, etc. Many (most) users of PostgreSQL want rpms/debs that've been through a QA and release process. The PostgreSQL community definitely will not accept anything that depends on stuff that's so bleeding edge it isn't even on widespread Linuxes either. I'd be surprised if other open source DBMSes like MySQL weren't similar in terms of dependencies policies etc. This looks like a big mismatch of approaches. Presumably jaeger cpp-client is for fast-moving containerized environments that are highly dynamic and fetch everything from the 'net. No release processes, etc; grab it from the 'net, try it, seal it and deploy it if it works. That's cool if you're in the right sort of environment but it's a big problem for things like DBMS deployments. At linux.conf.au I asked a question in one of the container talks about how they deal with databases and other data-persistent stateful services. The answer: oh, we run those outside our container infrastructure, stateful services are still an evolving thing in the container world. I guess it's a question of what the goal of jaeger cpp-client is, the target audience. Right now I'd argue that its audience is limited to: - C++11 - Uses containers for everything, minimal local packages etc - Happy to adopt Hunter in all their applications (and their build systems can support that) - Doesn't have to deal with legal and regulatory policies that impose processes on releases, software sourcing etc Now, I want to make request lifecycles traceable throughout. From the edge through caches, proxies, DBMS, etc and back out again. But that means the build/packaging/deployment model must be able to support the inner ring services that are slower moving, more conservative, more stable. I can work around most of the current dependency issues. But I think I'd need to know that there was willingness to maintain more conservative dependencies, at least in terms of not adopting the latest version of everything as soon as it comes out and keeping in mind what's out there in the wild. Otherwise I'll be constantly chasing something I can never reach, and am better off finding a more stability oriented tool. Or writing a C driver. So what's your target audience?

…

-- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services

[isaachier]

To be honest, the only reason I developed this library the current way is to allow for rapid development. Using apt-get makes it very difficult to port to Mac, etc. Hunter produces the same build on all supported platforms. So I'm definitely interested in enlarging the scope of Jaeger C++ to allow for deb/rpm. However, I would like to keep Hunter as default because it makes building so much easier for the casual developer.

Meanwhile, the idea of Jaeger C++ being a library/platform level library does bother me. Especially, considering the use of C++11 in C executables, which no one loves. If we really want a lowest common denominator utility, we should push forward the idea of opentracing-c and follow up with jaeger-c. That library would be painful to develop, but probably much easier to link in with the classic C/C++ development environment, and have much less bloat.

My final point, think of Jaeger C++ as a project with a lot of room for improvement. The basic proof of concept is here and it works in production, but compatibility could be extended to other platforms and build systems. I am totally open to hearing about features you'd like, and better yet, seeing pull requests with initial implementations.

[ringerc]

Certainly no complaint about Hunter as default. I can see how it's handy for development, for container based work, etc. Though it'd be much, much more useful if you could do something like

 cmake -DCMAKE_INSTALL_PREFIX=/opt/jaeger-cpp -DHUNTER_ENABLED=1 -DHUNTER_INSTALL_DEPENDENCIES=1
 make
 make install

and get everything Hunter built as well as jaeger-cpp its self. So you can use it from other apps that may in turn not be able to use Hunter. Or where the user doesn't have the time/knowledge to convert the app's build system to use Hunter and just wants to use jaeger-cpp. Big barrier to entry there. (That's what I was getting at with #44)

I don't have a huge problem with thunking C++11 into C. It's awkward and annoying, but less so than writing a whole new library and API. Sure, if it massively takes off, that might make sense, but for now just making the C++ lib play a bit better with local installs (and documenting it) would be enough IMO. That's what I've been trying to do here, but am running out of time. I can keep working on it if you're OK with committing to maintaining a degree of lib version compatibility going forward, but otherwise need to drop it here.

Definitely no time to write a pure C client.

Working on it re doing the work and actually sending pulls. I'm trying to help not just complain. Lots to learn and figure out as I go given I've never met this Hunter tool before - a sort of Maven for C. And that jaeger-cpp hasn't had to care about dependency versions or compatibility so there are lots of unknowns there.

[isaachier]

I am willing to agree to that. Good work so far!

[isaachier]

@ringerc you've inspired me to begin a minimal client in C. This is a side project so can't guarantee anything about if/when it will be completed. Nonetheless, this might be more along the lines of what you wanted: jaeger-c-client.

[ringerc]

@isaachier Cool. I wasn't asking you to, and I've been trying to do what I can to help make the C++ one usable from C. IMO it's OK enough, the problems are related to builds and library management more than language. Thunking from C++ to C is ugly but manageable.

[ringerc]

The bigger problem has been Hunter, specific Thrift and json library dependencies not widely packaged, etc.

Sure, some folks will whine about C++, and I won't pretend it's a joy to work with in a C project, but that's not where the main challenges have been.

[isaachier]

I find C makes tends to be better as a base layer especially when considering language bindings. C99 compiles pretty much anywhere unlike C++11. The C library is more of a challenge for me to implement a bare bones client with as few dependencies as possible.

[ringerc]

@isaachier So long as you're happy :)

I imagine it'd do good things for adoption if it's easy to plug in, mind.

Here are some things I'd be considering, if I were the one doing the work. But since I'm not putting my hand up for that part, feel free to ignore everything I say! I have my hands full trying to get the C++ lib usable for my needs and getting some mergable pulls together for you.

Anyway, considerations in a C infrastructure lib:

• exposing jaeger_malloc() and jaeger_free(...) wrappers for malloc() and free(). Memory allocated in the client to be freed by jaeger should be allocated with jaeger_malloc(); memory allocated by jaeger to be freed by the client should be freed with jaeger_free(). This ensures you can ensure you use the same C library to free memory returned by jaeger c-client as was used to allocate it. Important for Windows. Standard pattern for C libraries.

• Allocator wrappers should be function pointers so applications can replace the allocator used by jaeger-cpp.

• Minimising allocations by letting the client pass pointers to pre-allocated, possibly on-stack, memory where possible. Lets client apps manage memory lifetimes if they have their own allocators (e.g. PostgreSQL palloc/MemoryContextAlloc, Samba's talloc, etc. And lets client apps integrate their own memory statistics.

• Low cost of trace before the "should I send this" decision is made so hot paths can be traced. Preferably avoiding heap allocations before sampler/filter decisions are made.

• Shameless use of static inline functions and macros to minimise overheads. (This is one area C++ rocks, I miss inline template functions so much when I write C).

• Doesn't call abort(). Ever.

[isaachier]

If you check out the repo, the alloc.h header allows you to replace the Jaeger allocator. Before joining Uber, used to work at Bloomberg where they rewrote the STL with custom allocators, so I understand the importance of that. Otherwise, all sound like good suggestions I will use going forward.

[ringerc]

Thanks.

Closing this issue. I've had a look at the changelog between 2.0.2 and 2.1.0 in nlohmann json and it's huge. I have no chance of figuring out what's needed to make jaeger cpp-client work with 2.0.2. There are changes to assignment operators and conversion support, tons of things.

I suggest documenting a current required version and sticking to it for a while; the world will catch up. And it's a header-only library so the usual issues with packaging aren't such a concern.

[ringerc]

BTW, rewrote the STL o_O ? Seems an odd choice given std::allocator and the way the templates all take allocator arguments. Presumably issues with the pre-c++11 requirement that custom allocators must be stateless.

But gee. I thought PostgreSQL liked wheel reinvention. That's a new level.

[isaachier]

Agreed about the plan for libs and will document eventually :/.

BSL is a big debate there. Now that you mention it, who do you think was behind that C++11 change to the standard? Bloomberg engineers wrote the proposal: http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2008/n2554.pdf. Anyway, I didn't use any scoped allocators in the Jaeger code so no issue here.