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
Some of the tests are time sensitive, but the get better all the time.
They should all run for a release and if some fail on the collective
run, they should pass when run on their own, with mvn test
-Dtest=SslBrokerServiceTest for example.
There was one failure in the last hudson run for example,
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
there should be a message logged, at info level I think, at least on
trunk I see it.
On 5 November 2010 18:13, dcheckoway wrote:
>
> Thanks Gary. I think we switched to vmQueueCursor at one point several
> weeks ago as an attempt to get better throughput...it was a desperate
> attempt that ended
Gary,
One more question...since I had configured memoryLimit="20mb" in the ">"
catch-all for queues, is 20mb the limiting factor for vmQueueCursor size, or
does some other systemUsage/memoryLimit setting control the vmQueueCursor
size limit?
Thanks,
Dan
On Fri, Nov 5, 2010 at 2:13 PM, Dan Chec
Thanks Gary. I think we switched to vmQueueCursor at one point several
weeks ago as an attempt to get better throughput...it was a desperate
attempt that ended up working (made things faster), and so we kept
vmQueueCursor enabled. I now understand that memory is the limiting factor
in this confi
The default behavior for the broker is to block a send pending
resources b/c exceeding resource limits could blow the VM with OOM,
producer flow control is about blocking producers before the client
does a send, rather than blocking on the broker, b/c blocking on the
broker will block the connectio
5.3.2, 5.4.1, and 5.5-SNAPSHOT -- doesn't matter which version, but I'm
currently running 5.5-SNAPSHOT. It's running with the stock persistence
enabled and the stock -Xmx memory settings.
PROBLEM: as consumers slow down, producers slow down -- despite
producerFlowControl explicitly being disable
...even better.
Thanks Gary
--
View this message in context:
http://activemq.2283324.n4.nabble.com/Prefetch-problem-tp3028494p3028879.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
yea, that will work, the syntax for the destination options you were
using is different from the broker uri parameters that you have
working. Some info on the original destination options syntax at :
http://activemq.apache.org/destination-options.html
On 5 November 2010 11:58, MARollins wrote:
>
...looks like I've just solved it!!
The prefetch should be set on the connection as follows...
tcp://SERVERNAME:61616?wireFormat.maxInactivityDuration=0&jms.prefetchPolicy.all=1
Thanks!!
--
View this message in context:
http://activemq.2283324.n4.nabble.com/Prefetch-problem-tp3028494p3028523
Hi,
I'm running ActiveMQ 5.3. I have a single consumer which receives (large -
up to 4MB) messages from a queue and after some checking, emails them. The
problem I have is that the prefetch doesn't seem to be working.
Because of the size of the messages and client memory limitations, I have
set
14 matches
Mail list logo
