[jbertram]

We changed the connection-ttl into 1hour (3600000ms). it worked with this change.

This is still quite long, in my opinion.  The default connection-ttl is 60,000 ms (i.e. 1 minute).  Using a connection-ttl of 1 hour will still allow potentially significant message accumulation in the defunct subscription.

If No consumer connected, how hornetq handle the server message from Application side, seems it's discarded, right?  since when I dumped, there is no ServerMessageImpl object in heap dump.

If there are no subscriptions on the topic then any message sent to the topic will be discarded.  Remember, subscriptions can be durable or non-durable so even if there are no clients connected there can still be a valid subscription.

[ericxiaomingzhao]

Justin,

I got it. Thanks a lot for your patient answers for all my previous questions.

[gabboflabbo]

I've been noticing similar memory issues with hornetq and clustering (but not related to connection-ttl).   Except my memory runs out quite quickly.

In my setup (both wildfly 9.0.1):

Server A Windows:

- produces messages to queue

Server B Linux

- consumes messages

Server B can't consume messages as fast as they are produced so Server A eventually starts paging.   Debugging memory on Server A shows that the BridgeImpl class has a member called "refs" which holds every a reference to every message (even ones that are paged).    The problem is that if I push 1million messages then that refs member will hold 1 million references which blows up my memory.    

Paging works fine in a single server environment to limit memory usage but does not in a clustered environment.   How do I avoid this problem?

I have (2) small wars to reproduce this problem.

[jbertram]

I recommend you create a new thread for your question rather than hijacking this one.

[ericxiaomingzhao]

Hello Justin,

I got new problem when I changed the connection-ttl to a lower value (10 min = 600000 ms) , now we got new problem:

we got the following log:

(hornetq-failure-check-thread) Connection failure has been detected: Did not receive data from /135.251.90.168:57638. It is likely the client has exited or crashed without closing its connection, or the network between the server and client has failed. You also might have configured connection-ttl and client-failure-check-period incorrectly. Please check user manual for more information. The connection will now be closed. [code=3]

then send jms message, we always see "Producer is closed".   it will clean up the producer when the failure happened.

We tried to pull out the cable and wait for 10 mins, but didn't show the above log. currently we don't know the scenario.

how to fix this issue?

Best Regards,

Eric.

[jbertram]

then send jms message, we always see "Producer is closed".   it will clean up the producer when the failure happened.

What is "it" here that is cleaning up the producer when the failure happened?  Are you asking a question or simply making a statement?  If the latter, why do you see "Producer is closed" if "it" will clean up the producer when the failure happened?

We tried to pull out the cable and wait for 10 mins, but didn't show the above log. currently we don't know the scenario.

Currently you don't know the scenario for what?

how to fix this issue?

At this point I don't even know what the issue is.