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? > >> > > >> > > >> > > >
