-
-
Save markembling/1104836 to your computer and use it in GitHub Desktop.
require 'mqtt/client' | |
mqtt = MQTT::Client.new('10.25.2.4') | |
loop do | |
mqtt.connect do |c| | |
c.publish('test/foo/bar','this is a test message #{Time.now}') | |
puts "published a msg" | |
sleep 0.05 | |
end | |
end |
markembling
commented
Jul 26, 2011
via email
Yep, RSMB is the broker....the strange thing is that if we use the MQTT java tool to connect to the broker...the broker answers.... it is only when our ruby server tries to answer (with the ruby mqtt gem), the answer doesn't seem to get out of the server....
Our code is different from yours since we init a new client for each message we want to send.... from the ruby-mqtt doc we thought that once it executes the block, it disconnects.... but in the broker log, if we stop it, when stopping we see a lot of "Closing client" messages so it seems that the client is persistent.... maybe we could start by trying to create just one client like you and send all the messages through it..... its so confusing :S
Anyway thanks for your help!! I'll let you know if we find any solution! :)
Hmm, I still have no clue as to the problem. About the block/connection/disconnection issue though, as I understand it, you are right. The block passed into the connect method is executed after a connection, then it is disconnected. The client (in my case, the mqtt
variable) can be reused though, as you just have it connect again.
If you watch the broker's log output, it does definitely connect, do its thing and disconnect. However I too saw what you're describing when stopping the broker. I assume that is some sort of cleanup process in the broker (removing the record of previous clients perhaps?)
But both my experience and yours seem to point at the gem not being that reliable. Looking at the code myself (I'm no expect, but...) it does look like perhaps things are somewhat optimistic - if it doesn't get what it expects, when it expects it, all hell breaks loose.