Hi Tim,
I used gdb along with the code and I figured out the problem. It was indeed
my
fault, an ID10T error on my part.
I constructed an invalid broker URI string.
My string was as follows:
std::string brokerURI =
"failover:(tcp://127.0.0.1:61616"
"?initialReconnectDelay=10
According to my comprehension of the JMS Spec, without transaction and
AUTO_ACKNOWLEDGE in session the disk sync should occur once a meesage is get by
the consumer; it's just like the case each message has a transaction committing?
In this case the performance of the two cases should be similar,
I'm encountering a deadlock related to throttling (producer flow control).
Here is the scenario which causes this. I receive a message from a queue,
process this message, and send a message to a different queue inside the
message handler. When throttling kicks in, this results in a deadlock. The
ne
In this case you best source of info is the code. Stepping into the
FailovetTransport start method and the reconnect method may show what is
going wrong.
On Nov 30, 2011 12:40 PM, "JRR" wrote:
> Hello Tim,
>
> I tried the test using version */3.4.0/* of ActiveMQ-CPP and the problem
> remains the
Hello Tim,
I tried the test using version */3.4.0/* of ActiveMQ-CPP and the problem
remains the same. The connection factory creates a connection even if there
is no broker running, and I've set the parameters to not try forever. Then
when start is invoked on the connection it blocks until the bro
For producers, only use transactions is you are sending more than one
message, so for batching. Jms already guarantees a disk sync when a
send returns.
For clients do what you wish.
Do try and cache connections/sessions/prodcuers
and if you have a single consumer cache that.
Remeber, transaction
the typical activemq way to do that is use an embeded vm broker and a
network connector to forward messages to the target when it can.
Disable persistence and it will use a memory store so it will be have
like a buffer.
On 29 November 2011 16:27, Joe Carter wrote:
> Hi,
>
> Does anyone know how t
On Tue, 2011-11-29 at 16:20 -0800, JRR wrote:
> Hello Tim,
>
> I am playing with the simple producer and the fail over options. However, I
> am not getting the results I expected and I'm hoping you can share some
> insights.
>
> I am using version 3.2.3 of the activemq-cpp library on a SuSE Linux
Hi,
as you are using queues, you don't have durable/non-durable
subscriptions. But it appears to me that you do NOT close the last
consumer, that's why the queue is not actually removed. You also
should NEVER need to interact with the persistence adapter.
Still, the issue is that you should NOT N
Hi,
I'm using ActiveMQQueues, that are not persisted. The subscriptions
are non-durable. I'm removing the queues from the JMX bean by calling
removeQueue (which succeeds, as they dis-appear when viewed with
JConsole) - However, when I look with a profiler, I still see
ActiveMQQueue instances layin
Hi,
first thing: does it occur while there is a consumer? Or only if there
is no consumer? Are you using queues or topics (maybe even with
persistent subscriptions)?
TTL basically works the way you expected, BUT it depends if the
messages are persistent or not, and if you have configured expired
11 matches
Mail list logo