Heartbeat mechanism with Smallrye AMQP connector #39365
-
Describe the bugHi everyone, this is mostly a question as I couldn't change the label. I am using smallrye reactive messaging with Quarkus to connect to an amqp message broker. My assumption here is that the idle timeout is set at the broker side because I don't think the smallrye amqp has an idle timeout right? Ideally there should be a mechanism for the client to keep the connection like a heartbeat mechanism in case the broker has a timeout. I could not find something like that in the doc for Smallrye AMQP. Expected behaviorNo response Actual behaviorNo response How to Reproduce?No response Output of
|
Beta Was this translation helpful? Give feedback.
Replies: 13 comments 16 replies
-
|
/cc @Ladicek (smallrye), @jmartisk (smallrye), @phillip-kruger (smallrye), @radcortez (smallrye) |
Beta Was this translation helpful? Give feedback.
-
|
@geoand @cescoffier Any idea how I could do this? 😬 |
Beta Was this translation helpful? Give feedback.
-
|
cc @ozangunalp |
Beta Was this translation helpful? Give feedback.
-
|
No, except modifying the AMQP client options, I do not see another approach. I would disable the health check and implement a custom one instead. |
Beta Was this translation helpful? Give feedback.
-
Hi @cescoffier @ApplicationScoped
public class AmqpConfigurationProvider {
@ConfigProperty(name = "amqp-port")
int port;
@ConfigProperty(name = "amqp-use-ssl")
boolean useSsl;
@Produces
@Identifier("custom-amqp-client-options")
public AmqpClientOptions getNamedOptions() {
return new AmqpClientOptions().setTcpKeepAlive(true).setPort(port).setSsl(useSsl);
}
}I would use the health check deactivation as last solution. If you know another AMQP option I can try please let me know. |
Beta Was this translation helpful? Give feedback.
-
|
Which broker are you using? Do they use an idle timeout? Could you potentially send fake frames regularly to keep it open? |
Beta Was this translation helpful? Give feedback.
-
Interesting. Thanks a lot for the link. But for now I can only use AMQP 1.0 |
Beta Was this translation helpful? Give feedback.
-
|
Did you try also setting the idle timeout on AMQP client options ? As per the Solace doc they should honor it and not close the connection. |
Beta Was this translation helpful? Give feedback.
-
I looked at the default in Vert.x AmqpClientOptions: https://vertx.io/docs/apidocs/io/vertx/core/net/TCPSSLOptions.html#DEFAULT_IDLE_TIMEOUT |
Beta Was this translation helpful? Give feedback.
-
|
I am not sure how the Vert.x Proton interprets the options. Maybe it is not even the idle timeout but the The proton client will then advertise the idle timeout opening a transport to the remote peer. |
Beta Was this translation helpful? Give feedback.
-
|
Hmm From the ProtonClientOptions#setHeartbeat(...) Javadoc I am not sure whether it is what we need here |
Beta Was this translation helpful? Give feedback.
-
|
That's why I pointed you to the TCP idle timeout config but looking at the proton transport code, it does set the AMQP idle timeout from the heartbeat config. |
Beta Was this translation helpful? Give feedback.
-
|
Ok thanks I will try that out and let you know. That would mean I will have to set it pretty high. Because I actually need a permanent connection |
Beta Was this translation helpful? Give feedback.
-
|
Unfortunately setting the heartbeat on the AmqpClientOptions did not help either return new AmqpClientOptions()
.setTcpKeepAlive(true)
.setPort(port)
.setSsl(useSsl)
.setHeartbeat((int) TimeUnit.DAYS.toMillis(30)); |
Beta Was this translation helpful? Give feedback.
-
|
I think AMQP 1.0 broker in Azure (I don't remember the product name) had a similar behaviour. |
Beta Was this translation helpful? Give feedback.
-
|
Probably, you are sending the TCP keep-alive but the server doesn't respect it and closes the connection anyway. |
Beta Was this translation helpful? Give feedback.
-
|
Yes |
Beta Was this translation helpful? Give feedback.
-
|
Cloud-based broker tends to cut connections quickly if there are no L7 frames. |
Beta Was this translation helpful? Give feedback.
-
|
/cc @Ladicek (smallrye), @jmartisk (smallrye), @phillip-kruger (smallrye), @radcortez (smallrye) |
Beta Was this translation helpful? Give feedback.
-
|
@ozangunalp I have some good news. Setting the heartbeat finally helped. But I have to explain. Here is what the javadoc of the setHeartBeat method on the ProtonClientOptions says: Set the heartbeat (in milliseconds) as maximum delay between sending frames for the remote peers. If no frames are received within 2*heartbeat, the connection is closed In summary maybe it is something we can add to the Quarkus doc in the section about customizing the underlying AMQP client. I could also submit a PR if you like. If you would like to do it by yourself it is also fine. return new AmqpClientOptions()
.setTcpKeepAlive(true)
.setPort(port)
.setSsl(useSsl)
.setHeartbeat(3000); |
Beta Was this translation helpful? Give feedback.
-
|
That's very good news! Please submit a PR explaining that, it can serve others |
Beta Was this translation helpful? Give feedback.
-
|
Here is the PR I just created for that in Quarkus doc : #39406 |
Beta Was this translation helpful? Give feedback.
-
|
PR for adjusting similar doc in smallrye-reactive-messaging: smallrye/smallrye-reactive-messaging#2528 |
Beta Was this translation helpful? Give feedback.
-
|
If you know someone at Qaurkus repo that could review the PR I would really appreciate: #39406 |
Beta Was this translation helpful? Give feedback.
-
|
Sorry I missed that, it is merged now. |
Beta Was this translation helpful? Give feedback.
I am not sure how the Vert.x Proton interprets the options. Maybe it is not even the idle timeout but the
heartbeatproperty:https://github.com/vert-x3/vertx-proton/blob/dd39eeea85764255750fe19013ad231f8dee4c16/src/main/java/io/vertx/proton/impl/ProtonTransport.java#L75
The proton client will then advertise the idle timeout opening a transport to the remote peer.