[
https://issues.apache.org/jira/browse/QPID-7652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16182320#comment-16182320
]
Robbie Gemmell edited comment on QPID-7652 at 9/27/17 10:19 AM:
----------------------------------------------------------------
I mentioned to rob elsewhere that I didn't particularly like the appearance
that with the change (and QPIDJMS-326) the AMQP 1.0 JMS client would find
delivery-delay works by default (or always, if there is no toggle to disable
it) when using topics [subscription backing queues] and temporary queues, but
fails by default on regular queues where it arguably makes the most sense to
actually use. It seemed like it would be more consistent to have the same
default behaviour and ability to toggle it in consistent manner.
Though thinking further after I typed that, and realising in this case the
'topic' is actually an exchange, and the issue presumably also related to
exchanges already indicating that it is supported since they dont know which
queues will get the message, I now realise the existing behaviour already
differs between queues and 'topics' (the latter would allow it to be sent and
rejected) and so perhaps this would be a nicer default difference. Having the
ability to disable it tog et the current behaviour might still be good though.
Or another thing Rob is presumably going to mention shortly.
Sidenote, the same would apply for anonymous producer links (for
MessageProducer with null destination, or all JMSProducer objects since they
are inherently anonymous) which have no choice but to always say its supported,
if anything that can be sent to does support it.
was (Author: gemmellr):
I mentioned to rob elsewhere that I didn't particularly like the appearance
that with the change (and QPIDJMS-326) the AMQP 1.0 JMS client would find
delivery-delay works by default (or always, if there is no toggle to disable
it) when using topics [subscription backing queues] and temporary queues, but
fails by default on regular queues where it arguably makes the most sense to
actually use. It seemed like it would be more consistent to have the same
default behaviour and ability to toggle it in consistent manner.
Though thinking further after I typed that, and realising in this case the
'topic' is actually an exchange, and the issue presumably also related to
exchanges already indicating that it is supported since they dont know which
queues will get the message, I now realise the existing behaviour already
differs between queues and 'topics' (the latter would allow it to be sent and
rejected) and so perhaps this would be a nicer default difference. Having the
ability to disable it tog et the current behaviour might still be good though.
Or another thing Rob is presumably going to mention shortly.
Sidenote, the same would apply for anonymous producer links (for
MessageProducer with null destination, or all JMSProducer objects since they
are inherently anonymous) which have no choice but to always say its supported,
if anything that can be sent to does support it.
So that leaves the main issue as 0-x clients sending and 1.0 clients receiving
thats the issue?
> [Java Broker] Subscription queue do not have 'message holding' enabled by
> default in order to support 'message delivery delay'
> ------------------------------------------------------------------------------------------------------------------------------
>
> Key: QPID-7652
> URL: https://issues.apache.org/jira/browse/QPID-7652
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
> Reporter: Alex Rudyy
> Priority: Minor
> Fix For: Future
>
> Attachments: QPID_7652.patch
>
>
> 'Hold on publish' feature is not enabled on subscription queue. Thus, they
> currently cannot support 'message delivery delay' as specified in JMS 2.0
> spec "7.9. Message delivery delay".
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
