-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Apache ActiveMQ Artemis: Peer disconnected #26
Comments
can you provide a simple test replicating this? |
duh.. this is Java.. so simple to check... we should open a JIRA on artemis. @themerius want to make the honors or should I open it? |
close this one.. I will take a look through the JIRA. |
Thanks for your fast reply! I would happy to support you with testing the fixed Artemis. |
@themerius : I already see a few things wrong that need improvement on the Stomp manager, but I'm a bit confused on making the actual keep alive frames to be sent. I added an example on master using stomp-jms, that maybe you could tweak to replicate the issue you are seeing: https://github.com/apache/activemq-artemis/tree/master/examples/protocols/stomp/stomp-jms Can you help on that? Otherwise I won't know how to replicate your issue. |
@clebertsuconic : Have a look at my branch: Run with Run with |
@clebertsuconic @themerius I don't know StompJMS at all, but as far as I can tell this is working as expected on the Artemis side of things. Artemis will close the connection if no data has been received for a certain amount of time. By default it will check every 30 seconds, and will evict connections that haven't received data in 30 seconds. So depending on when exactly you send data, connections are closed anytime between 30s-60s after data was last received. It looks like StompJMS doesn't have any support for heart-beating (see #17) so if you're not sending anything yourself then the connection will be closed after a while. If you want Artemis to behave more like Apollo, you can increase the timeouts. (I don't know what timeouts Apollo uses by default, but evidently they are higher.) Alternatively, somebody could implement proper heart-beating in StompJMS or you could add poor man's heart-beating to your application code (i.e. manually sending a dummy message in regular intervals). |
@jscheid Thanks for your reply. I've feared something like that. Is it possible to configure a
But it seems that this is not the right way to increase the timeouts to infinite? But indeed, a neat solution would be to have heart beats. |
It looks right to me, does it not work? @clebertsuconic knows more about Artemis configuration, perhaps he can chime in. |
I'll get still |
There is the master configuration ttlOverride.. not on the acceptor I'm afraid. (although it makes sense and it looks an easy change) What happens is per definition stomp should be -1 if no TTL or ping sent (per stomp docs/spec) and the connection should be closed through netty failures, what should happen after TCP settings. Also, @jscheid the TTL Checker is using a Thread instead of the scheduled executors.. what won't scale to many connections... it's one thing that's need to be changed. |
@clebertsuconic where does it say that in the STOMP spec? |
@themerius after discussing with @clebertsuconic on IRC, it turns out that Artemis has two separate mechanisms for terminating an idle STOMP connection:
It seems to me that the correct fix is to disable the former for the STOMP protocol. Then, without a |
@jscheid Because this library is STOMP 1.0 and sends no |
@themerius should work once apache/activemq-artemis#208 is merged. |
artemis should make an infinite connecotin life accordingly to Hiram |
... and his spec |
Hi there,
I've tested this library with Apache ActiveMQ Artemis 1.1.0, and it works.
But if my process idles some time, it gets this exception:
Maybe something makes a timeout (heart beat to slow?), which causes the server to disconnect this client? If I'm using
factory.setDisconnectTimeout(...)
it has no effect, but maybe I'm searching at the wrong place?For comparison: On Apache Apollo the connections remains open.
The text was updated successfully, but these errors were encountered: