Return-Path: Delivered-To: apmail-geronimo-activemq-users-archive@www.apache.org Received: (qmail 85834 invoked from network); 25 Aug 2006 09:15:07 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 25 Aug 2006 09:15:07 -0000 Received: (qmail 7625 invoked by uid 500); 25 Aug 2006 09:15:07 -0000 Delivered-To: apmail-geronimo-activemq-users-archive@geronimo.apache.org Received: (qmail 7434 invoked by uid 500); 25 Aug 2006 09:15:07 -0000 Mailing-List: contact activemq-users-help@geronimo.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: activemq-users@geronimo.apache.org Delivered-To: mailing list activemq-users@geronimo.apache.org Received: (qmail 7422 invoked by uid 99); 25 Aug 2006 09:15:07 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 25 Aug 2006 02:15:07 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of mteira@tid.es designates 193.145.240.2 as permitted sender) Received: from [193.145.240.2] (HELO correo.tid.es) (193.145.240.2) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 25 Aug 2006 02:15:04 -0700 Received: from tid (filvit [192.168.48.202]) by tid.hi.inet (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0J4J008VGR0JVD@tid.hi.inet> for activemq-users@geronimo.apache.org; Fri, 25 Aug 2006 11:14:43 +0200 (MEST) Received: from [10.95.89.20] by tid.hi.inet (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0J4J008V8R0IVD@tid.hi.inet> for activemq-users@geronimo.apache.org; Fri, 25 Aug 2006 11:14:43 +0200 (MEST) Date: Fri, 25 Aug 2006 11:15:21 +0200 From: Manuel Teira Subject: Re: Connection lost in JMS to JMS Bridge scenario. In-reply-to: Sender: mteira@tid.es To: activemq-users@geronimo.apache.org Message-id: <44EEBFA9.70702@tid.es> MIME-version: 1.0 Content-type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary=------------ms000003060804030404010207 User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) References: <44EEB1C9.9060107@tid.es> <44EEB917.6080303@tid.es> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N --------------ms000003060804030404010207 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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. > > * 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). > > 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. Thanks a lot. > > > On 8/25/06, Manuel Teira 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 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: >> >> >> >> >> >> >> >> > >> outboundQueueConnectionFactory="#REMOTE"> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> 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 >> > >> >> > > --------------ms000003060804030404010207 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEpjCC Ak8wggG4oAMCAQICAg8UMA0GCSqGSIb3DQEBBAUAMEwxCzAJBgNVBAYTAkVTMQwwCgYDVQQK EwNUSUQxETAPBgNVBAsTCFBlcnNvbmFsMRwwGgYDVQQDExNDRVJUSUZJQ0FETyBJTlRFUk5P MB4XDTA0MDkyOTA2NDAxN1oXDTA2MTAwNDA2NDAxN1owfzELMAkGA1UEBhMCRVMxDDAKBgNV BAoTA1RJRDERMA8GA1UECxMIUEVSU09OQUwxFjAUBgoJkiaJk/IsZAEBEwZtdGVpcmExGTAX BgNVBAMTEE1BTlVFTCBURUlSQSBQQVoxHDAaBgkqhkiG9w0BCQEWDW10ZWlyYUB0aWQuZXMw XDANBgkqhkiG9w0BAQEFAANLADBIAkEAuxxwrp96StAQmgdnKbGubkWOWmtqWoXK4mW4RPsY d0StoLZ8dqvTdwGn+4zs7Fd7JvtghH9hQFNhoLG2AMwl2QIDAQABo1EwTzAOBgNVHQ8BAf8E BAMCBeAwEQYJYIZIAYb4QgEBBAQDAgSwMB8GA1UdIwQYMBaAFCm2UVr/fsja/0H3L4IKyTaL Uww1MAkGA1UdEwQCMAAwDQYJKoZIhvcNAQEEBQADgYEAtDGRDHLiwGJa4WQLe8k9RKVxLF99 85QZPz2CjBVz8KkGMgrqYlQyaKx4QLtgf3emckBDv/SBc9g2pIcxaCaVyHBBr8UoNBhCZgAv 8BsMUxER01m69VqTPabiTyyYItSzxylPBXODz0KkNdcLFZltWqEOqsf/rI6amohMrTLvLRsw ggJPMIIBuKADAgECAgIPFDANBgkqhkiG9w0BAQQFADBMMQswCQYDVQQGEwJFUzEMMAoGA1UE ChMDVElEMREwDwYDVQQLEwhQZXJzb25hbDEcMBoGA1UEAxMTQ0VSVElGSUNBRE8gSU5URVJO TzAeFw0wNDA5MjkwNjQwMTdaFw0wNjEwMDQwNjQwMTdaMH8xCzAJBgNVBAYTAkVTMQwwCgYD VQQKEwNUSUQxETAPBgNVBAsTCFBFUlNPTkFMMRYwFAYKCZImiZPyLGQBARMGbXRlaXJhMRkw FwYDVQQDExBNQU5VRUwgVEVJUkEgUEFaMRwwGgYJKoZIhvcNAQkBFg1tdGVpcmFAdGlkLmVz MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBALsccK6fekrQEJoHZymxrm5FjlpralqFyuJluET7 GHdEraC2fHar03cBp/uM7OxXeyb7YIR/YUBTYaCxtgDMJdkCAwEAAaNRME8wDgYDVR0PAQH/ BAQDAgXgMBEGCWCGSAGG+EIBAQQEAwIEsDAfBgNVHSMEGDAWgBQptlFa/37I2v9B9y+CCsk2 i1MMNTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBAUAA4GBALQxkQxy4sBiWuFkC3vJPUSlcSxf ffOUGT89gowVc/CpBjIK6mJUMmiseEC7YH93pnJAQ7/0gXPYNqSHMWgmlchwQa/FKDQYQmYA L/AbDFMREdNZuvVakz2m4k8smCLUs8cpTwVzg89CpDXXCxWZbVqhDqrH/6yOmpqITK0y7y0b MYICNDCCAjACAQEwUjBMMQswCQYDVQQGEwJFUzEMMAoGA1UEChMDVElEMREwDwYDVQQLEwhQ ZXJzb25hbDEcMBoGA1UEAxMTQ0VSVElGSUNBRE8gSU5URVJOTwICDxQwCQYFKw4DAhoFAKCC AXkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYwODI1MDkx NTIxWjAjBgkqhkiG9w0BCQQxFgQUEQEtAcwLPT7y3BwK9nlzQjTtcjQwUgYJKoZIhvcNAQkP MUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4D AgcwDQYIKoZIhvcNAwICASgwYQYJKwYBBAGCNxAEMVQwUjBMMQswCQYDVQQGEwJFUzEMMAoG A1UEChMDVElEMREwDwYDVQQLEwhQZXJzb25hbDEcMBoGA1UEAxMTQ0VSVElGSUNBRE8gSU5U RVJOTwICDxQwYwYLKoZIhvcNAQkQAgsxVKBSMEwxCzAJBgNVBAYTAkVTMQwwCgYDVQQKEwNU SUQxETAPBgNVBAsTCFBlcnNvbmFsMRwwGgYDVQQDExNDRVJUSUZJQ0FETyBJTlRFUk5PAgIP FDANBgkqhkiG9w0BAQEFAARAqh6O1buJuy5iRB0LS6uO5Wtjb92Ps+uJpcRrBuwn4yjaxNl4 v87z/tp4kKXnJvozfPUaYH5JI6cruhkrde3zvwAAAAAAAA== --------------ms000003060804030404010207--