[
https://issues.apache.org/jira/browse/QPID-7670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15864048#comment-15864048
]
Alex Rudyy commented on QPID-7670:
----------------------------------
I reviewed the changes committed under revision
[r1782735|https://svn.apache.org/r1782735].
The changes look good, however, I'm concerned about possibility of multiple
ticks invocations for the same ticker.
For example, if multiple connections are created where one has expired
idle/open transaction, and other connections receive/send data actively.
On every receive WebSocketIdleTimeoutChecker is woken up and depending from
number of threads in pool and thread scheduling, there is possibility that the
same ticker could be scheduled multiple times. (Let's imagine that it is the
first connection with expired ticker in the _activeConnections list). It looks
like that for transaction idle/open closing ticker, that might result in
multiple end frames being send for the same session. One way to mitigate this
issue is to have idempotent tickers implementations. Another way to mitigate
this problem is to keep the iterator state for the active connection iterator
and resume iteration from the next connection and when the iterator end is
reached create a new iterator. Taking that we need to include this fix into
next bugfix release, I am fine with current approach but we might need to fix
the possibility of multiple invocations of the same ticker in next major
release.
Keith, Rob,
What do you think about the issue highlighted above?
> [Java Broker] WebSocket transport does not respect AMQP idle timeout
> --------------------------------------------------------------------
>
> Key: QPID-7670
> URL: https://issues.apache.org/jira/browse/QPID-7670
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
> Affects Versions: qpid-java-6.0.6, qpid-java-6.1.1
> Reporter: Rob Godfrey
> Assignee: Rob Godfrey
> Fix For: qpid-java-7.0, qpid-java-6.1.2
>
>
> The websocket transport does not currently respect the requested AMQP idle
> timeout settings. Moreover it does enforce an arbitrary Jetty setting for
> read timeout, which it does not inform the client about
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
