* add deprecation warning when tracer plugins are loaded
* add response format attribute to span in gateway handler
* add note about tracing's experimental status in godoc
* add nil check for TTL when adding name span attrs
* add basic sharness test for integration with otel collector
* add nil check in UnixFSAPI.processLink
* test: sharness check all json objs for swarm span
* add env var docs to docs/environment-variables.md
* chore: pin the otel collector version
* add tracing spans per response type (#8841)
* docs: tracing with jaeger-ui
Co-authored-by: Marcin Rataj <lidel@lidel.org>
This doesn't _stop_ us from cutting these connections but indicates that there's
some hidden usefulness to them.
fixes#6164
License: MIT
Signed-off-by: Steven Allen <steven@stebalien.com>
Most of these are probably harmless but a few looked like they might actually be
bugs. Most of them are just faulty tests.
License: MIT
Signed-off-by: Steven Allen <steven@stebalien.com>
Switch _back_ to the 0.4.18 style of peer IDs while we figure things out. See
https://github.com/libp2p/specs/issues/138.
License: MIT
Signed-off-by: Steven Allen <steven@stebalien.com>
Turns out that `pool.Put(buf)` had to *allocate* because we needed to turn
`[]byte` into `interface{}`. Apparently, we've never done this correctly we just
never noticed because we never really used buffer pools extensively.
However, since migrating yamux to a buffer-pool backed buffer, this started
showing up in allocation profiles.
License: MIT
Signed-off-by: Steven Allen <steven@stebalien.com>
* go-datastore and friends: GetSize
* badger: new release, fewer allocations
* go-mplex: send fewer packets
* go-bitswap: pack multiple blocks in a single message, fewer allocations
* go-buffer-pool: replace the buffer pool from go-msgio
* yamux: fixed data race and uses go-buffer-pool for stream read-buffers to
reduce memory and allocations.
* go-libp2p-secio: get rid of a hot-spot allocation
* go-libp2p-peerstore: reduced allocations (at the cost of some memory)
More?
License: MIT
Signed-off-by: Steven Allen <steven@stebalien.com>