activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ByteFlinger <byteflin...@gmail.com>
Subject Re: PrioritizedBackup slows down producers?
Date Tue, 09 Apr 2013 19:15:09 GMT
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]<http://user/SendEmail.jtp?type=node&node=4665780&i=0>>
> 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<http://activemq.2283324.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4665763&code=Ynl0ZWZsaW5nZXJAZ21haWwuY29tfDQ2NjU3NjN8LTExMDA3NjUyMzg=>
> .
> NAML<http://activemq.2283324.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.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.
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message