Re: Message going in topic with the use of "session.createQueue(name)"
Hi Robbie And Rob, Thank you so much for details. I completely understand now, we can't do much. Thanks again. Regards, Abhishek Kumar -- Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: Temporary queues deletion
Greetings,
I tried setting lifetime-policy in qmf request and I do not see any difference.
Then I modified messenger.c (starting from line 1768) and set 'exclusive'
property there on source terminus when creating queue using '#' specifier
as follows:
if (pn_streq(name, "#")) {
pn_data_t *properties;
if (pn_link_is_sender(link)) {
pn_terminus_set_dynamic(pn_link_target(link), true);
properties = pn_terminus_properties(pn_link_target(link));
} else {
pn_terminus_set_dynamic(pn_link_source(link), true);
properties = pn_terminus_properties(pn_link_source(link));
}
pn_data_rewind(properties);
pn_data_next(properties);
if (pn_data_type(properties) == PN_EOS)
pn_data_put_map(properties);
if (pn_data_type(properties) == PN_MAP) {
static pn_bytes_t _exclusive = { 9, "exclusive" };
pn_data_enter(properties);
pn_data_put_symbol(properties, _exclusive);
pn_data_put_bool(properties, true);
pn_data_exit(properties);
}
else
pn_logf("%s: unexpected TERMINUS PROPERTIES type [%d], MAP expected",
__func__, pn_data_type(properties));
pn_data_rewind(properties);
} else {
pn_terminus_set_address(pn_link_target(link), name);
pn_terminus_set_address(pn_link_source(link), name);
}
And after that I have seen that my temporary queues started to be created
in exclusive mode, at least qpid-stat shows this:
queuedur autoDel excl msg msgIn
msgOut bytes bytesIn bytesOut cons bind
==
21948F78- . . . -70568712B_receiver-27663.0 YY1 1
0 4354350 1 1
But after clien program that has created this queue termionated, the queue
regrettably
was not deleted, but "exclusive" property was dropped instead:
queuedur autoDel excl msg msgIn
msgOut bytes bytesIn bytesOut cons bind
==
21948F78- . . . -70568712B_receiver-27663.0 Y 0 1
1 0435 435 0 1
Setting lifetime-property to delete-on-close in same way also does not make
any difference.
Any hope to get temporary queue deleted without terminating server (responder)
process?
Best regards,
On 04.07.2018 11:26, Gordon Sim wrote:
> On 03/07/18 21:15, Michael Ivanov wrote:
>> Hallo,
>>
>> I'm trying to create a queue using qmf message to qpidd cpp (1.38) as follows
>> (pseudocode, actually pn_data_* functions are used to construct the message):
>>
>> subject='broker',
>> correlation_id='1',
>> reply_to='X',
>> properties={
>> 'method': 'request'
>> 'qmf.opcode': '_method_request',
>> 'x-amqp-0-10.app-id': 'qmf2',
>> },
>> content={
>> '_object_id': {
>> '_object_name': 'org.apache.qpid.broker:broker:amqp-broker'
>> },
>> '_method_name': 'create',
>> '_arguments': {
>> 'type': 'queue',
>> 'name': u'test',
>> 'strict': True,
>> 'properties': {
>> 'auto-delete': True,
>> }
>> }
>> }
>>
>> Queue is created and auto-delete property is set, but as I understand to make
>> auto deletion actually work 'exclusive' property has to be added. Is it
>> possible using this kind of message? I tried to add 'exclusive': True to
>> message but it did not work.
>
> Try setting :
>
> 'qpid.lifetime-policy': 'delete-on-close'
>
> in the properties?
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
--
\ / | |
(OvO) | Михаил Иванов|
(^^^) | Тел.:+7(911) 223-1300|
\^/ | E-mail: iv...@isle.spb.ru |
^ ^ | |
-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
Re: [VOTE] Release Apache Qpid Proton-J 0.28.1
On 07/31/2018 12:18 PM, Robbie Gemmell wrote: Hi folks, I have put together a spin for a Qpid Proton-J 0.28.1 release, please test it and vote accordingly. The files can be grabbed from: https://dist.apache.org/repos/dist/dev/qpid/proton-j/0.28.1-rc1/ The maven artifacts are staged for now at: https://repository.apache.org/content/repositories/orgapacheqpid-1152 The JIRAs assigned are: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12313720=12343744 Regards, Robbie P.S. If you want to test things out using maven with your own build you can temporarily add this to your poms to access the staging repo: staging https://repository.apache.org/content/repositories/orgapacheqpid-1152 The dependency for proton-j would then be: org.apache.qpid proton-j 0.28.1 - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org +1 * Validated signatures and checksums * Checked binary for licensee and notice files. * Checked for license headers with 'mvn apache-rat:check' * Built source and ran the unit tests * Built Qpid JMS master branch using the staged artifact and ran the tests * Built ActiveMQ 5.x master branch using the staged artifact and ran the tests * Built ActiveMQ Artemis master branch using the staged artifact and ran the tests -- Tim Bish twitter: @tabish121 blog: http://timbish.blogspot.com/ - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: [VOTE] Release Apache Qpid Proton-J 0.27.3
On 07/31/2018 11:00 AM, Robbie Gemmell wrote: Hi folks, I have put together a spin for a Qpid Proton-J 0.27.3 release, please test it and vote accordingly. The files can be grabbed from: https://dist.apache.org/repos/dist/dev/qpid/proton-j/0.27.3-rc1/ The maven artifacts are staged for now at: https://repository.apache.org/content/repositories/orgapacheqpid-1151 The JIRAs assigned are: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12313720=12343802 Regards, Robbie P.S. If you want to test things out using maven with your own build you can temporarily add this to your poms to access the staging repo: staging https://repository.apache.org/content/repositories/orgapacheqpid-1151 The dependency for proton-j would then be: org.apache.qpid proton-j 0.27.3 - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org +1 * Validated signatures and checksums * Checked binary for licensee and notice files. * Checked for license headers with 'mvn apache-rat:check' * Built source and ran the unit tests * Built Qpid JMS master branch using the staged artifact and ran the tests * Built ActiveMQ 5.x master branch using the staged artifact and ran the tests * Built ActiveMQ Artemis master branch using the staged artifact and ran the tests -- Tim Bish twitter: @tabish121 blog: http://timbish.blogspot.com/ - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: Message going in topic with the use of "session.createQueue(name)"
On 31 July 2018 at 17:35, Rob Godfrey wrote: > On Tue, 31 Jul 2018 at 17:18, akabhishek1 > wrote: > >> Hi Rob, >> >> Thanks for your reply. I also got same comment from Robbie and Timothy. >> >> So, I raised this issue with Microsoft and they accepted this issue and >> they >> fixed issues in their SDK which is “azure-servicebus-1.2.7”. >> >> I have done testing with “azure-servicebus-1.2.7” and getting expected >> error now. They are also using "proton-j-0.22.0" internally. I don't know, >> what they have done changes to fix this issue. >> >> After applying their fixes, i am thinking there should be done form client >> side. That's why, they fixed the issue. I am sorry to say this, i don't >> have proton-j knowledge otherwise i could share technical implementation >> details with you. >> >> This is not a blocker for us but this will definitely add value in JMS Qpid >> Client. >> > > To repeat the point... there is *nothing* more the client can do. The > client doesn't / can't know about the nature of the address. The client is > saying "I expect this to be a queue". Proton-J is a generic AMQP client, > it is designed to work with the AMQP specification rather than a particular > implementation of it. If ServcieBus is not responding to the client with > either a failure to attach, or by explicitly saying "this is a topic" then > how can the client do anything else. From Microsoft's point of view they > may be able to add logic to their client libraries which depends on the > behaviour of ServiceBus, but as a generic client Qpid JMS cannot do that. > Qpid JMS relies on the system it is connecting to to respect AMQP defined > behaviours. > > -- Rob To add to Rob's message, in this case the change seemingly being referenced looks to be https://github.com/Azure/azure-service-bus-java/pull/240/files, in which a vendor-specific link-property called "com.microsoft:entity-type" is added and used by the client(+server?) in order to achieve the functionality, so that isnt something we would be making use of. Robbie - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: [VOTE] Release Apache Qpid Proton-J 0.28.1
On 31 July 2018 at 17:18, Robbie Gemmell wrote: > Hi folks, > > I have put together a spin for a Qpid Proton-J 0.28.1 release, please > test it and vote accordingly. > > The files can be grabbed from: > https://dist.apache.org/repos/dist/dev/qpid/proton-j/0.28.1-rc1/ > > The maven artifacts are staged for now at: > https://repository.apache.org/content/repositories/orgapacheqpid-1152 > > The JIRAs assigned are: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12313720=12343744 > > Regards, > Robbie > > P.S. If you want to test things out using maven with your own build > you can temporarily add this to your poms to access the staging repo: > > > > staging > > https://repository.apache.org/content/repositories/orgapacheqpid-1152 > > > > The dependency for proton-j would then be: > > > org.apache.qpid > proton-j > 0.28.1 > +1 I checked things over as follows: - Verified the signature and checksum files. - Checked for LICENCE and NOTICE files in the archives. - Verified the licence headers with mvn apache-rat:check. - Ran the build and tests from source archive. - Used the staged bits with a Qpid JMS master build and ran the tests. - Ran the JMS HelloWorld example against Qpid Broker-J 7.0.6. - Used the staged bits with the ActiveMQ 5 master build and AMQP tests. - Used the staged bits with the ActiveMQ Artemis master build and AMQP tests. Robbie - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: [VOTE] Release Apache Qpid Proton-J 0.27.3
On 31 July 2018 at 16:00, Robbie Gemmell wrote: > Hi folks, > > I have put together a spin for a Qpid Proton-J 0.27.3 release, please > test it and vote accordingly. > > The files can be grabbed from: > https://dist.apache.org/repos/dist/dev/qpid/proton-j/0.27.3-rc1/ > > The maven artifacts are staged for now at: > https://repository.apache.org/content/repositories/orgapacheqpid-1151 > > The JIRAs assigned are: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12313720=12343802 > > Regards, > Robbie > > P.S. If you want to test things out using maven with your own build > you can temporarily add this to your poms to access the staging repo: > > > > staging > > https://repository.apache.org/content/repositories/orgapacheqpid-1151 > > > > The dependency for proton-j would then be: > > > org.apache.qpid > proton-j > 0.27.3 > +1 I checked things over as follows: - Verified the signature and checksum files. - Checked for LICENCE and NOTICE files in the archives. - Verified the licence headers with mvn apache-rat:check. - Ran the build and tests from source archive. - Used the staged bits with a Qpid JMS master build and ran the tests. - Ran the JMS HelloWorld example against Qpid Broker-J 7.0.6. - Used the staged bits with the ActiveMQ 5 master build and AMQP tests. - Used the staged bits with the ActiveMQ Artemis 2.6.x build and AMQP tests. Robbie - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: Message going in topic with the use of "session.createQueue(name)"
On Tue, 31 Jul 2018 at 17:18, akabhishek1 wrote: > Hi Rob, > > Thanks for your reply. I also got same comment from Robbie and Timothy. > > So, I raised this issue with Microsoft and they accepted this issue and > they > fixed issues in their SDK which is “azure-servicebus-1.2.7”. > > I have done testing with “azure-servicebus-1.2.7” and getting expected > error now. They are also using "proton-j-0.22.0" internally. I don't know, > what they have done changes to fix this issue. > > After applying their fixes, i am thinking there should be done form client > side. That's why, they fixed the issue. I am sorry to say this, i don't > have proton-j knowledge otherwise i could share technical implementation > details with you. > > This is not a blocker for us but this will definitely add value in JMS Qpid > Client. > To repeat the point... there is *nothing* more the client can do. The client doesn't / can't know about the nature of the address. The client is saying "I expect this to be a queue". Proton-J is a generic AMQP client, it is designed to work with the AMQP specification rather than a particular implementation of it. If ServcieBus is not responding to the client with either a failure to attach, or by explicitly saying "this is a topic" then how can the client do anything else. From Microsoft's point of view they may be able to add logic to their client libraries which depends on the behaviour of ServiceBus, but as a generic client Qpid JMS cannot do that. Qpid JMS relies on the system it is connecting to to respect AMQP defined behaviours. -- Rob > Regards, > Abhishek Kumar > > > > -- > Sent from: > http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html > > - > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > For additional commands, e-mail: users-h...@qpid.apache.org > >
Re: [Broker-J] Reject overflow policy
Olivier,
Yeap, the Web Management Console needs to be changed for that.
I will look into it.
Kind Regards,
Alex
On 31 July 2018 at 15:10, VERMEULEN Olivier wrote:
> Thanks Alex, I just tested it and it works like a charm.
> One thing though, this attribute is not accessible through the graphical
> interface...
>
> Olivier
>
> -Original Message-
> From: Oleksandr Rudyy
> Sent: mardi 31 juillet 2018 15:22
> To: users@qpid.apache.org
> Subject: Re: [Broker-J] Reject overflow policy
>
> Hi Olivier,
>
> By default, Qpid exchanges drop unroutable/rejected messages.
> You can set exchange "unroutableMessageBehaviour" to "REJECT" in order to
> reject the unroutable/rejected messages:
>
> "unroutableMessageBehaviour" : "REJECT"
>
> Kind Regards,
> Alex
>
>
> On 31 July 2018 at 12:44, VERMEULEN Olivier
> wrote:
>> Hello,
>>
>> Actually I managed to reproduce my first use case where the client does not
>> receive the exception.
>> It happens when sending through a topic to a queue with REJECT policy
>> enabled.
>> The message is indeed rejected when the queue is full but the client does
>> not receive anything...
>>
>> Olivier
>>
>> -Original Message-
>> From: VERMEULEN Olivier
>> Sent: mercredi 4 juillet 2018 15:36
>> To: users@qpid.apache.org
>> Subject: RE: [Broker-J] Reject overflow policy
>>
>> Hello,
>>
>> I get the same error as you now...
>> There must have been something wrong with my use case the first time.
>> Thanks for the help and sorry for the trouble
>>
>> Olivier
>>
>> -Original Message-
>> From: Oleksandr Rudyy
>> Sent: mercredi 4 juillet 2018 14:35
>> To: users@qpid.apache.org
>> Subject: Re: [Broker-J] Reject overflow policy
>>
>> Oliver,
>>
>> I quickly tested publishing into a queue with reject policy configured using
>> jms client of version 0.11.1.
>> It worked for me: ResourceAllocationException was thrown on reaching a limit
>> for the maximum number of messages.
>>
>> Could you please enable trace logging on client (for example, using env
>> variable PN_TRACE_FRM=true) and debug logging on Broker side and repeat your
>> test in order to understand what is happening?
>> What is reported in both logs on reaching the limit?
>>
>> Kind Regards,
>> Alex
>>
>>
>> On 4 July 2018 at 11:10, VERMEULEN Olivier
>> wrote:
>>> Hello Rudyy
>>>
>>> Thanks for the detailed answer.
>>> I'm using a JMS client (qpid-jms-client 0.11.1) with a non-transacted
>>> session and no specific flags.
>>> For this use case I'm publishing directly in a standard queue.
>>>
>>> Olivier
>>>
>>> -Original Message-
>>> From: Oleksandr Rudyy
>>> Sent: mercredi 4 juillet 2018 11:08
>>> To: users@qpid.apache.org
>>> Subject: Re: [Broker-J] Reject overflow policy
>>>
>>> Hi Olivier,
>>>
>>> The broker behaviour for reject policy depends on AMQP protocol in use.
>>>
>>> With AMQP 1-0 an error "Maximum depth exceeded on 'reject-queue' :
>>> current=[count: 11, size: 5458], max=[count: 10, size: -1] [condition =
>>> amqp:resource-limit-exceeded]" is reported back as part of broker
>>> disposition for both transactional and non-transaction cases.
>>> The JMS client throws javax.jms.ResourceAllocationException on receiving
>>> the disposition with error.
>>>
>>> With AMQP 0-10 an execution exception
>>> (ExecutionException(errorCode=RESOURCE_LIMIT_EXCEEDED, description=No route
>>> for message with destination 'amq.direct' and routing key 'reject-queue' :
>>> Maximum depth exceeded on 'reject-queue' :
>>> current=[count: 11, size: 9389], max=[count: 10, size: -1]) [error
>>> code: 506(resource error)]) is sent by Broker to the client (followed by
>>> session close) when following conditions are met:
>>> * delivery property flag "discard-unroutable" is not set and transfer
>>> accept-mode is not explicit
>>> * broker amqp port attribute "closeWhenNoRoute" is set to true
>>> (default)] Otherwise,
>>> * when delivery property flag "discard-unroutable" is not set and transfer
>>> accept-mode is explicit, a message reject is sent back.
>>> * when delivery property flag "discard-unroutable" is set or amqp port
>>> attribute "closeWhenNoRoute" is false, the message is discarded with
>>> generating a broker log 'EXH-1003 : Discarded Message : Name: "{0}"
>>> Routing Key: "{1}"'
>>>
>>>
>>> With AMQP 0-8..0-91 a connection is closed with error "Maximum depth
>>> exceeded on 'reject-queue' : current=[count: 11, size: 10330],
>>> max=[count: 10, size: -1] [error code: 506(resource error)]" when following
>>> conditions are met:
>>> * transactions are used
>>> * message is mandatory
>>> * client supports broker feature "closeWhenNoRoute"
>>> * synchronous publishing is not used
>>> Otherwise,
>>> * when synchronous publishing is used, the basick.nack is sent back.
>>> * when message is mandatory or immediate, the broker sends back
>>> basic.return
>>> * when message is not mandatory and not immediate, the message is
>>> discarded with generating a broker log 'EXH-1003 : Discarded
Re: Message going in topic with the use of "session.createQueue(name)"
Hi Rob, Thanks for your reply. I also got same comment from Robbie and Timothy. So, I raised this issue with Microsoft and they accepted this issue and they fixed issues in their SDK which is “azure-servicebus-1.2.7”. I have done testing with “azure-servicebus-1.2.7” and getting expected error now. They are also using "proton-j-0.22.0" internally. I don't know, what they have done changes to fix this issue. After applying their fixes, i am thinking there should be done form client side. That's why, they fixed the issue. I am sorry to say this, i don't have proton-j knowledge otherwise i could share technical implementation details with you. This is not a blocker for us but this will definitely add value in JMS Qpid Client. Regards, Abhishek Kumar -- Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
[VOTE] Release Apache Qpid Proton-J 0.28.1
Hi folks, I have put together a spin for a Qpid Proton-J 0.28.1 release, please test it and vote accordingly. The files can be grabbed from: https://dist.apache.org/repos/dist/dev/qpid/proton-j/0.28.1-rc1/ The maven artifacts are staged for now at: https://repository.apache.org/content/repositories/orgapacheqpid-1152 The JIRAs assigned are: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12313720=12343744 Regards, Robbie P.S. If you want to test things out using maven with your own build you can temporarily add this to your poms to access the staging repo: staging https://repository.apache.org/content/repositories/orgapacheqpid-1152 The dependency for proton-j would then be: org.apache.qpid proton-j 0.28.1 - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: Message going in topic with the use of "session.createQueue(name)"
The client's responsibility is to say "I want to send to this destination
and I assert that is a queue". This is what the client does.
It is up to the server side to validate the assertion that the client is
making. The client has no information as to whether the server is lying or
not. The error you encountered was purely because of the bug on the server
(Azure) side (it was saying "your assertion is correct, is a queue"),
there is nothing more that the client can do.
-- Rob
On Tue, 31 Jul 2018 at 16:46, akabhishek1
wrote:
> Hi Tim,
>
> I have created
>
> Destination dest = session.createQueue("test-resource");
>
> I am expecting message should go in Queue and if "queue" is not available
> then throw
> exception.
>
> Current Behaviour - If "test-resource" named topic exists instead of a
> Queue
> then message is successfully delivered to topic "test-resource" instead of
> throwing exception.
>
> Feature Request - if i create Queue Destination then message should go in
> Queue and if same resource not available as Queue then throw exception.
>
> Please let me know for any concern/question.
>
> Regards,
> Abhishek Kumar
>
>
>
>
> --
> Sent from:
> http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>
Re: Message going in topic with the use of "session.createQueue(name)"
Hi Tim,
I have created
Destination dest = session.createQueue("test-resource");
I am expecting message should go in Queue and if "queue" is not available
then throw
exception.
Current Behaviour - If "test-resource" named topic exists instead of a Queue
then message is successfully delivered to topic "test-resource" instead of
throwing exception.
Feature Request - if i create Queue Destination then message should go in
Queue and if same resource not available as Queue then throw exception.
Please let me know for any concern/question.
Regards,
Abhishek Kumar
--
Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
[VOTE] Release Apache Qpid Proton-J 0.27.3
Hi folks, I have put together a spin for a Qpid Proton-J 0.27.3 release, please test it and vote accordingly. The files can be grabbed from: https://dist.apache.org/repos/dist/dev/qpid/proton-j/0.27.3-rc1/ The maven artifacts are staged for now at: https://repository.apache.org/content/repositories/orgapacheqpid-1151 The JIRAs assigned are: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12313720=12343802 Regards, Robbie P.S. If you want to test things out using maven with your own build you can temporarily add this to your poms to access the staging repo: staging https://repository.apache.org/content/repositories/orgapacheqpid-1151 The dependency for proton-j would then be: org.apache.qpid proton-j 0.27.3 - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
RE: [Broker-J] Reject overflow policy
Thanks Alex, I just tested it and it works like a charm.
One thing though, this attribute is not accessible through the graphical
interface...
Olivier
-Original Message-
From: Oleksandr Rudyy
Sent: mardi 31 juillet 2018 15:22
To: users@qpid.apache.org
Subject: Re: [Broker-J] Reject overflow policy
Hi Olivier,
By default, Qpid exchanges drop unroutable/rejected messages.
You can set exchange "unroutableMessageBehaviour" to "REJECT" in order to
reject the unroutable/rejected messages:
"unroutableMessageBehaviour" : "REJECT"
Kind Regards,
Alex
On 31 July 2018 at 12:44, VERMEULEN Olivier wrote:
> Hello,
>
> Actually I managed to reproduce my first use case where the client does not
> receive the exception.
> It happens when sending through a topic to a queue with REJECT policy enabled.
> The message is indeed rejected when the queue is full but the client does not
> receive anything...
>
> Olivier
>
> -Original Message-
> From: VERMEULEN Olivier
> Sent: mercredi 4 juillet 2018 15:36
> To: users@qpid.apache.org
> Subject: RE: [Broker-J] Reject overflow policy
>
> Hello,
>
> I get the same error as you now...
> There must have been something wrong with my use case the first time.
> Thanks for the help and sorry for the trouble
>
> Olivier
>
> -Original Message-
> From: Oleksandr Rudyy
> Sent: mercredi 4 juillet 2018 14:35
> To: users@qpid.apache.org
> Subject: Re: [Broker-J] Reject overflow policy
>
> Oliver,
>
> I quickly tested publishing into a queue with reject policy configured using
> jms client of version 0.11.1.
> It worked for me: ResourceAllocationException was thrown on reaching a limit
> for the maximum number of messages.
>
> Could you please enable trace logging on client (for example, using env
> variable PN_TRACE_FRM=true) and debug logging on Broker side and repeat your
> test in order to understand what is happening?
> What is reported in both logs on reaching the limit?
>
> Kind Regards,
> Alex
>
>
> On 4 July 2018 at 11:10, VERMEULEN Olivier
> wrote:
>> Hello Rudyy
>>
>> Thanks for the detailed answer.
>> I'm using a JMS client (qpid-jms-client 0.11.1) with a non-transacted
>> session and no specific flags.
>> For this use case I'm publishing directly in a standard queue.
>>
>> Olivier
>>
>> -Original Message-
>> From: Oleksandr Rudyy
>> Sent: mercredi 4 juillet 2018 11:08
>> To: users@qpid.apache.org
>> Subject: Re: [Broker-J] Reject overflow policy
>>
>> Hi Olivier,
>>
>> The broker behaviour for reject policy depends on AMQP protocol in use.
>>
>> With AMQP 1-0 an error "Maximum depth exceeded on 'reject-queue' :
>> current=[count: 11, size: 5458], max=[count: 10, size: -1] [condition =
>> amqp:resource-limit-exceeded]" is reported back as part of broker
>> disposition for both transactional and non-transaction cases.
>> The JMS client throws javax.jms.ResourceAllocationException on receiving the
>> disposition with error.
>>
>> With AMQP 0-10 an execution exception
>> (ExecutionException(errorCode=RESOURCE_LIMIT_EXCEEDED, description=No route
>> for message with destination 'amq.direct' and routing key 'reject-queue' :
>> Maximum depth exceeded on 'reject-queue' :
>> current=[count: 11, size: 9389], max=[count: 10, size: -1]) [error
>> code: 506(resource error)]) is sent by Broker to the client (followed by
>> session close) when following conditions are met:
>> * delivery property flag "discard-unroutable" is not set and transfer
>> accept-mode is not explicit
>> * broker amqp port attribute "closeWhenNoRoute" is set to true
>> (default)] Otherwise,
>> * when delivery property flag "discard-unroutable" is not set and transfer
>> accept-mode is explicit, a message reject is sent back.
>> * when delivery property flag "discard-unroutable" is set or amqp port
>> attribute "closeWhenNoRoute" is false, the message is discarded with
>> generating a broker log 'EXH-1003 : Discarded Message : Name: "{0}"
>> Routing Key: "{1}"'
>>
>>
>> With AMQP 0-8..0-91 a connection is closed with error "Maximum depth
>> exceeded on 'reject-queue' : current=[count: 11, size: 10330],
>> max=[count: 10, size: -1] [error code: 506(resource error)]" when following
>> conditions are met:
>> * transactions are used
>> * message is mandatory
>> * client supports broker feature "closeWhenNoRoute"
>> * synchronous publishing is not used
>> Otherwise,
>> * when synchronous publishing is used, the basick.nack is sent back.
>> * when message is mandatory or immediate, the broker sends back
>> basic.return
>> * when message is not mandatory and not immediate, the message is discarded
>> with generating a broker log 'EXH-1003 : Discarded Message :
>> Name: "{0}" Routing Key: "{1}"'
>>
>> Could you please clarify what protocol and client you are using and what
>> properties/flags are set on message transfer/publishing on client side? Do
>> you publish using transacted session? What exchange is used?
>>
>> Kind Regards,
>> Alex
>>
>>
Re: [Broker-J] Reject overflow policy
Hi Olivier,
By default, Qpid exchanges drop unroutable/rejected messages.
You can set exchange "unroutableMessageBehaviour" to "REJECT" in order
to reject the unroutable/rejected messages:
"unroutableMessageBehaviour" : "REJECT"
Kind Regards,
Alex
On 31 July 2018 at 12:44, VERMEULEN Olivier wrote:
> Hello,
>
> Actually I managed to reproduce my first use case where the client does not
> receive the exception.
> It happens when sending through a topic to a queue with REJECT policy enabled.
> The message is indeed rejected when the queue is full but the client does not
> receive anything...
>
> Olivier
>
> -Original Message-
> From: VERMEULEN Olivier
> Sent: mercredi 4 juillet 2018 15:36
> To: users@qpid.apache.org
> Subject: RE: [Broker-J] Reject overflow policy
>
> Hello,
>
> I get the same error as you now...
> There must have been something wrong with my use case the first time.
> Thanks for the help and sorry for the trouble
>
> Olivier
>
> -Original Message-
> From: Oleksandr Rudyy
> Sent: mercredi 4 juillet 2018 14:35
> To: users@qpid.apache.org
> Subject: Re: [Broker-J] Reject overflow policy
>
> Oliver,
>
> I quickly tested publishing into a queue with reject policy configured using
> jms client of version 0.11.1.
> It worked for me: ResourceAllocationException was thrown on reaching a limit
> for the maximum number of messages.
>
> Could you please enable trace logging on client (for example, using env
> variable PN_TRACE_FRM=true) and debug logging on Broker side and repeat your
> test in order to understand what is happening?
> What is reported in both logs on reaching the limit?
>
> Kind Regards,
> Alex
>
>
> On 4 July 2018 at 11:10, VERMEULEN Olivier
> wrote:
>> Hello Rudyy
>>
>> Thanks for the detailed answer.
>> I'm using a JMS client (qpid-jms-client 0.11.1) with a non-transacted
>> session and no specific flags.
>> For this use case I'm publishing directly in a standard queue.
>>
>> Olivier
>>
>> -Original Message-
>> From: Oleksandr Rudyy
>> Sent: mercredi 4 juillet 2018 11:08
>> To: users@qpid.apache.org
>> Subject: Re: [Broker-J] Reject overflow policy
>>
>> Hi Olivier,
>>
>> The broker behaviour for reject policy depends on AMQP protocol in use.
>>
>> With AMQP 1-0 an error "Maximum depth exceeded on 'reject-queue' :
>> current=[count: 11, size: 5458], max=[count: 10, size: -1] [condition =
>> amqp:resource-limit-exceeded]" is reported back as part of broker
>> disposition for both transactional and non-transaction cases.
>> The JMS client throws javax.jms.ResourceAllocationException on receiving the
>> disposition with error.
>>
>> With AMQP 0-10 an execution exception
>> (ExecutionException(errorCode=RESOURCE_LIMIT_EXCEEDED, description=No route
>> for message with destination 'amq.direct' and routing key 'reject-queue' :
>> Maximum depth exceeded on 'reject-queue' :
>> current=[count: 11, size: 9389], max=[count: 10, size: -1]) [error
>> code: 506(resource error)]) is sent by Broker to the client (followed by
>> session close) when following conditions are met:
>> * delivery property flag "discard-unroutable" is not set and transfer
>> accept-mode is not explicit
>> * broker amqp port attribute "closeWhenNoRoute" is set to true
>> (default)] Otherwise,
>> * when delivery property flag "discard-unroutable" is not set and transfer
>> accept-mode is explicit, a message reject is sent back.
>> * when delivery property flag "discard-unroutable" is set or amqp port
>> attribute "closeWhenNoRoute" is false, the message is discarded with
>> generating a broker log 'EXH-1003 : Discarded Message : Name: "{0}"
>> Routing Key: "{1}"'
>>
>>
>> With AMQP 0-8..0-91 a connection is closed with error "Maximum depth
>> exceeded on 'reject-queue' : current=[count: 11, size: 10330],
>> max=[count: 10, size: -1] [error code: 506(resource error)]" when following
>> conditions are met:
>> * transactions are used
>> * message is mandatory
>> * client supports broker feature "closeWhenNoRoute"
>> * synchronous publishing is not used
>> Otherwise,
>> * when synchronous publishing is used, the basick.nack is sent back.
>> * when message is mandatory or immediate, the broker sends back
>> basic.return
>> * when message is not mandatory and not immediate, the message is discarded
>> with generating a broker log 'EXH-1003 : Discarded Message :
>> Name: "{0}" Routing Key: "{1}"'
>>
>> Could you please clarify what protocol and client you are using and what
>> properties/flags are set on message transfer/publishing on client side? Do
>> you publish using transacted session? What exchange is used?
>>
>> Kind Regards,
>> Alex
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For
>> additional commands, e-mail: users-h...@qpid.apache.org
>>
>> ***
>>
>> This e-mail contains information for the intended recipient only. It may
>> contain proprietary
RE: [Broker-J] Reject overflow policy
Hello,
Actually I managed to reproduce my first use case where the client does not
receive the exception.
It happens when sending through a topic to a queue with REJECT policy enabled.
The message is indeed rejected when the queue is full but the client does not
receive anything...
Olivier
-Original Message-
From: VERMEULEN Olivier
Sent: mercredi 4 juillet 2018 15:36
To: users@qpid.apache.org
Subject: RE: [Broker-J] Reject overflow policy
Hello,
I get the same error as you now...
There must have been something wrong with my use case the first time.
Thanks for the help and sorry for the trouble
Olivier
-Original Message-
From: Oleksandr Rudyy
Sent: mercredi 4 juillet 2018 14:35
To: users@qpid.apache.org
Subject: Re: [Broker-J] Reject overflow policy
Oliver,
I quickly tested publishing into a queue with reject policy configured using
jms client of version 0.11.1.
It worked for me: ResourceAllocationException was thrown on reaching a limit
for the maximum number of messages.
Could you please enable trace logging on client (for example, using env
variable PN_TRACE_FRM=true) and debug logging on Broker side and repeat your
test in order to understand what is happening?
What is reported in both logs on reaching the limit?
Kind Regards,
Alex
On 4 July 2018 at 11:10, VERMEULEN Olivier wrote:
> Hello Rudyy
>
> Thanks for the detailed answer.
> I'm using a JMS client (qpid-jms-client 0.11.1) with a non-transacted session
> and no specific flags.
> For this use case I'm publishing directly in a standard queue.
>
> Olivier
>
> -Original Message-
> From: Oleksandr Rudyy
> Sent: mercredi 4 juillet 2018 11:08
> To: users@qpid.apache.org
> Subject: Re: [Broker-J] Reject overflow policy
>
> Hi Olivier,
>
> The broker behaviour for reject policy depends on AMQP protocol in use.
>
> With AMQP 1-0 an error "Maximum depth exceeded on 'reject-queue' :
> current=[count: 11, size: 5458], max=[count: 10, size: -1] [condition =
> amqp:resource-limit-exceeded]" is reported back as part of broker disposition
> for both transactional and non-transaction cases.
> The JMS client throws javax.jms.ResourceAllocationException on receiving the
> disposition with error.
>
> With AMQP 0-10 an execution exception
> (ExecutionException(errorCode=RESOURCE_LIMIT_EXCEEDED, description=No route
> for message with destination 'amq.direct' and routing key 'reject-queue' :
> Maximum depth exceeded on 'reject-queue' :
> current=[count: 11, size: 9389], max=[count: 10, size: -1]) [error
> code: 506(resource error)]) is sent by Broker to the client (followed by
> session close) when following conditions are met:
> * delivery property flag "discard-unroutable" is not set and transfer
> accept-mode is not explicit
> * broker amqp port attribute "closeWhenNoRoute" is set to true
> (default)] Otherwise,
> * when delivery property flag "discard-unroutable" is not set and transfer
> accept-mode is explicit, a message reject is sent back.
> * when delivery property flag "discard-unroutable" is set or amqp port
> attribute "closeWhenNoRoute" is false, the message is discarded with
> generating a broker log 'EXH-1003 : Discarded Message : Name: "{0}"
> Routing Key: "{1}"'
>
>
> With AMQP 0-8..0-91 a connection is closed with error "Maximum depth
> exceeded on 'reject-queue' : current=[count: 11, size: 10330],
> max=[count: 10, size: -1] [error code: 506(resource error)]" when following
> conditions are met:
> * transactions are used
> * message is mandatory
> * client supports broker feature "closeWhenNoRoute"
> * synchronous publishing is not used
> Otherwise,
> * when synchronous publishing is used, the basick.nack is sent back.
> * when message is mandatory or immediate, the broker sends back
> basic.return
> * when message is not mandatory and not immediate, the message is discarded
> with generating a broker log 'EXH-1003 : Discarded Message :
> Name: "{0}" Routing Key: "{1}"'
>
> Could you please clarify what protocol and client you are using and what
> properties/flags are set on message transfer/publishing on client side? Do
> you publish using transacted session? What exchange is used?
>
> Kind Regards,
> Alex
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For
> additional commands, e-mail: users-h...@qpid.apache.org
>
> ***
>
> This e-mail contains information for the intended recipient only. It may
> contain proprietary material or confidential information. If you are not the
> intended recipient you are not authorised to distribute, copy or use this
> e-mail or any attachment to it. Murex cannot guarantee that it is virus free
> and accepts no responsibility for any loss or damage arising from its use. If
> you have received this e-mail in error please notify immediately the sender
> and delete the original email received, any attachments and all copies from
>
