[
https://issues.apache.org/jira/browse/AMQ-5379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14231394#comment-14231394
]
Robbie Gemmell commented on AMQ-5379:
-------------------------------------
Hi Dejan,
I think we need to change how the credit is observed after the initial flow,
patch attached. As AMQPProtocolConverter could create the 'ActiveMQ consumer'
with a 1000 msg prefetch (if we havent already also had a Flow before the
Attach actually gets processed), it is likely it could buffer up to that many
messages sends before we ever get a Flow, at which point the way the credit is
currently observed (via getRemoteCredit()) wont actually give the amount of
credit we received but rather what is currently believed to be left unused
after accounting for buffered messages, leading us to underestimate the actual
prefetch (it could even be negative if it already buffered sends for more
messages than the actual received credit). I think getCredit() seems to be what
to use instead.
Having said all that, I am now also thinking that a better way to go for now
might be creating the 'ActiveMQ consumer' with 0 prefetch until the first flow
arrives, and then giving it that much prefetch, since the AMQP consumer
cant/wont actually be sent any messages over the wire until it gives the
broker/proton credit anyway. This would help with multiple consumers etc by
avoiding the 'ActiveMQ consumers' prefetching lots of messages they cant
actually transmit to the AMQP consumer yet.
The above may possibly make the general issue underlying AMQ-5453 a little
worse, since the 'ActiveMQ consumer' wouldnt have any 'advance credit' to use
to get messages buffered ready to send before a 'drain' flow occurs. As it is
currently almost entirely broken anyway, I'm not sure this would really be much
more of an issue than already exists, which will still need a general fix
either way. A possible saving grace in this specific case though is that I see
that client is sending two flows, one with drain false then one with it true,
which might still appear to work occasionally if messages get sent inbetween
them.
I think the changes here mean that anyone using ClientAcknowledge with the JMS
clients will find it isnt able to recieve more messages than the consumers
configured prefetch size within a single ack window, since the desire for more
messages is communicated by granting more credit, which would now have no
effect. That in itself isnt necessarily worse than it was in ActiveMQ 5.10,
which had an internal fixed window of 100 messages, the only difference is that
if AMQP clients set their prefetch down below the old fixed 100 (e.g, to 1)
they then wont be able to exceed that, whereas previously they would have
apparently been able to since up to 99 messages would have actually been
buffered awaiting the new credit. I guess that by using the new
'transport.prefetch' config to set a value will essentially force it to behave
as it did previously, which may be a workaround in some cases.
When looking an issue relating to transactions, I came across the 'prefetch
extension' concept in PrefetchSubscription. It currently looks to mainly use
acknowlegement of specific messages to operate, but perhaps it could be
modified to use credit (since we cant tell which specific messages, if any,
that incoming credit may have been previously associated with) and help toward
enabling things to work more along the lines of expectation for AMQP.
Sorry for writing another book size comment, I really dont mean to when I start
:P
Robbie
> AMQP - allow setting prefetch size
> ----------------------------------
>
> Key: AMQ-5379
> URL: https://issues.apache.org/jira/browse/AMQ-5379
> Project: ActiveMQ
> Issue Type: Bug
> Components: AMQP
> Affects Versions: 5.10.0
> Reporter: Dejan Bosanac
> Assignee: Dejan Bosanac
> Fix For: 5.11.0
>
>
> Currently the prefetch size is hardcoded to the value of 100
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
