Hazelcast Instrumentation
99 views
Skip to first unread message
Daryl Robbins
Apr 27, 2021, 5:01:04 PM4/27/21
to Hazelcast
Greetings all,
The one thing I wasn't able to support was the propagation of context information between nodes to follow through a full requests (i.e from the message producer to consumer for a queue).
Datadog uses the Opentracing API for this, which supports injection as binary or via a map (i.e. a set of header properties). Looking at the ClientMessage, the format seems to be pretty rigid without any additional slots to inject this kind of context right now.
It would be way too invasive to try and wrap the message payload since that would break any node not running the agent. I know there is a correlationId field but Datadog needs to be able to inject their own internal ID's to trace the request.
Is there a way to do this that I'm missing or is there a possibility of an enhancement in the future to support?
Thanks very much,
Daryl
M. Sancar Koyunlu
Apr 28, 2021, 3:06:14 AM4/28/21
to Hazelcast
Hi Daryl, Thanks for the great contribution.
ClientMessage has unused bits which is guaranteed to be not read by any existing members/clients. These are left for any future extension.
Let me try to give some initial guidelines. Adding this much logic via agents could be troublesome. I can try to help you on the client protocol side as much as I can, if you feel up to it.
Some initial pointers for client message extension:
Class Level ClientMessage Javadoc could be a good start to see which bits that you can reuse. Look for `flags` to find unused/reserved bits to set a custom flag.
Note that 3.x and 4.x client protocol is completely different. You are going to need to have two implementations for this part as well.
You may achieve adding extra information by setting an unused flag and adding extra information to the message end. The reader will read the extra information only when the flag is set.
Since it is guaranteed that any standard hazelcast distribution will never set that flag(at least released ones so far), they will work out-of-the box with even modified messages. They will just ignore the bytes appended at the end.
In 3.x series, you will need to modify ClientMessage.writeTo/readFrom methods.
In 4.x series, you can modify ClientMessageReader and ClientMessageWriter for the same purpose.
Good luck for now. I will try to answer any further questions of yours.
ClientMessage has unused bits which is guaranteed to be not read by any existing members/clients. These are left for any future extension.
Let me try to give some initial guidelines. Adding this much logic via agents could be troublesome. I can try to help you on the client protocol side as much as I can, if you feel up to it.
Some initial pointers for client message extension:
Class Level ClientMessage Javadoc could be a good start to see which bits that you can reuse. Look for `flags` to find unused/reserved bits to set a custom flag.
Note that 3.x and 4.x client protocol is completely different. You are going to need to have two implementations for this part as well.
You may achieve adding extra information by setting an unused flag and adding extra information to the message end. The reader will read the extra information only when the flag is set.
Since it is guaranteed that any standard hazelcast distribution will never set that flag(at least released ones so far), they will work out-of-the box with even modified messages. They will just ignore the bytes appended at the end.
In 3.x series, you will need to modify ClientMessage.writeTo/readFrom methods.
In 4.x series, you can modify ClientMessageReader and ClientMessageWriter for the same purpose.
Good luck for now. I will try to answer any further questions of yours.
--
You received this message because you are subscribed to the Google Groups "Hazelcast" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hazelcast+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hazelcast/e5ce92f1-be81-46f7-8c95-fb6e77ff5582n%40googlegroups.com.
|
This message contains confidential information and is intended only for the individuals named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required, please request a hard-copy version. -Hazelcast
Reply all
Reply to author
Forward
0 new messages