IllegalStateException: MQTT endpoint is closed
See original GitHub issueWe saw the following exception in an MQTT adapter log:
ERROR io.vertx.core.impl.ContextImpl Unhandled exception
java.lang.IllegalStateException: MQTT endpoint is closed
at io.vertx.mqtt.impl.MqttEndpointImpl.checkClosed(MqttEndpointImpl.java:724)
at io.vertx.mqtt.impl.MqttEndpointImpl.close(MqttEndpointImpl.java:674)
at io.vertx.mqtt.impl.MqttEndpointImpl.connack(MqttEndpointImpl.java:311)
at io.vertx.mqtt.impl.MqttEndpointImpl.reject(MqttEndpointImpl.java:343)
at io.vertx.mqtt.impl.MqttEndpointImpl.reject(MqttEndpointImpl.java:50)
at org.eclipse.hono.adapter.mqtt.AbstractVertxBasedMqttProtocolAdapter.handleConnectionRequestResult(AbstractVertxBasedMqttProtocolAdapter.java:454)
at org.eclipse.hono.adapter.mqtt.AbstractVertxBasedMqttProtocolAdapter.lambda$handleEndpointConnection$12(AbstractVertxBasedMqttProtocolAdapter.java:395)
at io.vertx.core.impl.FutureImpl.tryFail(FutureImpl.java:197)
at io.vertx.core.impl.FutureImpl.fail(FutureImpl.java:127)
[...]
at io.vertx.core.impl.FutureImpl.tryComplete(FutureImpl.java:152)
at io.vertx.core.impl.FutureImpl.complete(FutureImpl.java:113)
at org.eclipse.hono.service.resourcelimits.PrometheusBasedResourceLimitChecks.lambda$executeQuery$24(PrometheusBasedResourceLimitChecks.java:494)
at io.vertx.ext.web.client.impl.HttpContext.handleDispatchResponse(HttpContext.java:308)
at io.vertx.ext.web.client.impl.HttpContext.execute(HttpContext.java:295)
at io.vertx.ext.web.client.impl.HttpContext.next(HttpContext.java:270)
at io.vertx.ext.web.client.impl.predicate.PredicateInterceptor.handle(PredicateInterceptor.java:69)
at io.vertx.ext.web.client.impl.predicate.PredicateInterceptor.handle(PredicateInterceptor.java:32)
at io.vertx.ext.web.client.impl.HttpContext.next(HttpContext.java:267)
at io.vertx.ext.web.client.impl.HttpContext.fire(HttpContext.java:277)
at io.vertx.ext.web.client.impl.HttpContext.dispatchResponse(HttpContext.java:238)
at io.vertx.ext.web.client.impl.HttpContext.lambda$null$2(HttpContext.java:367)
at io.vertx.core.impl.ContextImpl.executeTask(ContextImpl.java:369)
[...]
There is no CONNECT
tracing span in the OpenTracing component for the corresponding MQTT connection attempt, i.e. the exception causes the span not to get finished.
Issue Analytics
- State:
- Created 3 years ago
- Comments:6 (6 by maintainers)
Top Results From Across the Web
IllegalStateException: MQTT endpoint is closed · Issue #2030
This may happen in the following scenario: The verify message limit check done as part of the CONNECT handling takes longer than the...
Read more >io.vertx.mqtt.MqttEndpoint.close java code examples
Close the endpoint, so the connection with remote MQTT client */ public void ... mqttEndpoint.close(); } catch (IllegalStateException e) { LOG.warn("MQTT ...
Read more >exception is java.lang.IllegalStateException: No reply topic ...
The outbound gateway can only infer the reply topic if the reply container is assigned to exactly one partition. You can assign it...
Read more >Spring Integration
An inbound channel adapter endpoint connects a source system to a MessageChannel . Message sources can be pollable (for example, POP3) or message-driven_...
Read more >Example usage for io.vertx.core Future future
incrementUndeliverableMqttMessages (resource.getEndpoint(), tenantId); close(endpoint); } else { LOG.trace("successfully processed message [client ID: {} ...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
@mbaeuerle It’s not the readiness probe there but just the
HotrodCache.checkForCacheAvailability
method. That method is invoked not only from the readiness probe but also from theHotrodCache.isConnected
method. And that method gets called as part of the MQTTCONNECT
handling (seeAbstractVertxBasedMqttProtocolAdapter.handleEndpointConnection
and theisConnected
call in there).So a possible scenario could have been that the Hotrod cache connection check (and the corresponding cache.put operation in there) took so long that the MQTT client already closed its connection attempt, which in the end lead to the above exception when the connection attempt was about to get rejected by the MQTT adapter. The fix in #2057 will also cover that scenario.
That fact that doing a cache PUT on each device opening an MQTT connection seems unnecessary is addressed in #2068.
Also fixed in 1.2.x (b94a67a4db43a514c93f50f9a1a66ef51b2db4cd)