hono: Connections don't seem to re-connect

When testing Hono I ran into the following scenario, the message flow works fine until the internal token expires. This will cause the connection to the adapter be terminated. The service should re-connect automatically but this doesn’t seem to work. Instead I do see the following messages in the log file:

17:08:17.229 [vert.x-eventloop-thread-0] DEBUG o.e.h.a.h.AbstractVertxBasedHttpProtocolAdapter - cannot process message for device [tenantId: DEFAULT_TENANT, deviceId: hono-demo-1-simulator-http-47-z6dh4-84, endpoint: telemetry]: null
17:08:17.229 [vert.x-eventloop-thread-0] DEBUG o.e.h.a.h.AbstractVertxBasedHttpProtocolAdapter - cannot process message for device [tenantId: DEFAULT_TENANT, deviceId: hono-demo-1-simulator-http-47-zkvfp-394, endpoint: telemetry]: null
17:08:17.230 [vert.x-eventloop-thread-0] DEBUG o.e.h.a.h.AbstractVertxBasedHttpProtocolAdapter - cannot process message for device [tenantId: DEFAULT_TENANT, deviceId: hono-demo-1-simulator-http-47-kx8g6-225, endpoint: telemetry]: null
17:08:17.231 [vert.x-eventloop-thread-0] DEBUG o.e.h.a.h.AbstractVertxBasedHttpProtocolAdapter - cannot process message for device [tenantId: DEFAULT_TENANT, deviceId: hono-demo-1-simulator-http-47-llk7p-290, endpoint: telemetry]: null
17:08:17.231 [vert.x-eventloop-thread-0] DEBUG o.e.h.a.h.AbstractVertxBasedHttpProtocolAdapter - cannot process message for device [tenantId: DEFAULT_TENANT, deviceId: hono-demo-1-simulator-http-47-htmqr-217, endpoint: telemetry]: null
17:08:17.232 [vert.x-eventloop-thread-0] DEBUG o.e.h.a.h.AbstractVertxBasedHttpProtocolAdapter - cannot process message for device [tenantId: DEFAULT_TENANT, deviceId: hono-demo-1-simulator-http-47-2db2j-169, endpoint: telemetry]: null
17:08:17.232 [vert.x-eventloop-thread-0] DEBUG o.e.h.a.h.AbstractVertxBasedHttpProtocolAdapter - cannot process message for device [tenantId: DEFAULT_TENANT, deviceId: hono-demo-1-simulator-http-47-4tmkg-330, endpoint: telemetry]: null
17:08:17.232 [vert.x-eventloop-thread-0] DEBUG o.e.h.a.h.AbstractVertxBasedHttpProtocolAdapter - cannot process message for device [tenantId: DEFAULT_TENANT, deviceId: hono-demo-1-simulator-http-47-z6dh4-460, endpoint: telemetry]: null

The location which seems to map is in org.eclipse.hono.adapter.http.AbstractVertxBasedHttpProtocolAdapter.doUploadMessage(RoutingContext, String, String, Buffer, String, Future<MessageSender>, String) on line 494. A message of null most often indicates a null pointer exception.

About this issue

Original URL
State: closed
Created 6 years ago
Comments: 21 (21 by maintainers)

Commits related to this issue

[#457] Clearing out connection after loss of connection This change sets the connection to 'null' when it is being handled is disconnected. This will ensure future checks on the connection won't cons... — committed to ctron/hono by ctron 6 years ago
[#457] Clearing out connection after loss of connection This change sets the connection to 'null' when it is being handled is disconnected. This will ensure future checks on the connection won't cons... — committed to ctron/hono by ctron 6 years ago
[#457] Clearing out connection after loss of connection This change sets the connection to 'null' when it is being handled is disconnected. This will ensure future checks on the connection won't cons... — committed to eclipse-hono/hono by ctron 6 years ago
[#457] Clearing out connection after loss of connection This change sets the connection to 'null' when it is being handled is disconnected. This will ensure future checks on the connection won't cons... — committed to bosch-io/hono by ctron 6 years ago
[#457] Clearing out connection after loss of connection This change sets the connection to 'null' when it is being handled is disconnected. This will ensure future checks on the connection won't cons... — committed to bcmi-labs/hono by ctron 6 years ago

Most upvoted comments

So calling disconnect() and then isDisconnected() should still return false, as the transport still is non-null.

This looks like a bug in ProtonConnectionImpl. doesn’t it? Shouldn’t the disconnect method also set transport to null like fireDisconnect does?

sophokles73 on Jan 25, 2018