qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robbie Gemmell (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (QPIDJMS-230) AmqpFixedProducer created for every message sent
Date Fri, 09 Dec 2016 10:28:58 GMT

    [ https://issues.apache.org/jira/browse/QPIDJMS-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15734923#comment-15734923

Robbie Gemmell commented on QPIDJMS-230:

Whats happening is that your usage is creating an 'anonymous producer' (no destination specified
at creation), and the server isn't advertising the capability the client checks before using
an 'anonymous sending link' for this producer.

In AMQP 1.0, producer/consumer 'links' carry messages, and these are established to a source/target
with a specific address. That unfortunately doesn't play very nice with JMS 'anonymous producers'
which dont have a specific address and each send could go to a different destiantion. An extension
is used by many AMQP 1.0 servers, of treating a target with null address as an anonymous sending
link, then inspecting each message for its 'to' address and using this as the message destiantion
rather than the link address, with support advertised for this using a connection-capability

As the server is not offering this capability the client doesn't try using it, and instead
uses a fallback of opening (and by default, closing) links to the destinations as required,
which is what you are seeing. You can see this mentioned at the start of your logs: "2016-12-09
07:16:34,937 | DEBUG | Creating an AmqpAnonymousFallbackProducer ".

There was some limited support for caching these links, but I dont think it is tested and
I don't think anyones really used it before, we've considered removing it previously. I'll
need to take a look to see if its an option for you.

> AmqpFixedProducer created for every message sent
> ------------------------------------------------
>                 Key: QPIDJMS-230
>                 URL: https://issues.apache.org/jira/browse/QPIDJMS-230
>             Project: Qpid JMS
>          Issue Type: Bug
>          Components: qpid-jms-client
>    Affects Versions: 0.11.1
>            Reporter: Milan Nikl
>            Priority: Minor
>              Labels: performance
>         Attachments: amqps_frames.log, apache.qpid.log
> *Configuration:* Hi, I'm using ActiveMQ 5.14.1 to connect from a device (running linux
derivate OS) to Azure IoT Hub. With Qpid JMS client 0.11.1 and protonj 0.15.0 providing AMQPS
based JmsConnection implementation. I'm using Destination bridges to connect my local queues
to remote queues.
> *Problem description:* For every message I send to the server there is new connection
attempt made. I can see those reconnections in Azure IoT Hub monitoring, in AMQPS frames logs,
qpid log etc. And while I have the same JmsConnection instance active for the whole time,
in reality the device keeps connecting and disconnecting for each message, which presents
additional load for both IoT Hub and device. Message throughput is really affected by this
> When I try running similar code from my desktop using Qpid JMS client 0.11.1 to send
messages, it creates single AmqpFixedProducer at start and disconnects when all messages are
sent. I'm not aware of any special settings, both application use JmsConnectionFactory.setForceSyncSend(true).
> So ActiveMQ or some of its components could be blamed for this. But I would like to know
if someone has any experience with similar problem and maybe some idea how to solve it.
> Thanks!
> Attachments: In logs you can see the device connecting, then some already enqueued messages
are sent. Once the initial load is processed, one message per minute should be sent.
> Originaly filed in http://qpid.2158936.n2.nabble.com/AmqpFixedProducer-created-for-every-message-sent-td7655816.html

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org

View raw message