Closed mswartley closed 3 months ago
This is a known issue and a problem with the IoTHub v2 gateway. Per spec, once a session has been established, the peer (IoTHub) must send flow frames with next-incoming-id
set.
The following series of frames indicates that a session has been established.
11:46:02.996654 TX (connWriter 0x140002b8000) timeout 30s: Frame{Type: AMQP, Channel: 0, Body: Begin{RemoteChannel: <nil>, NextOutgoingID: 0, IncomingWindow: 5000, OutgoingWindow: 5000, HandleMax: 4294967294, OfferedCapabilities: [], DesiredCapabilities: [], Properties: map[]}}
11:46:03.024231 RX (connReader 0x140002b8000): Frame{Type: AMQP, Channel: 0, Body: Begin{RemoteChannel: 0, NextOutgoingID: 1, IncomingWindow: 4294967295, OutgoingWindow: 5000, HandleMax: 4294967295, OfferedCapabilities: [], DesiredCapabilities: [], Properties: map[]}}
At this point, the peer must not send flow frames with an empty next-incoming-id
, but it does just that.
11:46:03.056878 RX (connReader 0x140002b8000): Frame{Type: AMQP, Channel: 0, Body: Flow{NextIncomingID: <nil>, IncomingWindow: 4294967295, NextOutgoingID: 0, OutgoingWindow: 5000, Handle: 0, DeliveryCount: 0, LinkCredit: 50, Available: <nil>, Drain: false, Echo: false, Properties: map[]}}
This is a violation of the protocol so go-amqp
terminates the connection.
Unfortunately, I don't know when IoTHub will fix their AMQP implementation.
Given that this is a service-side issue, I'm closing this. Please ping back if you have further questions.
We started encountering the following errors from the
go-amqp
library when sending messages to certain Azure IoTHub instances:It took a while, but Azure support determined that the issue is related to the version of the Gateway component in IoTHub:
go-amqp
library succeedgo-amqp
library fail with the error aboveHowever, I have tested with the Apache QPID client against IoTHub with both Gateway v1 and v2 and have not encountered this error.
My test code is below, as well as logs from both a successful send to IoTHub with Gateway v1 and a failed send to IoTHub with Gateway v2. Note that the successful and failure log files are from 2 different IoTHub instances. Once the instance that returned the failure is downgraded to Gateway v1, the same code results in a successful send.
Have you seen this error in any of your testing or integration with Azure IoTHub?
Logs from successful send to IoTHub with Gateway v1:
Logs from failed send to IoTHub with Gateway v2: