Hello, Regarding a previous point in an email. We actually use amqpIdleTimeout=0 as a workaround for a different problem we encountered. We have an environment where changing the system time can be a fairly typical scenario. We have observed that in the class "RemotingServiceImpl implements RemotingService, ServerConnectionLifeCycleListener" in the "run()" method the "final long now" variable is taking the current time using "System.currentTimeMilis". We suspect that because of this, when the system time changes to a future date, the checks regarding the "ttl" will fail, adding the connection to the "toRemove" variable and then closing the connection.
We therefore noticed that the "ttl" could be "-1" and eventually used the workaround to set the amqpIdleTimeout=0. It would help us out if the system time changing could be taken into consideration in these cases and we could also avoid using the amqpIdleTimeout=0 as it is understandably not recommended. On Mon, Jan 20, 2025 at 9:06 AM Erik Maerean <optimuser...@gmail.com> wrote: > Hi Justin, > > Thank you for the fast response and quick resolution to our issue with > Artemis. We really appreciate your help and are looking forward to the fix > in the next release. > > On Fri, Jan 17, 2025 at 5:52 PM Justin Bertram <jbert...@apache.org> > wrote: > >> Don't worry about creating a Jira. I created one already [1]. I'll be >> sending a PR shortly so this should be resolved in 2.40.0. >> >> >> Justin >> >> [1] https://issues.apache.org/jira/browse/ARTEMIS-5249 >> >> On Fri, Jan 17, 2025 at 9:29 AM Justin Bertram <jbert...@apache.org> >> wrote: >> >> > What specific WebSocket protocol documentation are you looking at? >> > >> > Netty's io.netty.handler.codec.http.websocketx.WebSocketProtocolHandler >> > [1] clearly handles pong frames. Also, the spec [2] says this: >> > >> > A Pong frame MAY be sent unsolicited. This serves as a >> > unidirectional heartbeat. A response to an unsolicited Pong frame >> is >> > not expected. >> > >> > Can you open a Jira [3] for this? Please include the exception in the >> > description of the Jira to help other folks who are searching find it. >> > Thanks! >> > >> > It's also worth noting that using amqpIdleTimeout=0 is a bit dangerous >> as >> > any connection that fails without being explicitly closed will not be >> > cleaned up on the broker. This risks an accumulation of "zombie" >> > connections on the broker which may starve legitimate connections of >> > resources and ultimately cause the broker to fail. >> > >> > >> > Justin >> > >> > [1] >> > >> https://github.com/netty/netty/blob/4.1/codec-http/src/main/java/io/netty/handler/codec/http/websocketx/WebSocketProtocolHandler.java >> > [2] https://www.rfc-editor.org/rfc/rfc6455#section-5.5.3 >> > [3] https://issues.apache.org/jira/browse/ARTEMIS >> > >> > On Fri, Jan 17, 2025 at 2:00 AM <optimuser...@gmail.com> wrote: >> > >> >> Hello everyone, >> >> >> >> >> >> >> >> We are using ActiveMQ Artemis Server version 2.33.0 on a Windows >> platform >> >> and run it as a service. >> >> We use AMQP over WebSocket protocol and have configured the websocket >> >> acceptor to have amqpIdleTimeout=0. >> >> In our setup we use IIS as a reverse proxy between the clients and the >> >> broker. The clients will no longer send keep-alive requests because of >> the >> >> amqpIdleTimeout configuration. >> >> >> >> >> >> >> >> However IIS does send Pong frames to the broker after the client is >> idle >> >> for 30s. >> >> Looking at the implementation of >> >> WebSocketServerHandler.handleWebSocketFrame, it seems that the Pong >> frame >> >> is not supported and an exception is thrown. The exception appears in >> the >> >> logs. >> >> >> >> >> >> >> >> Looking at the WebSocket protocol documentation, it seems that a Pong >> >> request should be supported. >> >> >> >> >> >> >> >> Our issue is that Artemis closes the connection immediately after >> >> receiving the Pong. Is this intended with regard to the protocol? >> > >> > >> >
