Repository navigation
Fixes MissingConverterException when receiving data with the rabbitmq input plugin - #9984
Conversation
…ingConverterException when receiving data with the rabbitmq input plugin. This is adding support for Byte, Short and (most importantly) Date. But to decrease verbosity I use the functionality in fallbackConvert to decode subclasses of the given classes. See method ValueReader.readFieldValue in java package amqp-client for which types can appear over AMQP (except that LongString is changed to String by March Hare).
|
Since this is a community submitted pull request, a Jenkins build has not been kicked off automatically. Can an Elastic organization member please verify the contents of this patch and then kick off a build manually? |
|
jenkins test this please |
| ); | ||
| converters.put(Long.class, LONG_CONVERTER); | ||
| converters.put(Integer.class, LONG_CONVERTER); | ||
| converters.put(Number.class, input -> RubyUtil.RUBY.newFixnum(((Number) input).longValue())); |
There was a problem hiding this comment.
This is not a good change. The key for the converters map needs to a concrete class. The o.getClass() will always be the concrete class so the lookup will not find this Number.class key, forcing the fallback execution.
I think adding converters.put(Short.class, LONG_CONVERTER); is all that is needed (and the Date one below) then we have all the Number subclasses covered.
…ingConverterException when receiving data with the rabbitmq input plugin. Be verbose instead of using functionality in fallbackConvert for Byte, Short, Integer and Long.
|
I know that my first commit would mean means fallback execution, but fallbackConvert would only be called once per concrete type. I don't see what the problem with that would be. |
|
The Valuefier class was meticulously crafted by @original-brownbear to eek out the maximum performance as it is called so many times during an Events lifetime. If we can avoid falling back then all the better. I think we had some discussion about whether Byte in its external usage is a Char in disguise although it might be a conversation I had with myself 😄. In some senses it would be up to the code on the edge where the data comes into logstash to interpret Byte as a character if that is the intent. |
logstash-plugins/logstash-input-rabbitmq#112 Fixes most cases of MissingConverterException when receiving data with the rabbitmq input plugin.
This is adding support for Byte, Short and (most importantly) Date. But to decrease verbosity I use the functionality in fallbackConvert to decode subclasses of the given classes.
See method ValueReader.readFieldValue in java package amqp-client for which types can appear over AMQP (except that LongString is changed to String by March Hare).