Hi. I do not have a very clear idea of what the appropriate level to implement this suggestion on would be yet, but I'm open to suggestions. Here's the gist.
Running an application that produces and consumes a lot of amqp traffic, I'd like to have some idea of the traffic it is using. Not sure if it'd be best to solve on the messaging or the transport layers. I suppose in other client libraries that come to mind (net/http, grpc-go) this sort of feature is usually done with some sort of middleware handler.
At the messaging layer, the Sender and Receiver interfaces hide the actual link message buffers and the marshaling/unmarshaling to an amqp.Message. This makes it difficult for users to get a general idea of the volume traffic their application is producing/consuming (especially when heavily using the amqp-value as opposed to just amqp data.) i.e. can't really sizeof(*amqp.Message) very effectively, and that may not totally correspond to what is going over the wire too directly. At present the best option to get that information is probably, running a redundant Message.UnmarshalBinary() to get the raw buffer and get its size.
Alternatively, maybe it is more idiomatic to instead focus on transport level traffic. A little ugly but if the amqp.ConnOptions included an option to provide a Dialer interface, folks could provide a wrapped net.Conn that could let them observe the whole of protocol traffic rather than figuring out an external proxy to point at.
Appreciate your thoughts! If there were consensus that there were a worth while solution here I'd be glad to contribute.
Hi. I do not have a very clear idea of what the appropriate level to implement this suggestion on would be yet, but I'm open to suggestions. Here's the gist.
Running an application that produces and consumes a lot of amqp traffic, I'd like to have some idea of the traffic it is using. Not sure if it'd be best to solve on the messaging or the transport layers. I suppose in other client libraries that come to mind (net/http, grpc-go) this sort of feature is usually done with some sort of middleware handler.
At the messaging layer, the Sender and Receiver interfaces hide the actual link message buffers and the marshaling/unmarshaling to an amqp.Message. This makes it difficult for users to get a general idea of the volume traffic their application is producing/consuming (especially when heavily using the amqp-value as opposed to just amqp data.) i.e. can't really sizeof(*amqp.Message) very effectively, and that may not totally correspond to what is going over the wire too directly. At present the best option to get that information is probably, running a redundant
Message.UnmarshalBinary()to get the raw buffer and get its size.Alternatively, maybe it is more idiomatic to instead focus on transport level traffic. A little ugly but if the amqp.ConnOptions included an option to provide a Dialer interface, folks could provide a wrapped net.Conn that could let them observe the whole of protocol traffic rather than figuring out an external proxy to point at.
Appreciate your thoughts! If there were consensus that there were a worth while solution here I'd be glad to contribute.