[
https://issues.apache.org/jira/browse/AMQ-5155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14504267#comment-14504267
]
Chad Kelly commented on AMQ-5155:
---------------------------------
Hi Timothy,
The included patch will give the read check thread a 2nd chance (via 1 second)
before exception and termination. It also designs the read check thread and
write check thread to be nearly identical. I will implement other approaches
should this one NOT be satisfactory. The attached patchfile.txt is for
“/activemq-client/src/main/java/org/apache/activemq/transport/AbstractInactivityMonitor.java”.
I believe there is a fundamental design problem with AMQ heartbeats, because
the timing of web browsers heartbeats has a cadence equal to the timing for AMQ
to check heartbeats. Eventually, due to very small changes in time, the web
browser heartbeat can eventually cross over AMQ checks for heartbeats. In the
included example, the web browser client is sending at the rate of 10 seconds,
and AMQ server is also checking at the rate of 10 seconds. Longer term testing,
with a variety of websocket enabled browsers, show that the heartbeats can
cross over.
> Heartbeat fails in STOMP over WebSockets
> ----------------------------------------
>
> Key: AMQ-5155
> URL: https://issues.apache.org/jira/browse/AMQ-5155
> Project: ActiveMQ
> Issue Type: Bug
> Affects Versions: 5.9.1, 5.10.0
> Reporter: Arjan van den Berg
> Assignee: Timothy Bish
> Priority: Minor
> Fix For: 5.12.0
>
> Attachments: AMQ-5155-jetty8.diff, AMQ-5155-jetty9.diff,
> firefox_bug_example1.pcapng, patchfile.txt
>
>
> From AMQ-4740:
> I receive the following error after establishing a connection and heartbeat
> through stomp.js. This seems to occur after the 'PING' is sent.
> ---------- stomp.js output
> <<< CONNECTED
> heart-beat:10000,10000
> session:ID:localhost.localdomain-45596-1396530920609-2:2
> server:ActiveMQ/5.10-SNAPSHOT
> version:1.1
> send PING every 10000ms
> check PONG every 10000ms
> <<< PONG
> >>> PING
> did not receive server activity for the last 20005ms
> Whoops! Lost connection to ws://172.16.99.73:61614/stomp
> --------------------- activemq console ---------------
> WARN | Transport Connection to: StompSocket_19548821 failed:
> java.io.IOException
> Exception in thread "ActiveMQ InactivityMonitor Worker"
> java.lang.NullPointerException
> at
> org.apache.activemq.transport.AbstractInactivityMonitor.onException(AbstractInactivityMonitor.java:314)
> at
> org.apache.activemq.transport.AbstractInactivityMonitor$4.run(AbstractInactivityMonitor.java:215)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> WARN | Transport Connection to: StompSocket_19548821 failed:
> java.io.IOException
> Exception in thread "ActiveMQ InactivityMonitor Worker"
> java.lang.NullPointerException
> at
> org.apache.activemq.transport.AbstractInactivityMonitor.onException(AbstractInactivityMonitor.java:314)
> at
> org.apache.activemq.transport.AbstractInactivityMonitor$4.run(AbstractInactivityMonitor.java:215)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> For me it looks as if the StompInactivityMonitor is delivering its events to
> the wrong Transport, i.e. it needs a "narrow()" when setting it up.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
