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
...looks like I've just solved it!!
The prefetch should be set on the connection as follows...
tcp://SERVERNAME:61616?wireFormat.maxInactivityDuration=0jms.prefetchPolicy.all=1
Thanks!!
--
View this message in context:
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
...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.
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
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
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
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 dchecko...@gmail.com 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
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 fail
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,
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
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
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.
FYI we
13 matches
Mail list logo
