So a few things going on here.
* on a restart not all queues appear in JMX until they are actually
used. This page describes why along with explaining how to work around
this
http://incubator.apache.org/activemq/how-do-i-create-new-destinations.html
* the database is not always in sync with the broker as we use a high
performance journal; so the database is checkpointed periodically and
is usually a bit behind the broker. You can avoid this by disabling
the high performance journal (but its pretty slow to do that). Here's
an example config if you want
http://incubator.apache.org/activemq/jdbc-master-slave.html
BTW I looked at the code for the JMS bridge and if a connection is
lost with the remote broker, the bridge just stops - so no messages
should be lost. Though it will require a bounce of the broker to
reconnect.
On 8/25/06, Manuel Teira <[EMAIL PROTECTED]> wrote:
Thanks for your fast answer. Looking further into my problem, I was
inspecting the ACTIVEMQ_MSGS database table used as persistence for
messages:
Starting with the remote SunMQ down:
In the beginning:
SQL> select count(*) from ACTIVEMQ_MSGS where container='queue://SUNRECV';
COUNT(*)
----------
0
When I send a message to the queue using the JMX console queue operation
sendTextMessage, I can see the logs talking about trying to send the
message. The JMX console shows a QueueSize of 1 for SUNRECV queue, but
in the Database, I still have the same count of zero messages.
If I send a message to the queue using an external client:
SQL> select count(*) from ACTIVEMQ_MSGS where container='queue://SUNRECV';
COUNT(*)
----------
1
And the JMX console is now showing a QueueSize of 2.
Therefore, on restarting the two brokers, I find these cases:
1.-SUNRECV queue doesn't exist in ActiveMQ. This seems to be related
with the fact to have sent the messages using the JMX console.
2.-SUNRECV queue exists in ActiveMQ with the same number of messages the
DB was holding on restart. For whatever reason these messages are not
sent to SunMQ broker. When a new message hits this queue, old messages
are lost and the new one reaches SunMQ (the DequeueCount shown in the
JMX console is however right (old + new)).
3.-SUNRECV queue exists in ActiveMQ and all the messages where sent to
the SunMQ broker.
Should we consider this a different problem or the same one?
Do you think one JIRA is enough for this?
Regards.
James Strachan escribió:
> On 8/25/06, Manuel Teira <[EMAIL PROTECTED]> wrote:
>>
>> Hello and sorry for the previous message, it seems I pressed the wrong
>> button.
>>
>>
>> I'm using ActiveMQ JMS to JMS Bridge functionality to connect to a
>> SunMQ
>> JMS Broker (3.6 SP3 (Build 02-A)). I'm using two queues, an input
>> and an
>> output one, with the following configuration:
>>
>>
>> <jmsBridgeConnectors>
>> <jmsQueueConnector
>> outboundQueueConnectionFactory="#REMOTE">
>> <outboundQueueBridges>
>> <outboundQueueBridge outboundQueueName="SUNRECV"/>
>> </outboundQueueBridges>
>> <inboundQueueBridges>
>> <inboundQueueBridge inboundQueueName="SUNSEND"/>
>> </inboundQueueBridges>
>> </jmsQueueConnector>
>> </jmsBridgeConnectors>
>>
>> under ActiveMQ 4.0.1
>>
>> The system works really well until the SunMQ broker needed to be
>> restarted.
>> This is what I found:
>> 1.-ActiveMQ is not aware of the remote broker shutdown. I waited for a
>> while, but no log on ActiveMQ indicates knowledge about the new
>> situation.
>> 2.-When I send a message to the output queue SUNRECV, ActiveMQ
>> complains
>> that the producer is closed:
>>
>> [ERROR][2006/08/25.09:47:12.039][ActiveMQ Session Task]failed to
>> forward
>> message: ActiveMQTextMessage {commandId = 5, responseRequired = false,
>> messageId = ID:trabucco-43457-1156491843149-3:4:1:1:1,
>> originalDestination = null, originalTransactionId = null, producerId =
>> ID:trabucco-43457-1156491843149-3:4:1:1, destination =
>> queue://SUNRECV, transactionId = null, expiration = 0, timestamp =
>> 1156492032027, arrival = 0, correlationId = null, replyTo = null,
>> persistent
>> = false, type = null, priority = 0, groupID = null, groupSequence = 0,
>> targetConsumerId = null, compressed = false, userID = null, content =
>> null,
>> marshalledProperties = null, dataStructure = null, redeliveryCounter
>> = 0,
>> size = 2, properties = null, readOnlyProperties = true, readOnlyBody
>> = true,
>> text = 1}([C4064]: Cannot perform operation, producer is closed.)
>>
>> After this, it is automatically queueing messages without sending
>> them,
>> showing the log:
>>
>> [DEBUG][2006/08/25.09:47:42.721][RMI TCP Connection(4)-10.95.89.20]No
>> subscriptions registered, will not dispatch message at this time.
>>
>> Even if SunMQ is started again, ActiveMQ is not detecting the new
>> situation, and continues queueing messages sent to SUNRECV.
>>
>> 3.-Once I restart ActiveMQ broker (with SunMQ previously restarted) two
>> things can happen:
>> a.-ActiveMQ sends the previously queued messages to SunMQ. I can find
>> SUNRECV queue in the 'queues' section of the jmx console with the
>> correct
>> number of dequeued messages.
>> b.-ActiveMQ sends nothing to SunMQ. The jmx console doesn't show the
>> bridged queue, however, there's an advisory topic called:
>> ActiveMQ.Advisory.Consumer.Queue.SUNRECV.
>> When a new message is sent to SUNRECV, the queue is created in
>> ActiveMQ, but the old messages seems to be lost (The jmx console
>> shows 1 for
>> the Enqueue and Dequeue count and SunMQ shows one message in its queue).
>>
>>
>> This situation is far from desired. So, I would like to know:
>> -Is there any way to make ActiveMQ broker test the bridge connection
>> state?
>
> No not really
>
>> Is there any way to force a reconnection?
>
> If a send fails we should tear down and reconnect the producer. Could
> you raise a JIRA for this please?
>
>
>> -Should ActiveMQ detect the remote side shutdown?
>
> It can't really - all it can do is respond to the send/consume failing
>
--
James
-------
http://radio.weblogs.com/0112098/
