The new client is the old one reconnecting after the old connection failed.
brianmay
brianmay
Looking at this more, I can see that after a publish it can be more then 30 seconds (the keep alive time) after sending a PUBLISH command and sending the ping. And sometimes (but not always) mosquitto complains and disconnects the client.
It seems that the timer code is triggered, but should_ping(ConnMod, Sock, LastPktId) returns false, so we don’t send the ping.
should_ping(ConnMod, Sock, _LastPktId) ->
case ConnMod:getstat(Sock, [send_oct]) of
{ok, [{send_oct, Val}]} ->
OldVal = put(send_oct, Val),
OldVal == undefined orelse OldVal == Val;
Error = {error, _Reason} ->
Error
end.
I am finding it difficult to interpret what this does.
I am going to set the config option force_ping to true, which I believe bypasses that test, see if that helps.
0
brianmay
The process which I said wasn’t working, may have actually been working fine, but coincidentally may not have busy at same time mqtt connection went down to normal operation. Have more debugging added now, will watch and see what happens.
I think the mqtt connection isn’t down for long, so chances of missing out on messages is small, but it was annoying me - especially when trying to diagnose another bigger issue, so fingers crossed that is resolved now.
0
Sebb
brianmay
Yes, definitely. That name is based on the hostname, which is automatically generated by nerves based on the mac address - or something like that.
Remember timestamps here are 1 second precision. So everything happened within 1 second.
0
Sebb
OK, makes sense. You can set log_dest syslog to get precise timestamps. I’d want to be 100% sure that its the same client. Being on the same host does not mean its the same client.
You say you are using nerves. Is this an embedded device? Maybe hardware problems with ETH?
Can’t imagine that there is such a horrendous bug in emqttc.
0
brianmay
I now have:
log_timestamp_format %Y-%m-%dT%H:%M:%S
In my mosquitto.conf, which is better, but still only accurate to the second.
This is running on RPI3, although I have also seen the same problem running on my relatively fast desktop too.
The timeout errors disappeared when I set force_ping=false.
It definitely looks like a bug in emqtt to me. But possibly only causes problems for use with mosquitto broker, not sure.
0
Sebb
mosquitto can’t log more precise (which is odd) but syslog can (log_dest syslog in .conf).
0
emiltin
I’m trying to use emqtt, on elixir 1.15.5, Erlang/OTP 26, following this example:
But I keep getting this error:
22:41:33.452 [error] emqtt(rsmp): State: waiting_for_connack, Unexpected Event: (:info, {:EXIT, #Port<0.10>, :einval})
This issue on Github makes we think it could be an issue on OTP 26?
https://github.com/emqx/emqtt/issues/203
Any experience/ideas? I just wanted to try mqtt on Elixir, but can’t really get past this roadblock.
0