Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow explicit number type declaration #358

Closed
pcan opened this issue Jun 4, 2017 · 3 comments
Closed

Allow explicit number type declaration #358

pcan opened this issue Jun 4, 2017 · 3 comments

Comments

@pcan
Copy link

pcan commented Jun 4, 2017

I'm currently trying to send messages from amqp.node to a Java Spring Application, that expects an header as long, see this listener for example:

@RabbitListener(queues = "testQueue")
public void handleRequest(@Payload RequestBean bean, @Header("trace-id") long traceId) {
    // some logic here...
}

I'm getting a type mismatch exception when the handleRequest method gets called, since the expected type for trace-id is long (64-bit integer), but it arrives as byte (8-bit integer). I found that this behaviour is implemented here, and at the moment there is no way to force the number type from outside.

I think the codec may handle these special cases like it does for timestamp (see here and here), by adding 'int8', 'int16', 'int32' and 'int64' to that switch-case block, and let the user choose the right integer type if needed. The existing heuristic may not be changed, to avoid a breaking change.
So, I may write something like this:

var options = {
	headers: {
		'trace-id': {'!': 'int64', value: 12}
	},
	contentType: 'application/json',
	contentEncoding: 'UTF-8'
};

channel.publish('myExchange', 'routing.key', new Buffer(JSON.stringify(message)), options);
@squaremo
Copy link
Collaborator

I like this idea. You're right that it need not interfere with the existing encodings. I'm not sure there are signed 32 bit integers in AMQP 0.9.1 (or RabbitMQ's codec, anyway). But hence or otherwise, this would be fairly easy to add. PR? :)

@michaelklishin
Copy link

This is not a bad idea. Numerical type interop between languages is a pain and sometimes more control is the only way to achieve it.

On a related note, this is one of the reasons to avoid using message headers where possible and
stick to serialised message bodies.

@pcan
Copy link
Author

pcan commented Jun 16, 2017

Thanks. I will submit a PR asap.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants