Re: Test message redelivery with qpid-receive

[Gordon Sim]

On 22/01/18 17:03, Jan Bares, WOOD & Co. wrote:

Hi,

Can I test message redelivery with qpid-receive? I would like to seem message 
delivered to alternate queue (DLQ), how can I tell qpid-receive to reject a 
message?


It has no support for issuing a reject.

-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Test message redelivery with qpid-receive

[Jan Bares, WOOD & Co.]

Hi,

Can I test message redelivery with qpid-receive? I would like to seem message 
delivered to alternate queue (DLQ), how can I tell qpid-receive to reject a 
message?

Thank you for your time, Jan

Jan Bares
Calypso / Java Lead Developer

Hradecka 10
Czech Republic
Mobile: +420 776 333 676

In association with
WOOD & Company Financial Services, a.s.
http://www.wood.cz



DISCLAIMER

 WOOD & Company Financial Services, a.s. and its branches are 
authorized and regulated by the CNB as Home State regulator and in Poland by 
the KNF, in Slovakia by the NBS, in Italy by the CONSOB and in the UK by the 
FCA as Host State regulators. For further information about WOOD & Co., its 
investment services, financial instruments and associated risks, safeguard 
client assets (incl. compensation schemes) and contractual relationship please 
see our website at www.wood.com under section Corporate 
Governance.
 Unless otherwise stated, this transmission is neither an offer nor the 
solicitation of an offer to sell or purchase any investment. All estimates, 
opinions and other information contained herein are subject to change without 
notice and are provided in good faith but without legal responsibility or 
liability. Opinion may be personal to the author and may not reflect the 
opinions of WOOD & Co. Communications from sales persons, sales traders or 
traders should not be regarded as investment research and may contain opinions 
or trading ideas which are different from WOOD & Co. investment research 
opinions.
 This e-mail and any attachments are confidential and may be privileged 
or otherwise protected from disclosure. If you are not a named addressee you 
must not use, disclose, distribute, copy, print or rely on this e-mail and any 
of its attachments. Please notify the sender that you have received this email 
by mistake by replying to the email, and then delete the email and any copies 
of it. Although WOOD & Co. routinely screens e-mails for viruses, addressees 
should scan this e-mail and any attachments for viruses. WOOD & Co. makes no 
representation or warranty as to the absence of viruses in this e-mail or any 
attachments. Please note that to ensure regulatory compliance and for the 
protection of our clients and business, we may monitor and read e-mails sent to 
and from our server(s).


-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Re: Java Broker performance

[Oleksandr Rudyy]

Hi Tomas,

We are currently looking into performance improvements for the Receiver.
We will notify you after necessary changes are made and ready for testing.

Kind Regards,
Alex



On 22 January 2018 at 11:20, Tomas Soltys  wrote:
> Hi Keith,
>
> I can confirm that sending is now much faster.
>
> *C++ broker*
> $ ./Broadcaster 20001
> real0m0.085s
> user0m0.027s
> sys 0m0.005s
>
> *Java broker*
> $ ./Broadcaster 20002
> real0m0.876s
> user0m0.037s
> sys 0m0.011s
>
> However receiving is still much slower.
>
> *C++ broker*
> $ time ./Receiver 20001
> real0m0.113s
> user0m0.035s
> sys 0m0.014s
>
> *Java broker*
> $ time ./Receiver 20002
> real0m50.168s
> user0m0.061s
> sys 0m0.032s
>
> See attached file  cpp_vs_java.gz
>    which
> contains:
> Broadcaster.cpp and Receiver.cpp based on qpid-proton 0.19.0
> Setup for C++ broker 1.37.0
> Setup for Java broker (master from 22-nd January 2017)
>
> Regards,
> Tomas
>
>
>
>
> --
> 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
>

-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

RE: C++ broker flow to disk

[Jan Bares, WOOD & Co.]

Thank you Gordon for the pointers, I have found some more documentation from 
Jakub Scholz in list archive.

Kind regards, Jan

> -Original Message-
> From: Gordon Sim [mailto:g...@redhat.com]
> Sent: Monday, January 22, 2018 4:42 PM
> To: users@qpid.apache.org
> Subject: Re: C++ broker flow to disk
>
> On 22/01/18 14:55, Jan Bares, WOOD & Co. wrote:
> > I get
> >
> > qpid-config: error: option --limit-policy: invalid choice:
> > 'flow-to-disk' (choose from 'none', 'reject', 'ring', 'ring-strict')
> >
> > with latest qpid c++ broker 1.37.0. Should I configure some module or is 
> > this
> feature no longer supported? As
> https://issues.apache.org/jira/browse/QPID-4339 says, it was removed in
> 0.19 and reimplemented in 0.23.
>
> It is no longer implemented in that form and with that name. There is a
> 'paging' mechanism that is considered a replacement.
>
> Paging is enabled for a queue by setting "qpid.paging" to true. It can be
> tuned via "qpid.max_pages_loaded", which determines how many pages can
> be kept in memory and "qpid.page_factor" which controls the page size as a
> multiple of the platform default page size).
>
> Note that this mechanism is entirely orthogonal to persistence.
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional
> commands, e-mail: users-h...@qpid.apache.org


Jan Bares
Calypso / Java Lead Developer

Hradecka 10
Czech Republic
Mobile: +420 776 333 676

In association with
WOOD & Company Financial Services, a.s.
http://www.wood.cz



DISCLAIMER

 WOOD & Company Financial Services, a.s. and its branches are 
authorized and regulated by the CNB as Home State regulator and in Poland by 
the KNF, in Slovakia by the NBS, in Italy by the CONSOB and in the UK by the 
FCA as Host State regulators. For further information about WOOD & Co., its 
investment services, financial instruments and associated risks, safeguard 
client assets (incl. compensation schemes) and contractual relationship please 
see our website at www.wood.com under section Corporate 
Governance.
 Unless otherwise stated, this transmission is neither an offer nor the 
solicitation of an offer to sell or purchase any investment. All estimates, 
opinions and other information contained herein are subject to change without 
notice and are provided in good faith but without legal responsibility or 
liability. Opinion may be personal to the author and may not reflect the 
opinions of WOOD & Co. Communications from sales persons, sales traders or 
traders should not be regarded as investment research and may contain opinions 
or trading ideas which are different from WOOD & Co. investment research 
opinions.
 This e-mail and any attachments are confidential and may be privileged 
or otherwise protected from disclosure. If you are not a named addressee you 
must not use, disclose, distribute, copy, print or rely on this e-mail and any 
of its attachments. Please notify the sender that you have received this email 
by mistake by replying to the email, and then delete the email and any copies 
of it. Although WOOD & Co. routinely screens e-mails for viruses, addressees 
should scan this e-mail and any attachments for viruses. WOOD & Co. makes no 
representation or warranty as to the absence of viruses in this e-mail or any 
attachments. Please note that to ensure regulatory compliance and for the 
protection of our clients and business, we may monitor and read e-mails sent to 
and from our server(s).

Re: C++ broker flow to disk

[Gordon Sim]

On 22/01/18 14:55, Jan Bares, WOOD & Co. wrote:

I get

qpid-config: error: option --limit-policy: invalid choice: 'flow-to-disk' 
(choose from 'none', 'reject', 'ring', 'ring-strict')

with latest qpid c++ broker 1.37.0. Should I configure some module or is this 
feature no longer supported? As https://issues.apache.org/jira/browse/QPID-4339 
says, it was removed in 0.19 and reimplemented in 0.23.


It is no longer implemented in that form and with that name. There is a 
'paging' mechanism that is considered a replacement.


Paging is enabled for a queue by setting "qpid.paging" to true. It can 
be tuned via "qpid.max_pages_loaded", which determines how many pages 
can be kept in memory and "qpid.page_factor" which controls the page 
size as a multiple of the platform default page size).


Note that this mechanism is entirely orthogonal to persistence.


-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Re: Bidirectional route combined with binding to queue

[Gordon Sim]

On 22/01/18 15:05, andi welchlin wrote:

Qpid.trace.id would be found in the message header, I think.


Correct (with AMQP 1.0 it's in the message-annotations)


So this would break anonymity.


If by anonymity you mean there can be no way to distinguish which broker 
it arrived at first, then this would not meet that. You could use a 
fairly opaque id however (e.g. a uuid) which would make it less obvious, 
but it would still be possible to see which messages originated at the 
same broker.



Any ideas?


Unfortunately this is the only mechanism built into the c++ broker that 
would prevent message looping.


-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Re: Bidirectional route combined with binding to queue

[andi welchlin]

Hello Gordon,

thank you for your answer.

I forgot to mention that messages need to be anonymous in my environment,
as well :-)

Qpid.trace.id would be found in the message header, I think. So this would
break anonymity.

Any ideas?

Kind Regards,
Andreas



On Mon, Jan 22, 2018 at 3:13 PM, Gordon Sim  wrote:

> On 22/01/18 13:24, andi welchlin wrote:
>
>> Hello all,
>>
>> I want to share an exchange between two brokers (bidirectional).
>>
>> I understood that the right way to do this is using a dynamic route like:
>>
>> qpid-route dynamic add $broker1 $broker2 $exchange_name
>> qpid-route dynamic add $broker2 $broker1 $exchange_name
>>
>>
>> I also want to achieve that no messages will be lost when one of the
>> two brokers is down while messages are sent to the other broker.
>>
>> So I would bind a queue ($queue_out) to $exchange_name on both brokers.
>> Then I would route on each broker $queue_out to the exchange of the remote
>> broker.
>>
>> As far as I understood a dynamic route is then not possible any more.
>>
>> It would look like:
>>
>> # install binding from exchange to output queue
>> qpid-config -b $BROKER1 bind $exchange_name $queue_out
>> qpid-config -b $BROKER2 bind $exchange_name $queue_out
>>
>> # install route
>> qpid-route -d queue add $BROKER2 $BROKER1 $exchange_name $queue_out
>> qpid-route -d queue add $BROKER1 $BROKER2 $exchange_name $queue_out
>> qpid-route route map $BROKER2
>>
>>
>> But this seems to lead to circular messages.
>>
>> Does anyone have a solution for this scenario?
>>
>
> You can use the "qpid.trace.id" and "qpid.trace.exclude" queue options
> for this.
>
> For each of the two forwarding queues, set the id to the name of the
> broker the queue is on and set the excludes to a list containing the other
> brokers id.
>
> That way messages from the other broker are not enqueued on the forwarding
> queue, so will not get forwarded back.
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>

C++ broker flow to disk

[Jan Bares, WOOD & Co.]

Hi,

I get

qpid-config: error: option --limit-policy: invalid choice: 'flow-to-disk' 
(choose from 'none', 'reject', 'ring', 'ring-strict')

with latest qpid c++ broker 1.37.0. Should I configure some module or is this 
feature no longer supported? As https://issues.apache.org/jira/browse/QPID-4339 
says, it was removed in 0.19 and reimplemented in 0.23.

Kind regards, Jan

Jan Bares
Calypso / Java Lead Developer

Hradecka 10
Czech Republic
Mobile: +420 776 333 676

In association with
WOOD & Company Financial Services, a.s.
http://www.wood.cz



DISCLAIMER

 WOOD & Company Financial Services, a.s. and its branches are 
authorized and regulated by the CNB as Home State regulator and in Poland by 
the KNF, in Slovakia by the NBS, in Italy by the CONSOB and in the UK by the 
FCA as Host State regulators. For further information about WOOD & Co., its 
investment services, financial instruments and associated risks, safeguard 
client assets (incl. compensation schemes) and contractual relationship please 
see our website at www.wood.com under section Corporate 
Governance.
 Unless otherwise stated, this transmission is neither an offer nor the 
solicitation of an offer to sell or purchase any investment. All estimates, 
opinions and other information contained herein are subject to change without 
notice and are provided in good faith but without legal responsibility or 
liability. Opinion may be personal to the author and may not reflect the 
opinions of WOOD & Co. Communications from sales persons, sales traders or 
traders should not be regarded as investment research and may contain opinions 
or trading ideas which are different from WOOD & Co. investment research 
opinions.
 This e-mail and any attachments are confidential and may be privileged 
or otherwise protected from disclosure. If you are not a named addressee you 
must not use, disclose, distribute, copy, print or rely on this e-mail and any 
of its attachments. Please notify the sender that you have received this email 
by mistake by replying to the email, and then delete the email and any copies 
of it. Although WOOD & Co. routinely screens e-mails for viruses, addressees 
should scan this e-mail and any attachments for viruses. WOOD & Co. makes no 
representation or warranty as to the absence of viruses in this e-mail or any 
attachments. Please note that to ensure regulatory compliance and for the 
protection of our clients and business, we may monitor and read e-mails sent to 
and from our server(s).


-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Re: New user questions: Broker/AMQP versions

[Chris Richardson]

On 22 January 2018 at 14:17, Justin Ross  wrote:

> On Mon, Jan 22, 2018 at 6:05 AM, gewesp  wrote:
>
> > Hi all,
> >
> > I'm consulting with a company in the security business and we're
> evaluating
> > the use of QPID as a messaging platform.
> >
> > Q1: Supported AMQP versions of the C++ broker (qpidd):
> > * According to   https://qpid.apache.org/components/cpp-broker/index.
> html
> >    ,
> > it supports 0-10 and 1.0.
> > * According to
> > https://qpid.apache.org/releases/qpid-cpp-1.37.0/cpp-broker/book/AMQP-
> > Compatibility.html
> >  > Compatibility.html>
> > ,
> > it supports 0-9 and 0-10 .
> > Which one is it?
> >
>
> The former, 0-10 and 1.0.  The C++ broker book needs a lot of work!
>
>
> > Q2: APIs:  As far as I understand, there are two C++ APIs (Messaging and
> > Proton).  Which one of
> > these is the preferred one and will be supported in the long run?
> >
> > Q3: Python3 support: AFAICS, there is Python3 support for the Proton API,
> > but not for Messaging (neither
> > is it planned?).  Can I deduce from that that the Proton API is the
> > preferred one?
> >
>
> Yes, Proton is the way to go.
>
>
> > FWIW, we're using Ubuntu 16.04 (LTS) and we'd like to go with standard
> > Ubuntu packages
> > as far as practicable.  The project requires the use of AMQP 1.0.
> >
>
> The best way to get recent Qpid in Ubuntu is the Qpid PPA.  The default
> distro packages tend to be really old.
>
> https://launchpad.net/~qpid/+archive/ubuntu/released


Apropos the PPA, we are eagerly anticipating the addition of packages for
Proton 18/19 and Qpid-cpp 1.37  :)




-- 

*Chris Richardson*, System Architect
c...@fourc.eu


*FourC AS, Vestre Rosten 81, Trekanten, NO-7075 Tiller, Norwaywww.fourc.eu
*

*Follow us on LinkedIn , Facebook
, Google+  and Twitter
!*

Re: New user questions: Broker/AMQP versions

[Gordon Sim]

On 22/01/18 14:05, gewesp wrote:

I'm consulting with a company in the security business and we're evaluating
the use of QPID as a messaging platform.

Q1: Supported AMQP versions of the C++ broker (qpidd):
* According to   https://qpid.apache.org/components/cpp-broker/index.html
   ,
it supports 0-10 and 1.0.
* According to
https://qpid.apache.org/releases/qpid-cpp-1.37.0/cpp-broker/book/AMQP-Compatibility.html

,
it supports 0-9 and 0-10 .
Which one is it?


0-10 and 1.0


Q2: APIs:  As far as I understand, there are two C++ APIs (Messaging and
Proton).  Which one of
these is the preferred one and will be supported in the long run?


I would say the proton one.


Q3: Python3 support: AFAICS, there is Python3 support for the Proton API,
but not for Messaging (neither
is it planned?).  Can I deduce from that that the Proton API is the
preferred one?


Yes (the qpid.messaging python client does not support AMQP 1.0)


FWIW, we're using Ubuntu 16.04 (LTS) and we'd like to go with standard
Ubuntu packages
as far as practicable.  The project requires the use of AMQP 1.0.


-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Re: New user questions: Broker/AMQP versions

[Justin Ross]

On Mon, Jan 22, 2018 at 6:05 AM, gewesp  wrote:

> Hi all,
>
> I'm consulting with a company in the security business and we're evaluating
> the use of QPID as a messaging platform.
>
> Q1: Supported AMQP versions of the C++ broker (qpidd):
> * According to   https://qpid.apache.org/components/cpp-broker/index.html
>    ,
> it supports 0-10 and 1.0.
> * According to
> https://qpid.apache.org/releases/qpid-cpp-1.37.0/cpp-broker/book/AMQP-
> Compatibility.html
>  Compatibility.html>
> ,
> it supports 0-9 and 0-10 .
> Which one is it?
>

The former, 0-10 and 1.0.  The C++ broker book needs a lot of work!


> Q2: APIs:  As far as I understand, there are two C++ APIs (Messaging and
> Proton).  Which one of
> these is the preferred one and will be supported in the long run?
>
> Q3: Python3 support: AFAICS, there is Python3 support for the Proton API,
> but not for Messaging (neither
> is it planned?).  Can I deduce from that that the Proton API is the
> preferred one?
>

Yes, Proton is the way to go.


> FWIW, we're using Ubuntu 16.04 (LTS) and we'd like to go with standard
> Ubuntu packages
> as far as practicable.  The project requires the use of AMQP 1.0.
>

The best way to get recent Qpid in Ubuntu is the Qpid PPA.  The default
distro packages tend to be really old.

https://launchpad.net/~qpid/+archive/ubuntu/released

Re: Bidirectional route combined with binding to queue

[Gordon Sim]

On 22/01/18 13:24, andi welchlin wrote:

Hello all,

I want to share an exchange between two brokers (bidirectional).

I understood that the right way to do this is using a dynamic route like:

qpid-route dynamic add $broker1 $broker2 $exchange_name
qpid-route dynamic add $broker2 $broker1 $exchange_name


I also want to achieve that no messages will be lost when one of the
two brokers is down while messages are sent to the other broker.

So I would bind a queue ($queue_out) to $exchange_name on both brokers.
Then I would route on each broker $queue_out to the exchange of the remote
broker.

As far as I understood a dynamic route is then not possible any more.

It would look like:

# install binding from exchange to output queue
qpid-config -b $BROKER1 bind $exchange_name $queue_out
qpid-config -b $BROKER2 bind $exchange_name $queue_out

# install route
qpid-route -d queue add $BROKER2 $BROKER1 $exchange_name $queue_out
qpid-route -d queue add $BROKER1 $BROKER2 $exchange_name $queue_out
qpid-route route map $BROKER2


But this seems to lead to circular messages.

Does anyone have a solution for this scenario?


You can use the "qpid.trace.id" and "qpid.trace.exclude" queue options 
for this.


For each of the two forwarding queues, set the id to the name of the 
broker the queue is on and set the excludes to a list containing the 
other brokers id.


That way messages from the other broker are not enqueued on the 
forwarding queue, so will not get forwarded back.



-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

New user questions: Broker/AMQP versions

[gewesp]

Hi all,

I'm consulting with a company in the security business and we're evaluating
the use of QPID as a messaging platform.

Q1: Supported AMQP versions of the C++ broker (qpidd):
* According to   https://qpid.apache.org/components/cpp-broker/index.html
   ,
it supports 0-10 and 1.0.
* According to 
https://qpid.apache.org/releases/qpid-cpp-1.37.0/cpp-broker/book/AMQP-Compatibility.html

  
,
it supports 0-9 and 0-10 .
Which one is it?

Q2: APIs:  As far as I understand, there are two C++ APIs (Messaging and
Proton).  Which one of 
these is the preferred one and will be supported in the long run?

Q3: Python3 support: AFAICS, there is Python3 support for the Proton API,
but not for Messaging (neither
is it planned?).  Can I deduce from that that the Proton API is the
preferred one?

FWIW, we're using Ubuntu 16.04 (LTS) and we'd like to go with standard
Ubuntu packages
as far as practicable.  The project requires the use of AMQP 1.0.

Thanks for any insights!

Best
--Gerhard Wesp
http://www.kisstech.ch/   



--
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

Bidirectional route combined with binding to queue

[andi welchlin]

Hello all,

I want to share an exchange between two brokers (bidirectional).

I understood that the right way to do this is using a dynamic route like:

qpid-route dynamic add $broker1 $broker2 $exchange_name
qpid-route dynamic add $broker2 $broker1 $exchange_name


I also want to achieve that no messages will be lost when one of the
two brokers is down while messages are sent to the other broker.

So I would bind a queue ($queue_out) to $exchange_name on both brokers.
Then I would route on each broker $queue_out to the exchange of the remote
broker.

As far as I understood a dynamic route is then not possible any more.

It would look like:

# install binding from exchange to output queue
qpid-config -b $BROKER1 bind $exchange_name $queue_out
qpid-config -b $BROKER2 bind $exchange_name $queue_out

# install route
qpid-route -d queue add $BROKER2 $BROKER1 $exchange_name $queue_out
qpid-route -d queue add $BROKER1 $BROKER2 $exchange_name $queue_out
qpid-route route map $BROKER2


But this seems to lead to circular messages.

Does anyone have a solution for this scenario?

Kind Regards,
Andreas

[RESULT] [VOTE] Release Apache Qpid JMS 0.29.0

[Robbie Gemmell]

There were 6 binding +1 votes, and no other votes received. The vote has passed.

I will add the archives to the dist release repo and release the maven
staging repo shortly. The website will be updated once the artifacts
have had time to sync to the mirrors and maven central.

Robbie

-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Re: Java Broker performance

[Tomas Soltys]

Hi Keith,

I can confirm that sending is now much faster.

*C++ broker*
$ ./Broadcaster 20001
real0m0.085s
user0m0.027s
sys 0m0.005s

*Java broker*
$ ./Broadcaster 20002
real0m0.876s
user0m0.037s
sys 0m0.011s

However receiving is still much slower.

*C++ broker*
$ time ./Receiver 20001
real0m0.113s
user0m0.035s
sys 0m0.014s

*Java broker*
$ time ./Receiver 20002
real0m50.168s
user0m0.061s
sys 0m0.032s

See attached file  cpp_vs_java.gz
   which
contains:
Broadcaster.cpp and Receiver.cpp based on qpid-proton 0.19.0
Setup for C++ broker 1.37.0
Setup for Java broker (master from 22-nd January 2017)

Regards,
Tomas




--
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