Hello, James.
I don't know if you're following:
https://issues.apache.org/activemq/browse/AMQ-895
But I'm having problems to compile activemq after your changes (I
suppose, as the offending file is one of the changed) trying to fix
this issue. I've posted the problems as a comment for AMQ-895 but I'm
not sure if you have seen it.
Thanks a lot.
Regards.
Manuel Teira escribió:
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
|
