Re: Connection lost in JMS to JMS Bridge scenario.

[Manuel Teira]

James Strachan escribió: On 8/25/06, Manuel Teira <[EMAIL PROTECTED]> wrote: James Strachan escribió: > 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 > Anyway, it seems that if there are messages in the database for the SUNRECV queue, it is created by ActiveMQ on restart. With the cases: 1.-The messages are sent to the bridged broker. 2.-The messages are not sent to the bridged broker, and on a new message arriving, older are dropped. I find (2) to be a problem. I don't understand what (2) means. Could you try explain that again please? I apologize for my confusing explanation. This is the sequence of facts: 1.- SunMQ is down. I send 5 messages to the SUNRECV queue that get stored in the database. 2.- Stop ActiveMQ. The database shows 5 messages for the container 'queue://SUNRECV'. 3.- SunMQ is started. After this, ActiveMQ is started too. Now, two things can happen:   a.-ActiveMQ delivers the 5 messages stored in the DB to the SunMQ broker. This is OK, the desired situation.     b.-ActiveMQ don't deliver the messages to the SunMQ broker. What we find here is:      -The JMX console is showing the SUNRECV queue, with:        QueueSize: 5.        EnqueueCount: 0        DequeueCount: 5.          <--Strange, as if the messages where sent?        ConsumerCount: 1.      The DB is showing 5 messages for the SUNRECV queue.     SunMQ is not receiving these messages.       Restarting ActiveMQ when we reach this situation, doesn't help. For two times, the data showed by the JMX console and the number of messages stored in the database, where the same. This set of messages never got sent to SunMQ.   If under this situation, I try to send a new message to this queue:    -The message reaches SunMQ.    -The 5 older messages have dissapeared.    -The JMX console shows:       QueueSize: 0       DequeueCount: 6       EnqueueCount: 1       ConsumerCount: 1    The database has 0 messages for SUNRECV. I expect this less confusing. Situations (a) or (b) happens randomly, I think. > * 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 Well, I've found the reason for this. It's because messages sent with the JMX sendTextMessage operation are not persistent, and that's the reason they're not inserted in the database (I think). I don't follow. Persistence is defined not by the type of the message but by the deliveryMode of the MessageProducer I suppose so that the MessageProducer of whatever mechanism used by the JMX console operation to send the message is configured in a way the messages are not persistent. This is a log of error when the message comes from my external client ( persistent = true ) [ERROR][2006/08/25.11:30:56.058][ActiveMQ Session Task]failed to forward message: ActiveMQBytesMessage {commandId = 5, responseRequired = true, messageId = ID:trabucco-43872-1156498253884-1:0:1:1:1, originalDestination = null, originalTransactionId = null, producerId = ID:trabucco-43872-1156498253884-1:0:1:1, destination = queue://SUNRECV, transactionId = null, expiration = 0, timestamp = 1156498255598, arrival = 0, correlationId = null, replyTo = null, persistent = true, type = null, priority = 4, groupID = null, groupSequence = 0, targetConsumerId = null, compressed = false, userID = null, content = [EMAIL PROTECTED], marshalledProperties = null, dataStructure = null, redeliveryCounter = 0, size = 529, properties = null, readOnlyProperties = true, readOnlyBody = true} ActiveMQBytesMessage{ bytesOut = null, dataOut = null, dataIn = null }([C4064]: Cannot perform operation, producer is closed.) The same with a message generated with sendTextMessage operation of the JMX console ( persistent = false ). [DEBUG][2006/08/25.11:31:51.583][RMI TCP Connection(11)-10.95.89.20]Sending message: ActiveMQTextMessage {commandId = 0, responseRequired = false, messageId = ID:trabucco-43808-1156496710158-3:1:1:1:1, originalDestination = null, originalTransactionId = null, producerId = ID:trabucco-43808-1156496710158-3:1:1:1, destination = queue://SUNRECV, transactionId = null, expiration = 0, timestamp = 1156498311577, 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 = 0, properties = null, readOnlyProperties = true, readOnlyBody = true, text = a} > 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. I'm going to open a JIRA for this. Great