Open lukiano opened 5 years ago
you are right we don't limit messaging to just "b3" single because some systems don't have the same constraints as JMS. However, it is a very good choice for reasons of overhead and also compatibility. The best approach is lenient parsing.. meaning on the way in, parse both formats the same as HTTP mentions.
IOTW, while we mention this was originally designed for JMS, this doesn't mean only JMS implementation of messaging. Probably we should rename some sections.. do you want to give a go at doing that?
cc @openzipkin/core
Just to mention, I am waiting for zipkin-go to merge single header to use it in aws sqs propagation.
søn. 14. apr. 2019, 02:09 skrev Adrian Cole notifications@github.com:
you are right we don't limit messaging to just "b3" single because some systems don't have the same constraints as JMS. However, it is a very good choice for reasons of overhead and also compatibility. The best approach is lenient parsing.. meaning on the way in, parse both formats the same as HTTP mentions.
IOTW, while we mention this was originally designed for JMS, this doesn't mean only JMS implementation of messaging. Probably we should rename some sections.. do you want to give a go at doing that?
cc @openzipkin/core https://github.com/orgs/openzipkin/teams/core
— You are receiving this because you are on a team that was mentioned. Reply to this email directly, view it on GitHub https://github.com/openzipkin/b3-propagation/issues/33#issuecomment-482902955, or mute the thread https://github.com/notifications/unsubscribe-auth/AC7sAv0sB4HSbg-oojxV1gBln8fbE_6Tks5vgnGdgaJpZM4cuVSI .
I know the x-b3-* headers are well defined for propagation through http, but what about propagation through message systems (for asynchronous producer / consumer spans)? I think that in jms they use a b3 single header format, but I can't tell if this is standardized or not.