Return-Path: X-Original-To: apmail-activemq-users-archive@www.apache.org Delivered-To: apmail-activemq-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id A3DB2FA0D for ; Tue, 9 Apr 2013 19:15:34 +0000 (UTC) Received: (qmail 9571 invoked by uid 500); 9 Apr 2013 19:15:34 -0000 Delivered-To: apmail-activemq-users-archive@activemq.apache.org Received: (qmail 9542 invoked by uid 500); 9 Apr 2013 19:15:34 -0000 Mailing-List: contact users-help@activemq.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@activemq.apache.org Delivered-To: mailing list users@activemq.apache.org Received: (qmail 9533 invoked by uid 99); 9 Apr 2013 19:15:34 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 09 Apr 2013 19:15:34 +0000 X-ASF-Spam-Status: No, hits=4.2 required=5.0 tests=HTML_MESSAGE,SPF_NEUTRAL,URI_HEX X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: 216.139.250.139 is neither permitted nor denied by domain of byteflinger@gmail.com) Received: from [216.139.250.139] (HELO joe.nabble.com) (216.139.250.139) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 09 Apr 2013 19:15:30 +0000 Received: from [192.168.236.139] (helo=joe.nabble.com) by joe.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1UPe0b-0006WK-G6 for users@activemq.apache.org; Tue, 09 Apr 2013 12:15:09 -0700 Date: Tue, 9 Apr 2013 12:15:09 -0700 (PDT) From: ByteFlinger To: users@activemq.apache.org Message-ID: In-Reply-To: References: <1365513121908-4665763.post@n4.nabble.com> Subject: Re: PrioritizedBackup slows down producers? MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_29882_28707109.1365534909490" X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_29882_28707109.1365534909490 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Thank you. As it turns out, after hours of looking around, I found out the fallacies of using Jmstemplate on plain java. It was starting whole new connections and producers for every message. AMQ's PooledConnectionFactory seems to have done the job. While still not ideal that (apparently) the same thread is being used to check the connection and send messages, things are down to a much more manageable level. Regards ByteFlinger On Apr 9, 2013 9:06 PM, "gtully [via ActiveMQ]" < ml-node+s2283324n4665780h98@n4.nabble.com> wrote: > it may be worth looking at the transportconnector (broker side) > options, updateClusterClientsOnRemove=true and > updateClusterClients=true. > I that way the client should only be aware of the priority > availability when it returns to the cluster. > > If that does not work, raise an enhancement, the sending thread should > learn about the priority broker return in an async manner and get > notified. > > patches are always welcome :-) > > > On 9 April 2013 14:12, ByteFlinger <[hidden email]> > wrote: > > > Hi > > > > I have setup a network of 2 brokers connected to each other and I am > > performing some tests towards them. > > > > I have setup prioritizedBackup so that if broker 1 goes down and later > on > > comes up again, the producers will connect themselves back to that > broker > > rather than keep sending messages to broker 2. > > > > I have noticed that as soon as I bring broker 1 down, it seems that > activemq > > will try to reconnect itself to that broker after sending every single > > message and since it takes some time to timeout (and that the same > thread > > seems to be used to reconnect thus blocking sending the next message), > that > > means that even though broker 2 is up and running, sending messages to > it > > takes considerably more time when broker 1 is down than it does > otherwise. > > > > Is this normal behavior? If so, is there any way to tweak that so that > it > > only tries to reconnect every X messages or maybe that it uses a > separate > > thread to check whether that broker is up or not? Any other suggestions > on > > how one can overcome this issue are welcome. > > > > Regards > > ByteFlinger > > > > > > > > -- > > View this message in context: > http://activemq.2283324.n4.nabble.com/PrioritizedBackup-slows-down-producers-tp4665763.html > > Sent from the ActiveMQ - User mailing list archive at Nabble.com. > > > > -- > http://redhat.com > http://blog.garytully.com > > > ------------------------------ > If you reply to this email, your message will be added to the discussion > below: > > http://activemq.2283324.n4.nabble.com/PrioritizedBackup-slows-down-producers-tp4665763p4665780.html > To unsubscribe from PrioritizedBackup slows down producers?, click here > . > NAML > -- View this message in context: http://activemq.2283324.n4.nabble.com/PrioritizedBackup-slows-down-producers-tp4665763p4665782.html Sent from the ActiveMQ - User mailing list archive at Nabble.com. ------=_Part_29882_28707109.1365534909490--