Elliot Barlas wrote:
>
> Hey Michael, it turns out that the activemq broker actually does not
> proactively purge expired messages from queues. The broker will not send
> expired messages to consumers, but if there are no consumers consuming
> from the queue, expired messages just sit.
>
FY
We encountered the memory leak being described (the client map in
HttpTunnelServlet). In our case, we had an HTTP-based network of brokers on
an unreliable network. The brokers would constantly reconnect to each other
and eventually the client map caused an OOM.
I've reported the issue and incl
Thanks very much for the info, Gary. The hint to run the tests individually
should hopefully clear up any problems that I'm having in my environment.
--
View this message in context:
http://activemq.2283324.n4.nabble.com/AMQ-5-4-1-activemq-core-unit-test-failures-tp3029158p3029242.html
Sent fro
Hello,
I'm running "mvn test" from the root directory of my sandbox:
https://svn.apache.org/repos/asf/activemq/tags/activemq-5.4.1
The activemq-core project is failing on two unit tests and I'm wondering if
the general rule is that all unit tests should pass or is it expected that
some will fai
Hi,
We're working through some issues with the HTTP transport when connecting a
network of brokers over a periodically failing network. In the process,
I've noticed that there are two implementations of the HTTP transport:
HttpTransport and HttpClientTransport.
HttpClientTransport was made the
Dejan Bosanac wrote:
>
> You can set prefetchSize property on the network connector, which
> should help with your use case.
> See http://activemq.apache.org/networks-of-brokers.html for more details.
>
Unfortunately, setting the prefetchSize on the NetworkConnector URL does not
change the beh
> The prefetch limit determines how many messages can be sent to a
> consumer to be processed. The default value for the queue prefetch
> limit is 1000. Oftentimes this limit is fine for fast consumers that
> never slow down, but it can easily flood a slow consumer. This is why
> we recommend adju
