Created the Jira ticket https://issues.apache.org/jira/browse/ARTEMIS-5277
On Mon, Jan 27, 2025 at 6:59 PM Justin Bertram <jbert...@apache.org> wrote: > I think we could use System.nanoTime() for this. Could you open a Jira [1]? > > If you don't have an account just request one. I'll be looking for the > request and approve it ASAP. > > > Justin > > [1] https://issues.apache.org/jira/browse/ARTEMIS > > > On Mon, Jan 27, 2025 at 4:28 AM Erik Maerean <optimuser...@gmail.com> > wrote: > > > 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? > > >> > > > >> > > > >> > > > > > >
