Connection gets immediately closed if corrupt message is waiting to be delivered
gsprem opened this issue · comments
Message in queue that is to be delivered to client A has a corrupt topic so that serialize_utf function fails.
Client A is unable to make non CleanSession connection to server because each time it connects serialization fails and is immediately disconnected. Workaround is to connect with CleanSession true, but then all other messages are lost.
Log snippet from RabbitMQ, topic is omitted:
** Reason for termination ==
**
{
badarg,
[
{erlang,byte_size,[{error,<<"xxxxx">>,<<137>>}],[]},
{rabbit_mqtt_frame,serialise_utf,1,[{file,"src/rabbit_mqtt_frame.erl"},{line,220}]},
{rabbit_mqtt_frame,serialise_variable,3,[{file,"src/rabbit_mqtt_frame.erl"},{line,187}]},
{rabbit_mqtt_processor,send_client,2,[{file,"src/rabbit_mqtt_processor.erl"},{line,660}]},
{rabbit_mqtt_processor,amqp_callback,2,[{file,"src/rabbit_mqtt_processor.erl"},{line,328}]},
{rabbit_mqtt_reader,handle_info,2,[{file,"src/rabbit_mqtt_reader.erl"},{line,103}]},
{gen_server2,handle_msg,2,[{file,"src/gen_server2.erl"},{line,1049}]},
{proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,240}]}
]
}
Serialisation failures are considered to be fatal by every messaging protocol I can think of.
But this one affects not the side that corrupt message originated from but one it is to be delivered. Isn't that wrong?
@gsprem unless there is evidence (a way to reproduce) that it is RabbitMQ that causes the corruption, it's not really different to me. Ignoring [de]serialisation failures sounds way more wrong.
Perhaps a certain protocol codec could perform more checks; in general it is not a commonly reported issue for MQTT or any other protocol supported.
@michaelklishin I didn't say that RabbitMQ is causing corruption, but somehow message passed validation when it was received, and then failure occurred when it was to be delivered to destination. Btw, thanks for quick response.