Re: Java Broker performance

[Keith W]

The test is sending persistent messages so the broker is obliged to
write them to disk.  After the arrival of each message transfer, the
Broker-J awaits the sync'd to disk (after the write) before sending
the Disposition performative back to the client.  The Qpid JMS Client
is awaiting the Disposition, so it is only then that the
MessageProducer#send returns and the application can send the next
message.   I infer that CPP Broker must be optimistically sending the
Disposition back to the client before the data is sync'd, so that is
why you see better performance (but with a lesser guarantee).   If you
were to switch the Qpid JMS Client to jms.forceAsyncSend[1], I would
expect you would see greater performance.   Let me ask a higher level
question - what messaging guarantee does this application require?

[1] https://qpid.apache.org/releases/qpid-jms-0.27.0/docs/index.html

On 10 November 2017 at 15:50, Rob Godfrey  wrote:
> On 10 November 2017 at 16:39, Vavricka  wrote:
>
>> Hi,
>>
>> hardware:
>> * Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz
>> * 16 GB RAM
>> * HDD ST500DM002-1BD142
>>
>> timings:
>> Currently Java Broker 6.1.1 seems to behave as version 7.0.0 RC. 10 - 30
>> messages per second. Interesting is when I increase message size to 10kB.
>> Messages per second are same but throughput is increased ten times.
>> When I use nonpersistent messages everything goes smooth. Thousand of 1kB
>> messages are sent within 1 second.
>>
>
> So, this is more what I would expect (in the sense that 6.1 will behave
> like 7.0 - the performance is unacceptable, but I think I understand it).
>
> I *think* the issue is that we have not yet implemented the optimisations
> in the 1.0 layer for non-transactional durable messages to be processed
> asynchronously.  Because of this the rate of message processing is
> dependent upon how many times fsync() can be called a second.  500/s is
> probably about right for a SAN, ~20 is what I saw from conventional hard
> drives; for SSDs with a battery backed write cache I've gotten > 1000/s.
> Because it is dependent upon the number of fsyncs rather than the
> throughput of the disk, increasing the message size will not affect the
> rate and thus you will see a linear improvement in throughput.
>
> Fixing this shouldn't actually be a huge change, and after it you should
> see something more like the C++ broker behaviour.  Since this isn't (I
> think) a regression between 7.0 and 6.1 I'd suggest that we progress with
> the 7.0 release and then quickly follow that with a 7.0.1 that introduces
> the necessary optimisation (we can essentially copy over the code from the
> 0-x protocol layers).
>
> -- Rob
>
>
>>
>> There are no extra JVM options, just the ones which are present in
>> bin/qpid-server file.
>>
>> Heap and direct memory on broker is also default - -Xmx512m
>> -XX:MaxDirectMemorySize=1536m. I tried to increase to four times larger
>> ones
>> -Xmx2048m -XX:MaxDirectMemorySize=6000m, but there was no change in
>> messages
>> per second.
>>
>> Unfortunately vmstat gives same values pro CPU, I am sending at least top
>> output.
>>
>> 6.1.1:
>> %Cpu(s):  6.9 us,  0.3 sy,  0.0 ni, 68.5 id, 24.1 wa,  0.0 hi,  0.2 si,
>> 0.0
>> st
>>
>> 7.0.0:
>> %Cpu(s):  2.4 us,  0.4 sy,  0.0 ni, 71.2 id, 25.9 wa,  0.0 hi,  0.0 si,
>> 0.0
>> st
>>
>> When we tried on server where message store was stored on SAN disk, sending
>> of messages increased to 500 msg/sec. With C++ broker on same machine we
>> are
>> able to send 5000 msg/sec.
>>
>> ps. I cannot create queue in 7.0.0 version by webgui when queue contains
>> '.'
>> character, in 6.1.1 version queue with dot in name can be created by webgui
>>
>>
>> Keith Wall wrote
>> > Hi Tomas,
>> >
>> > Nor can I reproduce any discernible difference in performance between
>> > 6.1.1 and the 7.0.0 RC with your Java code.  I have not tried the C++
>> > yet.
>> >
>> > Can you share with us:
>> >
>> > * details of the hardware (including the storage) you are using for the
>> > test.
>> > * the timings you seeing for your tests for both the 6.1.1 case and 7.0.0
>> > RC
>> > * any extra JVM options you are passing either client or broker side.
>> > * size of java heap (client side) and heap and direct memory (broker)
>> >
>> > Can I suggest that you collect vmstat type information for both runs
>> > and compare?   My expectation is that CPU usage, disk I/O, and network
>> > utilisation should be approximately equal between the two runs.
>> >
>> > cheers, Keith
>>
>>
>>
>>
>>
>> --
>> 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 

Re: Electron/Amqp MessageAnnotations in Golang

[Alan Conway]

On Fri, Nov 10, 2017 at 8:28 AM, Jiri Danek < jda...@redhat.com > wrote:

> On Fri, Nov 10, 2017 at 1:10 PM, Alessio Gottardo
>  > wrote:
> >
> > Out of curiosity is there a specific reason for `panic`ing in the
> > `default` case instead of returning an `error`?I just became aware of
> this
> > `recover` mechanism in go to handle a runtime `panic` thrown somewhere
> > else, but that's going to make the code quite a bit more complicated. I
> was
> > wondering if it would have been easier to return an error to whoever uses
> > the `amqp` go wrapper, but I see that could have quite of an impact on
> the
> > codebase as it is at the moment.
> > Thank you for the fix.Alessio
> >
>
> I was thinking the same thing.I read somewhere that `panic`s in Go are
> intended to not cross library boundaries (and not be part of the API).
>  -



Exactly - the panics do not cross library boundaries (unless there's a bug)
and are not part of the API. You'll see that the exported Marshal and
Unmarshal functions recover from the panic and return an error instead.

This is a trick I copied from some of the standard libraries that do
similar marshal/unmarshal (e.g. xml and json) - exception-like
panic/recover inside the package, but return error at the boundaries.
Nowadays I have gotten to appreciate Go's very explicit error return style,
so I don't use that trick much anymore, but in this particular package it
works well so I left it there.

Re: ACL rules for Qpid C++ Broker

[Chuck Rolke]

Hi Andi,

The ACLs for Qpid C++ are modeled after the AMQP 0-10 exchange-binding-queue 
(EBQ) design. See 
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_MRG/1.1/html/Messaging_User_Guide/sect-Messaging_User_Guide-Introduction_to_RHM-The_AMQP_0_10_Model.html
 for pictures and discussion.

-Chuck

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

Re: ACL rules for Qpid C++ Broker

[andi welchlin]

Hello Jacub,

this helps a lot.

Thank you!

Andreas

On Fri, Nov 10, 2017 at 4:59 PM, Jakub Scholz  wrote:

> Hi Andreas,
>
> The problem is that in qpidd you never publish directly to queue or read
> directly from an exchange. You always publish to exchange and read from a
> queue. In reality what you see as publishing directly to an queue is
> sending the message to an exchange named "" (as in empty string) with a
> routing key which should be the name of your queue. The same when you try
> to read directly from an exchange the client acutally creates a queue and a
> binding to the exchange for you. That is why the ACL rules such as "publish
> queue" or "consume exchange" do not exist.
>
> In your case ... if your group wants to publish to queue name QU1, you
> should add a rule which looks something like this:
> acl allow group1 publish exchange name=amq.default routingkey=QU1
> where the exchange name "amq.default" will be substituted for the exchange
> without name (as per https://issues.apache.org/jira/browse/QPID-4727)
>
> To read directly from an exchange you need several ACL rights:
> - to create a queue
> acl allow group1 create queue name=*
> - to delete a queue when you are closing the connection
> acl allow group1 delete queue name=*
> - to consume from the queue
> acl allow group1 consume queue name=*
> - to bind the exchange
> acl allow group1 bind exchange name=EX1
>
> Depending on your client you might be able to specify the queue name in
> more detail. For example the qpid-receive client (using the old Qpid C++
> API) would create the queue named similar to
> "EX1_8f4ea08f-d211-41c0-97cf-652cd5ef9a11". But different clients might do
> it differently.
>
> Hope this helps.
>
> Jakub
>
>
> On Fri, Nov 10, 2017 at 3:46 PM, andi welchlin 
> wrote:
>
> > Hello everyone,
> >
> > I looked into ACL documentation of Qpid C++ broker (1.36.0) and tested
> it a
> > bit.
> >
> >
> > I would like to allow for one usergroup to write to a queue with a
> specific
> > name, but deny it for all other users.
> >
> > But I saw that i can not do the following:
> >
> > acl allow group1 publish queue name=QU1
> >
> >
> > I understood that the publish keyword can only be used for exchanges.
> >
> >
> > I also would like to restrict reading from an exchange with a specific
> name
> > and allow it only for one usergroup.
> >
> > But the following seems also not to be allowed:
> >
> > acl allow group1 consume exchange name=EX1
> >
> >
> > "consume" is only allowed for queues.
> >
> >
> > How can I reach these two requirements?
> >
> >
> > Kind Regards,
> > Andreas
> >
>

Re: ACL rules for Qpid C++ Broker

[Jakub Scholz]

Hi Andreas,

The problem is that in qpidd you never publish directly to queue or read
directly from an exchange. You always publish to exchange and read from a
queue. In reality what you see as publishing directly to an queue is
sending the message to an exchange named "" (as in empty string) with a
routing key which should be the name of your queue. The same when you try
to read directly from an exchange the client acutally creates a queue and a
binding to the exchange for you. That is why the ACL rules such as "publish
queue" or "consume exchange" do not exist.

In your case ... if your group wants to publish to queue name QU1, you
should add a rule which looks something like this:
acl allow group1 publish exchange name=amq.default routingkey=QU1
where the exchange name "amq.default" will be substituted for the exchange
without name (as per https://issues.apache.org/jira/browse/QPID-4727)

To read directly from an exchange you need several ACL rights:
- to create a queue
acl allow group1 create queue name=*
- to delete a queue when you are closing the connection
acl allow group1 delete queue name=*
- to consume from the queue
acl allow group1 consume queue name=*
- to bind the exchange
acl allow group1 bind exchange name=EX1

Depending on your client you might be able to specify the queue name in
more detail. For example the qpid-receive client (using the old Qpid C++
API) would create the queue named similar to
"EX1_8f4ea08f-d211-41c0-97cf-652cd5ef9a11". But different clients might do
it differently.

Hope this helps.

Jakub


On Fri, Nov 10, 2017 at 3:46 PM, andi welchlin 
wrote:

> Hello everyone,
>
> I looked into ACL documentation of Qpid C++ broker (1.36.0) and tested it a
> bit.
>
>
> I would like to allow for one usergroup to write to a queue with a specific
> name, but deny it for all other users.
>
> But I saw that i can not do the following:
>
> acl allow group1 publish queue name=QU1
>
>
> I understood that the publish keyword can only be used for exchanges.
>
>
> I also would like to restrict reading from an exchange with a specific name
> and allow it only for one usergroup.
>
> But the following seems also not to be allowed:
>
> acl allow group1 consume exchange name=EX1
>
>
> "consume" is only allowed for queues.
>
>
> How can I reach these two requirements?
>
>
> Kind Regards,
> Andreas
>

Re: Java Broker performance

[Rob Godfrey]

On 10 November 2017 at 16:39, Vavricka  wrote:

> Hi,
>
> hardware:
> * Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz
> * 16 GB RAM
> * HDD ST500DM002-1BD142
>
> timings:
> Currently Java Broker 6.1.1 seems to behave as version 7.0.0 RC. 10 - 30
> messages per second. Interesting is when I increase message size to 10kB.
> Messages per second are same but throughput is increased ten times.
> When I use nonpersistent messages everything goes smooth. Thousand of 1kB
> messages are sent within 1 second.
>

So, this is more what I would expect (in the sense that 6.1 will behave
like 7.0 - the performance is unacceptable, but I think I understand it).

I *think* the issue is that we have not yet implemented the optimisations
in the 1.0 layer for non-transactional durable messages to be processed
asynchronously.  Because of this the rate of message processing is
dependent upon how many times fsync() can be called a second.  500/s is
probably about right for a SAN, ~20 is what I saw from conventional hard
drives; for SSDs with a battery backed write cache I've gotten > 1000/s.
Because it is dependent upon the number of fsyncs rather than the
throughput of the disk, increasing the message size will not affect the
rate and thus you will see a linear improvement in throughput.

Fixing this shouldn't actually be a huge change, and after it you should
see something more like the C++ broker behaviour.  Since this isn't (I
think) a regression between 7.0 and 6.1 I'd suggest that we progress with
the 7.0 release and then quickly follow that with a 7.0.1 that introduces
the necessary optimisation (we can essentially copy over the code from the
0-x protocol layers).

-- Rob


>
> There are no extra JVM options, just the ones which are present in
> bin/qpid-server file.
>
> Heap and direct memory on broker is also default - -Xmx512m
> -XX:MaxDirectMemorySize=1536m. I tried to increase to four times larger
> ones
> -Xmx2048m -XX:MaxDirectMemorySize=6000m, but there was no change in
> messages
> per second.
>
> Unfortunately vmstat gives same values pro CPU, I am sending at least top
> output.
>
> 6.1.1:
> %Cpu(s):  6.9 us,  0.3 sy,  0.0 ni, 68.5 id, 24.1 wa,  0.0 hi,  0.2 si,
> 0.0
> st
>
> 7.0.0:
> %Cpu(s):  2.4 us,  0.4 sy,  0.0 ni, 71.2 id, 25.9 wa,  0.0 hi,  0.0 si,
> 0.0
> st
>
> When we tried on server where message store was stored on SAN disk, sending
> of messages increased to 500 msg/sec. With C++ broker on same machine we
> are
> able to send 5000 msg/sec.
>
> ps. I cannot create queue in 7.0.0 version by webgui when queue contains
> '.'
> character, in 6.1.1 version queue with dot in name can be created by webgui
>
>
> Keith Wall wrote
> > Hi Tomas,
> >
> > Nor can I reproduce any discernible difference in performance between
> > 6.1.1 and the 7.0.0 RC with your Java code.  I have not tried the C++
> > yet.
> >
> > Can you share with us:
> >
> > * details of the hardware (including the storage) you are using for the
> > test.
> > * the timings you seeing for your tests for both the 6.1.1 case and 7.0.0
> > RC
> > * any extra JVM options you are passing either client or broker side.
> > * size of java heap (client side) and heap and direct memory (broker)
> >
> > Can I suggest that you collect vmstat type information for both runs
> > and compare?   My expectation is that CPU usage, disk I/O, and network
> > utilisation should be approximately equal between the two runs.
> >
> > cheers, Keith
>
>
>
>
>
> --
> 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: Java Broker performance

[Vavricka]

Hi,

hardware:
* Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz
* 16 GB RAM
* HDD ST500DM002-1BD142

timings:
Currently Java Broker 6.1.1 seems to behave as version 7.0.0 RC. 10 - 30
messages per second. Interesting is when I increase message size to 10kB.
Messages per second are same but throughput is increased ten times.
When I use nonpersistent messages everything goes smooth. Thousand of 1kB
messages are sent within 1 second.

There are no extra JVM options, just the ones which are present in
bin/qpid-server file.

Heap and direct memory on broker is also default - -Xmx512m
-XX:MaxDirectMemorySize=1536m. I tried to increase to four times larger ones
-Xmx2048m -XX:MaxDirectMemorySize=6000m, but there was no change in messages
per second.

Unfortunately vmstat gives same values pro CPU, I am sending at least top
output.

6.1.1:
%Cpu(s):  6.9 us,  0.3 sy,  0.0 ni, 68.5 id, 24.1 wa,  0.0 hi,  0.2 si,  0.0
st

7.0.0:
%Cpu(s):  2.4 us,  0.4 sy,  0.0 ni, 71.2 id, 25.9 wa,  0.0 hi,  0.0 si,  0.0
st

When we tried on server where message store was stored on SAN disk, sending
of messages increased to 500 msg/sec. With C++ broker on same machine we are
able to send 5000 msg/sec.

ps. I cannot create queue in 7.0.0 version by webgui when queue contains '.'
character, in 6.1.1 version queue with dot in name can be created by webgui


Keith Wall wrote
> Hi Tomas,
> 
> Nor can I reproduce any discernible difference in performance between
> 6.1.1 and the 7.0.0 RC with your Java code.  I have not tried the C++
> yet.
> 
> Can you share with us:
> 
> * details of the hardware (including the storage) you are using for the
> test.
> * the timings you seeing for your tests for both the 6.1.1 case and 7.0.0
> RC
> * any extra JVM options you are passing either client or broker side.
> * size of java heap (client side) and heap and direct memory (broker)
> 
> Can I suggest that you collect vmstat type information for both runs
> and compare?   My expectation is that CPU usage, disk I/O, and network
> utilisation should be approximately equal between the two runs.
> 
> cheers, Keith





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

ACL rules for Qpid C++ Broker

[andi welchlin]

Hello everyone,

I looked into ACL documentation of Qpid C++ broker (1.36.0) and tested it a
bit.


I would like to allow for one usergroup to write to a queue with a specific
name, but deny it for all other users.

But I saw that i can not do the following:

acl allow group1 publish queue name=QU1


I understood that the publish keyword can only be used for exchanges.


I also would like to restrict reading from an exchange with a specific name
and allow it only for one usergroup.

But the following seems also not to be allowed:

acl allow group1 consume exchange name=EX1


"consume" is only allowed for queues.


How can I reach these two requirements?


Kind Regards,
Andreas

Re: Java Broker performance

[Keith W]

Hi Tomas,

I'm testing with out of the box configuration.   I have tried your
configuration and still can't reproduce a slow down. I don't know your
ACL rules, but I added some.  The result was the same.
I'm curious to hear the answers to the questions I posed earlier.
Hopefully that will give us a clue.

Thanks Keith.


On 10 November 2017 at 13:51, Keith W  wrote:
> Hi Tomas,
>
> Nor can I reproduce any discernible difference in performance between
> 6.1.1 and the 7.0.0 RC with your Java code.  I have not tried the C++
> yet.
>
> Can you share with us:
>
> * details of the hardware (including the storage) you are using for the test.
> * the timings you seeing for your tests for both the 6.1.1 case and 7.0.0 RC
> * any extra JVM options you are passing either client or broker side.
> * size of java heap (client side) and heap and direct memory (broker)
>
> Can I suggest that you collect vmstat type information for both runs
> and compare?   My expectation is that CPU usage, disk I/O, and network
> utilisation should be approximately equal between the two runs.
>
> cheers, Keith
>
>
> On 10 November 2017 at 11:12, Rob Godfrey  wrote:
>> Hi Tomas,
>>
>> on the producing side I cannot reproduce this difference on my laptop
>> (MacBook Pro, running OS X), and I'm unaware of any changes that were made
>> to the broker that would cause such a significant slowdown (I haven't
>> looked at consuming yet).
>>
>> I presume you are running these tests on the same hardware, with the same
>> JMS client version, and such...?
>>
>> -- Rob
>>
>> On 10 November 2017 at 10:11, Rob Godfrey  wrote:
>>
>>> Thanks Tomas,
>>>
>>> we'll look into this
>>>
>>> -- Rob
>>>
>>> On 10 November 2017 at 09:59, Vavricka  wrote:
>>>
 C++ client code below

 #include 
 #include 

 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 

 class Broadcaster : public proton::messaging_handler
 {

 private:

 std::string _account;
 std::string _password;
 std::string _host;
 unsigned int _port;
 unsigned int _count;
 unsigned int _size;
 unsigned int _sent;
 unsigned int _confirmed;
 std::string _exchange;
 std::string _routingKey;
 proton::sender _sender;

 public:

 explicit Broadcaster(const std::string ,
  const std::string ,
  const std::string ,
  unsigned int port,
  const std::string ,
  const std::string ,
  unsigned int count,
  unsigned int size)
 : _account(account)
 , _password(password)
 , _host(host)
 , _port(port)
 , _count(count)
 , _size(size)
 , _sent(0)
 , _confirmed(0)
 , _exchange(exchange)
 , _routingKey(routingKey)
 {
 }

 void on_container_start(proton::container )
 {
 proton::connection_options connectionOptions;
 connectionOptions.sasl_allow_insecure_mechs(true);
 connectionOptions.sasl_allowed_mechs("PLAIN");
 c.client_connection_options(connectionOptions);

 std::string url = "amqp://" + _account + ":" + _password + "@" +
 _host + ":" + std::to_string(_port) + "/" + _exchange;

 _sender = c.open_sender(url);
 }

 void on_sendable(proton::sender )
 {
 while (s.credit() && _sent < _count)
 {
 proton::message msg;
 msg.id(_sent + 1);
 msg.subject(_routingKey);
 msg.body(std::string(_size, '*'));
 msg.durable(true);
 s.send(msg);
 _sent++;
 std::cout << "-I sent " << _sent << " of " << _count <<
 std::endl;
 }
 }

 void on_tracker_accept(proton::tracker )
 {
 _confirmed++;
 if (_confirmed == _count)
 {
 std::cout << "-I- All messages (" << _confirmed << ")
 confirmed"
 << std::endl;
 t.connection().close();
 }
 }

 void on_transport_close(proton::transport )
 {
 _sent = _confirmed;
 }

 void run()
 {
 try
 {
 proton::default_container(*this).run();
 }
 catch (const std::exception )
 {
 std::cerr << "-E- Caught exception: " << error.what() <<
 

Re: Java Broker performance

[Keith W]

Hi Tomas,

Nor can I reproduce any discernible difference in performance between
6.1.1 and the 7.0.0 RC with your Java code.  I have not tried the C++
yet.

Can you share with us:

* details of the hardware (including the storage) you are using for the test.
* the timings you seeing for your tests for both the 6.1.1 case and 7.0.0 RC
* any extra JVM options you are passing either client or broker side.
* size of java heap (client side) and heap and direct memory (broker)

Can I suggest that you collect vmstat type information for both runs
and compare?   My expectation is that CPU usage, disk I/O, and network
utilisation should be approximately equal between the two runs.

cheers, Keith


On 10 November 2017 at 11:12, Rob Godfrey  wrote:
> Hi Tomas,
>
> on the producing side I cannot reproduce this difference on my laptop
> (MacBook Pro, running OS X), and I'm unaware of any changes that were made
> to the broker that would cause such a significant slowdown (I haven't
> looked at consuming yet).
>
> I presume you are running these tests on the same hardware, with the same
> JMS client version, and such...?
>
> -- Rob
>
> On 10 November 2017 at 10:11, Rob Godfrey  wrote:
>
>> Thanks Tomas,
>>
>> we'll look into this
>>
>> -- Rob
>>
>> On 10 November 2017 at 09:59, Vavricka  wrote:
>>
>>> C++ client code below
>>>
>>> #include 
>>> #include 
>>>
>>> #include 
>>> #include 
>>> #include 
>>> #include 
>>> #include 
>>> #include 
>>> #include 
>>> #include 
>>> #include 
>>>
>>> class Broadcaster : public proton::messaging_handler
>>> {
>>>
>>> private:
>>>
>>> std::string _account;
>>> std::string _password;
>>> std::string _host;
>>> unsigned int _port;
>>> unsigned int _count;
>>> unsigned int _size;
>>> unsigned int _sent;
>>> unsigned int _confirmed;
>>> std::string _exchange;
>>> std::string _routingKey;
>>> proton::sender _sender;
>>>
>>> public:
>>>
>>> explicit Broadcaster(const std::string ,
>>>  const std::string ,
>>>  const std::string ,
>>>  unsigned int port,
>>>  const std::string ,
>>>  const std::string ,
>>>  unsigned int count,
>>>  unsigned int size)
>>> : _account(account)
>>> , _password(password)
>>> , _host(host)
>>> , _port(port)
>>> , _count(count)
>>> , _size(size)
>>> , _sent(0)
>>> , _confirmed(0)
>>> , _exchange(exchange)
>>> , _routingKey(routingKey)
>>> {
>>> }
>>>
>>> void on_container_start(proton::container )
>>> {
>>> proton::connection_options connectionOptions;
>>> connectionOptions.sasl_allow_insecure_mechs(true);
>>> connectionOptions.sasl_allowed_mechs("PLAIN");
>>> c.client_connection_options(connectionOptions);
>>>
>>> std::string url = "amqp://" + _account + ":" + _password + "@" +
>>> _host + ":" + std::to_string(_port) + "/" + _exchange;
>>>
>>> _sender = c.open_sender(url);
>>> }
>>>
>>> void on_sendable(proton::sender )
>>> {
>>> while (s.credit() && _sent < _count)
>>> {
>>> proton::message msg;
>>> msg.id(_sent + 1);
>>> msg.subject(_routingKey);
>>> msg.body(std::string(_size, '*'));
>>> msg.durable(true);
>>> s.send(msg);
>>> _sent++;
>>> std::cout << "-I sent " << _sent << " of " << _count <<
>>> std::endl;
>>> }
>>> }
>>>
>>> void on_tracker_accept(proton::tracker )
>>> {
>>> _confirmed++;
>>> if (_confirmed == _count)
>>> {
>>> std::cout << "-I- All messages (" << _confirmed << ")
>>> confirmed"
>>> << std::endl;
>>> t.connection().close();
>>> }
>>> }
>>>
>>> void on_transport_close(proton::transport )
>>> {
>>> _sent = _confirmed;
>>> }
>>>
>>> void run()
>>> {
>>> try
>>> {
>>> proton::default_container(*this).run();
>>> }
>>> catch (const std::exception )
>>> {
>>> std::cerr << "-E- Caught exception: " << error.what() <<
>>> std::endl;
>>> throw error;
>>> }
>>> }
>>> };
>>>
>>> int main(void)
>>> {
>>> Broadcaster("C7",
>>> "C7",
>>> "pc1wj611",
>>> 20001,
>>> "broadcast",
>>> "broadcast.C7_CashTransaction",
>>> 1000,
>>> 1024).run();
>>> return 0;
>>> }
>>>
>>>
>>>
>>>
>>> --
>>> Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936
>>> .html
>>>
>>> -

Re: Electron/Amqp MessageAnnotations in Golang

[Jiri Danek]

On Fri, Nov 10, 2017 at 1:10 PM, Alessio Gottardo  wrote:
>
> Out of curiosity is there a specific reason for `panic`ing in the
> `default` case instead of returning an `error`?I just became aware of this
> `recover` mechanism in go to handle a runtime `panic` thrown somewhere
> else, but that's going to make the code quite a bit more complicated. I was
> wondering if it would have been easier to return an error to whoever uses
> the `amqp` go wrapper, but I see that could have quite of an impact on the
> codebase as it is at the moment.
> Thank you for the fix.Alessio
>

I was thinking the same thing. I read somewhere that `panic`s in Go are
intended to not cross library boundaries (and not be part of the API).
-- 
Jiri Daněk

Re: Java Broker performance

[Vavricka]

Yes, we running it on same hardware and versions.

Couldn't be there issue with our configuration? Can you spot there some
misconfiguration in config files below?

Will be helpful if you send us your broker configuration?

config.json

{
  "id" : "cfa9a57a-6f98-4f17-b81d-22fb5a032473",
  "name" : "cps",
  "modelVersion" : "7.0",
  "accesscontrolproviders" : [ {
"id" : "65b550b1-0a22-4815-9b6f-5287f6a9b455",
"name" : "brokerAcl",
"type" : "AclFile",
"path" : "/home/vavrtom/qpid/0406/broker/work/broker.acl",
"lastUpdatedBy" : null,
"lastUpdatedTime" : null,
"createdBy" : null,
"createdTime" : null
  } ],
  "authenticationproviders" : [ {
"id" : "df3680b4-8bd7-4bb8-92b7-705d33bf1496",
"name" : "SHA_256",
"type" : "SCRAM-SHA-256",
"secureOnlyMechanisms" : [ ],
"users" : [ {
  "id" : "e98445dd-4f79-46b1-bc7f-a153f546e63e",
  "name" : "C7",
  "type" : "managed",
  "durable" : true,
  "password" :
"KAkXZolpJXtHteNgxqeNaosC3eecIN0MRZVdFcAwGm4=,,U52qJCBi8jUfjPTHMxayTwUhQ3UT+N6B7h78S+kRNUw=,fQdDP2WsuAGZ/P4PxJuSAHrpmgE/2GBMjD9/TrYw0QY=,4096",
  "lastUpdatedBy" : "admin",
  "lastUpdatedTime" : 1510235279421,
  "createdBy" : "admin",
  "createdTime" : 1510235279421
}, {
  "id" : "62ab34ac-11d8-4ed0-adc3-bd1c34a2f7af",
  "name" : "admin",
  "type" : "managed",
  "password" :
"7uKre2FrpVvO+/gABKrTHyQS5tAY92UqOWNcWPCubyw=,,j3TzWP+Bg2iZUXxMdZbVi1ftrHIvzev5PqO9ftDC4hU=,9cvIWGYPfeUD0hFLvINPKz+Ddvv/9/yz8PuMC+JR3Ro=,4096"
}, {
  "id" : "e6451384-9ef5-4823-81c6-7b1aff7251ca",
  "name" : "monit",
  "type" : "managed",
  "password" :
"b3MiUviPyxYSfB9bxRZG4FJ/uxDWjWnNvBe1B/w8JYc=,,gxUMuoFhW9oVNV/tEiLm3IdgObL2uQagi63G+3bnFgs=,cQmi/8NKL2b8ESfoF/wcffPRILoMOx5cRy+rEG2TAxw=,4096"
} ]
  }, {
"id" : "85d7cb16-4c60-45ca-94e8-47c611a7b1e4",
"name" : "external",
"type" : "External"
  } ],
  "brokerloggers" : [ {
"id" : "e637b21b-c3a8-457f-a0ff-c4327c88135b",
"name" : "logfile",
"type" : "File",
"fileName" :
"${qpid.work_dir}${file.separator}..${file.separator}..${file.separator}log${file.separator}broker.log",
"brokerloginclusionrules" : [ {
  "id" : "f8e8c9eb-6ca9-4845-8ac8-1ba614a47ce8",
  "name" : "Operational",
  "type" : "NameAndLevel",
  "level" : "INFO",
  "loggerName" : "qpid.message.*"
}, {
  "id" : "13c4e2c4-3b3a-43be-890b-cc506dae63f8",
  "name" : "Qpid",
  "type" : "NameAndLevel",
  "level" : "INFO",
  "loggerName" : "org.apache.qpid.*"
}, {
  "id" : "00ff6321-2d42-4dce-aad0-12c55c928e0d",
  "name" : "Root",
  "type" : "NameAndLevel",
  "level" : "INFO",
  "loggerName" : "ROOT"
} ]
  }, {
"id" : "b25480a7-5ed1-4035-af9d-565c9c223708",
"name" : "memory",
"type" : "Memory",
"brokerloginclusionrules" : [ {
  "id" : "ffc9a1da-e812-476c-8ccf-c8ead2f15e1e",
  "name" : "Operational",
  "type" : "NameAndLevel",
  "level" : "INFO",
  "loggerName" : "qpid.message.*"
}, {
  "id" : "8c2a2fe6-9531-469b-8f26-c5d449e97f26",
  "name" : "Qpid",
  "type" : "NameAndLevel",
  "level" : "INFO",
  "loggerName" : "org.apache.qpid.*"
}, {
  "id" : "dcb193af-fba8-49e7-9ed4-9a4a08627e8c",
  "name" : "Root",
  "type" : "NameAndLevel",
  "level" : "INFO",
  "loggerName" : "ROOT"
} ]
  } ],
  "keystores" : [ {
"id" : "f262fc1c-081b-4215-8afb-bb0ce6131857",
"name" : "keyStore",
"type" : "FileKeyStore",
"certificateAlias" : "vavrtom-amqp",
"password" : "admin",
"storeUrl" : "/home/vavrtom/qpid/0406/broker/work/keystore.jks"
  } ],
  "plugins" : [ {
"id" : "1276ff6c-61ea-4b4d-b1ad-4edc5c02f581",
"name" : "httpManagement",
"type" : "MANAGEMENT-HTTP",
"httpBasicAuthenticationEnabled" : "true"
  } ],
  "ports" : [ {
"id" : "6fdbb8b1-76ba-4048-9ca8-4e7dfb884a38",
"name" : "amqp",
"type" : "AMQP",
"port" : 20406,
"protocols" : [ "AMQP_1_0" ],
"authenticationProvider" : "SHA_256",
"threadPoolSize" : 10,
"numberOfSelectors" : 1,
"maxOpenConnections" : 1000,
"virtualhostaliases" : [ {
  "id" : "59d083e1-57f2-45c0-b8d4-c75f23ea33ef",
  "name" : "defaultAlias",
  "type" : "defaultAlias"
}, {
  "id" : "1c61ebd0-fbc6-4891-998b-59b972492fc7",
  "name" : "hostnameAlias",
  "type" : "hostnameAlias"
}, {
  "id" : "d75851d6-ea9c-4aec-a8db-7e28d5815b5e",
  "name" : "nameAlias",
  "type" : "nameAlias"
} ]
  }, {
"id" : "f52c4129-d388-4f3a-b23f-892070a131dd",
"name" : "amqps",
"type" : "AMQP",
"port" : 10406,
"protocols" : [ "AMQP_1_0" ],
"authenticationProvider" : "external",
"needClientAuth" : true,
"wantClientAuth" : true,
"keyStore" : "keyStore",
"transports" : [ "SSL" ],
"trustStores" : [ "trustStore" ],
"threadPoolSize" : 10,
"numberOfSelectors" : 1,
"maxOpenConnections" : 

Re: SASL can not parse configuration file

[andi welchlin]

Hello Gordon, hello all,

now I got what is wrong with my SASL config.

I mixed up qpidd.conf for the broker and qpidd.conf for sasl. These are two
different files with the same name, right?

So qpidd.conf for sasl should be similar to the file contained in
"qpid-cpp-1.36.0/etc/sasl2".

It could look like this:

pwcheck_method: auxprop
auxprop_plugin: sasldb
sasldb_path: /tmp/sasl/qpidd.sasldb
mech_list: ANONYMOUS DIGEST-MD5 EXTERNAL PLAIN

and NOT like this:

auth=YES
realm=QPID


So since I placed this file into the folder it works.


Regards,
Andreas




On Fri, Nov 10, 2017 at 12:51 PM, andi welchlin 
wrote:

> Hi Gordon,
>
> It contains two files:
>
> qpidd.conf
> qpidd.sasldb
>
>
>
>
>
> On Fri, Nov 10, 2017 at 12:05 PM, Gordon Sim  wrote:
>
>> On 10/11/17 10:31, andi welchlin wrote:
>>
>>> Hello all,
>>>
>>> I tried to configure SASL for Qpid C++ broker 1.36.0 but it seems like I
>>> missed something.
>>>
>>> What I did:
>>> 
>>>
>>> Installed Cyrus SASL.
>>>
>>> Created a SASL database with a user "bob" using:
>>>
>>> saslpasswd2 -f qpidd.sasldb -u QPID bob
>>>
>>> Checked the db using sasldblistusers2 and it worked.
>>>
>>>
>>> Configured qpidd using qpidd.conf
>>>
>>> auth=YES
>>> realm=QPID
>>> sasl-config=/home/andreas/brokers/qpid/qpid-configuration
>>>
>>
>>
>> What are the contents of /home/andreas/brokers/qpid/qpid-configuration?
>> It sounds like the sasl library can't parse that.
>>
>>
>> Both qpidd.conf and qpidd.sasldb are located in the configured directory
>>> and the sasldb is readable for every user.
>>>
>>> Then I started qpidd and it told me this:
>>>
>>> /home/andreas/brokers/qpid/qpid-cpp-1.36.0/src/qpidd.cpp:111: Unexpected
>>> error: SASL: failed to parse SASL configuration file in
>>> (/home/andreas/brokers/qpid/qpid-configuration/qpid1), error: generic
>>> failure
>>> (/home/andreas/brokers/qpid/qpid-cpp-1.36.0/src/qpid/broker/
>>> SaslAuthenticator.cpp:181)
>>>
>>>
>>> Looking into the code I can see that sasl_server_init failed. But I don't
>>> get what the reason could be since I could read the db using
>>> sasldblistusers2.
>>>
>>>
>>> Do I have to set some environment variables?
>>>
>>> What did I miss?
>>>
>>> Any hints are welcome.
>>>
>>>
>>> Cheers,
>>> Andreas
>>>
>>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
>> For additional commands, e-mail: users-h...@qpid.apache.org
>>
>>
>

Re: Electron/Amqp MessageAnnotations in Golang

[Alessio Gottardo]

 Thank you Alan, very much appreciated :)
Out of curiosity is there a specific reason for `panic`ing in the `default` 
case instead of returning an `error`?I just became aware of this `recover` 
mechanism in go to handle a runtime `panic` thrown somewhere else, but that's 
going to make the code quite a bit more complicated. I was wondering if it 
would have been easier to return an error to whoever uses the `amqp` go 
wrapper, but I see that could have quite of an impact on the codebase as it is 
at the moment.
Thank you for the fix.Alessio
On Thursday, 9 November 2017, 20:17:41 GMT, Alan Conway 
 wrote:  
 
 Apologies for the long delay, this is a bug and was reported previously:
https://issues.apache.org/jira/browse/PROTON-1429

I am fixing it now, watch the JIRA to be notified when it is fixed. You can
get the latest code direct from git, the "go get" repo will be updated with
the next release of proton, which should be fairly soon.

On Mon, Nov 6, 2017 at 6:29 AM, Alessio Gottardo 
wrote:

> Hi there,
>
> I am having a hard time at parsing this field `MessageAnnotations()
> map[AnnotationKey]interface{}` from this type:
> https://godoc.org/qpid.apache.org/amqp#Message when receiving a message.
>
> I am connecting to a Azure Event Hub which is supposed to send some useful
> annotations that I would like to parse e.g.:
>
> - the field called "x-opt-sequence-number" to retrieve the offset of this
> message in the partition
> - the field called "x-opt-enqueued-time" for the timestamp
>
> Cf. this for more details: https://github.com/
> Azure/amqpnetlite/blob/master/docs/articles/azure_eventhubs.md
>
> However at runtime when I attempt at accessing that golang field with
> `amqpMessage.MessageAnnotations()` then I keep getting a panic message
> saying: `cannot unmarshal AMQP timestamp to *interface {}`
>
> It seems there is a missing switch-case scenario in here:
> https://github.com/apache/qpid-proton/blob/go1/amqp/unmarshal.go#L248
>
> Am I doing anything wrong in the way I am trying to access those AMQP
> fields?
> How could I try to avoid that panic at line 551 in the "default" case of
> the switch?
> I am not familiar with AMQP and golang so I am wondering if I should do
> things in a different / more idiomatic way instead.
>
> Thank you
> Alessio
>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>
  

Re: SASL can not parse configuration file

[andi welchlin]

Hi Gordon,

It contains two files:

qpidd.conf
qpidd.sasldb





On Fri, Nov 10, 2017 at 12:05 PM, Gordon Sim  wrote:

> On 10/11/17 10:31, andi welchlin wrote:
>
>> Hello all,
>>
>> I tried to configure SASL for Qpid C++ broker 1.36.0 but it seems like I
>> missed something.
>>
>> What I did:
>> 
>>
>> Installed Cyrus SASL.
>>
>> Created a SASL database with a user "bob" using:
>>
>> saslpasswd2 -f qpidd.sasldb -u QPID bob
>>
>> Checked the db using sasldblistusers2 and it worked.
>>
>>
>> Configured qpidd using qpidd.conf
>>
>> auth=YES
>> realm=QPID
>> sasl-config=/home/andreas/brokers/qpid/qpid-configuration
>>
>
>
> What are the contents of /home/andreas/brokers/qpid/qpid-configuration?
> It sounds like the sasl library can't parse that.
>
>
> Both qpidd.conf and qpidd.sasldb are located in the configured directory
>> and the sasldb is readable for every user.
>>
>> Then I started qpidd and it told me this:
>>
>> /home/andreas/brokers/qpid/qpid-cpp-1.36.0/src/qpidd.cpp:111: Unexpected
>> error: SASL: failed to parse SASL configuration file in
>> (/home/andreas/brokers/qpid/qpid-configuration/qpid1), error: generic
>> failure
>> (/home/andreas/brokers/qpid/qpid-cpp-1.36.0/src/qpid/broker/
>> SaslAuthenticator.cpp:181)
>>
>>
>> Looking into the code I can see that sasl_server_init failed. But I don't
>> get what the reason could be since I could read the db using
>> sasldblistusers2.
>>
>>
>> Do I have to set some environment variables?
>>
>> What did I miss?
>>
>> Any hints are welcome.
>>
>>
>> Cheers,
>> Andreas
>>
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>

Re: [VOTE] Release Qpid Broker-J 7.0.0 (RC3)

[Robbie Gemmell]

On 8 November 2017 at 17:35, Oleksandr Rudyy  wrote:
> HI all,
>
> Apache Qpid Broker-J 7.0.0 RC3 is built and ready for testing.
> The following issues have been resolved since RC2:
>
> * QPID-8020 - [Broker-J] Rename binary and source distribution bundles for
> broker-j
> * QPID-8023 - [Broker-J] Remove com.google.code.findbugs:jsr305 dependency
> * QPID-8024 - [Broker-J] Reflect missing components and changes in
> copyright dates in the NOTICE file
>
> The full list of new features, defect fixes and improvements can be found
> in Jira:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20QPID%20AND%20fixVersion%20%3D%20qpid-java-broker-7.0.0
>
> The source and binary archives can be grabbed from here:
> https://dist.apache.org/repos/dist/dev/qpid/broker-j/7.0.0-rc3
>
> The maven artifacts are also staged for now at:
> https://repository.apache.org/content/repositories/orgapacheqpid-1121
>
> Please test and cast your vote accordingly.
>
> Kind regards
>
> P.S. If you want to test it out using maven, you can temporarily add this
> to your poms to access
> the staging repo:
>
>   
> 
>   staging
>   
> https://repository.apache.org/content/repositories/orgapacheqpid-1121
> 
>   

+1

I checked things over as follows:
- Verified the signature and checksum files.
- Used "mvn apache-rat:check" to verify the headers in source release.
- Checked for LICENCE+NOTICE files present in each archive.
- Ran the source release build and unit tests (default profile).
- Started the broker from the tar.gz binary, used the web management
console to create a queue.
- Ran the Qpid JMS master HelloWorld example against the running broker.

Robbie

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

Re: Java Broker performance

[Rob Godfrey]

Hi Tomas,

on the producing side I cannot reproduce this difference on my laptop
(MacBook Pro, running OS X), and I'm unaware of any changes that were made
to the broker that would cause such a significant slowdown (I haven't
looked at consuming yet).

I presume you are running these tests on the same hardware, with the same
JMS client version, and such...?

-- Rob

On 10 November 2017 at 10:11, Rob Godfrey  wrote:

> Thanks Tomas,
>
> we'll look into this
>
> -- Rob
>
> On 10 November 2017 at 09:59, Vavricka  wrote:
>
>> C++ client code below
>>
>> #include 
>> #include 
>>
>> #include 
>> #include 
>> #include 
>> #include 
>> #include 
>> #include 
>> #include 
>> #include 
>> #include 
>>
>> class Broadcaster : public proton::messaging_handler
>> {
>>
>> private:
>>
>> std::string _account;
>> std::string _password;
>> std::string _host;
>> unsigned int _port;
>> unsigned int _count;
>> unsigned int _size;
>> unsigned int _sent;
>> unsigned int _confirmed;
>> std::string _exchange;
>> std::string _routingKey;
>> proton::sender _sender;
>>
>> public:
>>
>> explicit Broadcaster(const std::string ,
>>  const std::string ,
>>  const std::string ,
>>  unsigned int port,
>>  const std::string ,
>>  const std::string ,
>>  unsigned int count,
>>  unsigned int size)
>> : _account(account)
>> , _password(password)
>> , _host(host)
>> , _port(port)
>> , _count(count)
>> , _size(size)
>> , _sent(0)
>> , _confirmed(0)
>> , _exchange(exchange)
>> , _routingKey(routingKey)
>> {
>> }
>>
>> void on_container_start(proton::container )
>> {
>> proton::connection_options connectionOptions;
>> connectionOptions.sasl_allow_insecure_mechs(true);
>> connectionOptions.sasl_allowed_mechs("PLAIN");
>> c.client_connection_options(connectionOptions);
>>
>> std::string url = "amqp://" + _account + ":" + _password + "@" +
>> _host + ":" + std::to_string(_port) + "/" + _exchange;
>>
>> _sender = c.open_sender(url);
>> }
>>
>> void on_sendable(proton::sender )
>> {
>> while (s.credit() && _sent < _count)
>> {
>> proton::message msg;
>> msg.id(_sent + 1);
>> msg.subject(_routingKey);
>> msg.body(std::string(_size, '*'));
>> msg.durable(true);
>> s.send(msg);
>> _sent++;
>> std::cout << "-I sent " << _sent << " of " << _count <<
>> std::endl;
>> }
>> }
>>
>> void on_tracker_accept(proton::tracker )
>> {
>> _confirmed++;
>> if (_confirmed == _count)
>> {
>> std::cout << "-I- All messages (" << _confirmed << ")
>> confirmed"
>> << std::endl;
>> t.connection().close();
>> }
>> }
>>
>> void on_transport_close(proton::transport )
>> {
>> _sent = _confirmed;
>> }
>>
>> void run()
>> {
>> try
>> {
>> proton::default_container(*this).run();
>> }
>> catch (const std::exception )
>> {
>> std::cerr << "-E- Caught exception: " << error.what() <<
>> std::endl;
>> throw error;
>> }
>> }
>> };
>>
>> int main(void)
>> {
>> Broadcaster("C7",
>> "C7",
>> "pc1wj611",
>> 20001,
>> "broadcast",
>> "broadcast.C7_CashTransaction",
>> 1000,
>> 1024).run();
>> return 0;
>> }
>>
>>
>>
>>
>> --
>> 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
>>
>>
>

SASL can not parse configuration file

[andi welchlin]

Hello all,

I tried to configure SASL for Qpid C++ broker 1.36.0 but it seems like I
missed something.

What I did:


Installed Cyrus SASL.

Created a SASL database with a user "bob" using:

saslpasswd2 -f qpidd.sasldb -u QPID bob

Checked the db using sasldblistusers2 and it worked.


Configured qpidd using qpidd.conf

auth=YES
realm=QPID
sasl-config=/home/andreas/brokers/qpid/qpid-configuration



Both qpidd.conf and qpidd.sasldb are located in the configured directory
and the sasldb is readable for every user.

Then I started qpidd and it told me this:

/home/andreas/brokers/qpid/qpid-cpp-1.36.0/src/qpidd.cpp:111: Unexpected
error: SASL: failed to parse SASL configuration file in
(/home/andreas/brokers/qpid/qpid-configuration/qpid1), error: generic
failure
(/home/andreas/brokers/qpid/qpid-cpp-1.36.0/src/qpid/broker/SaslAuthenticator.cpp:181)


Looking into the code I can see that sasl_server_init failed. But I don't
get what the reason could be since I could read the db using
sasldblistusers2.


Do I have to set some environment variables?

What did I miss?

Any hints are welcome.


Cheers,
Andreas

Re: HA Cluster using Qpid C++ Broker 1.36.0

[andi welchlin]

Hello Alan,

thank you for your answer. I could install pacemaker using "apt-get install
pacemaker".

If you could give me some hints what to do to get it run it would be
welcome.

Thanks,
Andreas

On Wed, Nov 8, 2017 at 8:01 PM, Alan Conway  wrote:

> rgmanager has been replaced by pacemaker on RHEL7, I'm not sure what is
> available on Ubuntu. There is no out-of-the-box integration with pacemaker
> or other cluster managers, but all that is needed is some configuration and
> a couple of scripts to enable the cluster manager to start, stop and
> promote Qpid brokers at the appropriate time - the cluster manager already
> knows what the "appropriate time" is based on its liveness and membership
> rules. If you're interested in trying to make it work, I can give you more
> pointers on what is needed.
>
> On Wed, Nov 8, 2017 at 1:18 PM, Steve Huston  wrote:
>
> > I have used the qpid C++ broker in clusters. On RHEL 6. Works very well.
> >
> > > -Original Message-
> > > From: andi welchlin [mailto:andi.welch...@gmail.com]
> > > Sent: Wednesday, November 08, 2017 12:00 PM
> > > To: users@qpid.apache.org
> > > Subject: HA Cluster using Qpid C++ Broker 1.36.0
> > >
> > > Hello,
> > >
> > > I would like to configure a HA cluster using the Qpid C++ message
> broker
> > > 1.36.0. In the handbook I read that rgmanager is neccessary.
> > >
> > > When I try to install it on Ubuntu 16.04 it is not found. On a Fedora
> > installation
> > > it is also not found.
> > >
> > > Is anyone here using the Qpid message broker in a cluster?
> > >
> > > Are you using rgmanager or is there some other cluster manager usable
> on
> > > Linux?
> > >
> > > Any hints are welcome ... even if you say "noone uses the Qpid broker
> in
> > a
> > > cluster".
> > >
> > > Kind Regards,
> > > Andreas
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> > For additional commands, e-mail: users-h...@qpid.apache.org
> >
> >
>

Re: Java Broker performance

[Rob Godfrey]

Thanks Tomas,

we'll look into this

-- Rob

On 10 November 2017 at 09:59, Vavricka  wrote:

> C++ client code below
>
> #include 
> #include 
>
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
>
> class Broadcaster : public proton::messaging_handler
> {
>
> private:
>
> std::string _account;
> std::string _password;
> std::string _host;
> unsigned int _port;
> unsigned int _count;
> unsigned int _size;
> unsigned int _sent;
> unsigned int _confirmed;
> std::string _exchange;
> std::string _routingKey;
> proton::sender _sender;
>
> public:
>
> explicit Broadcaster(const std::string ,
>  const std::string ,
>  const std::string ,
>  unsigned int port,
>  const std::string ,
>  const std::string ,
>  unsigned int count,
>  unsigned int size)
> : _account(account)
> , _password(password)
> , _host(host)
> , _port(port)
> , _count(count)
> , _size(size)
> , _sent(0)
> , _confirmed(0)
> , _exchange(exchange)
> , _routingKey(routingKey)
> {
> }
>
> void on_container_start(proton::container )
> {
> proton::connection_options connectionOptions;
> connectionOptions.sasl_allow_insecure_mechs(true);
> connectionOptions.sasl_allowed_mechs("PLAIN");
> c.client_connection_options(connectionOptions);
>
> std::string url = "amqp://" + _account + ":" + _password + "@" +
> _host + ":" + std::to_string(_port) + "/" + _exchange;
>
> _sender = c.open_sender(url);
> }
>
> void on_sendable(proton::sender )
> {
> while (s.credit() && _sent < _count)
> {
> proton::message msg;
> msg.id(_sent + 1);
> msg.subject(_routingKey);
> msg.body(std::string(_size, '*'));
> msg.durable(true);
> s.send(msg);
> _sent++;
> std::cout << "-I sent " << _sent << " of " << _count <<
> std::endl;
> }
> }
>
> void on_tracker_accept(proton::tracker )
> {
> _confirmed++;
> if (_confirmed == _count)
> {
> std::cout << "-I- All messages (" << _confirmed << ")
> confirmed"
> << std::endl;
> t.connection().close();
> }
> }
>
> void on_transport_close(proton::transport )
> {
> _sent = _confirmed;
> }
>
> void run()
> {
> try
> {
> proton::default_container(*this).run();
> }
> catch (const std::exception )
> {
> std::cerr << "-E- Caught exception: " << error.what() <<
> std::endl;
> throw error;
> }
> }
> };
>
> int main(void)
> {
> Broadcaster("C7",
> "C7",
> "pc1wj611",
> 20001,
> "broadcast",
> "broadcast.C7_CashTransaction",
> 1000,
> 1024).run();
> return 0;
> }
>
>
>
>
> --
> 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: Java Broker performance

[Vavricka]

C++ client code below

#include 
#include 

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

class Broadcaster : public proton::messaging_handler
{

private:

std::string _account;
std::string _password;
std::string _host;
unsigned int _port;
unsigned int _count;
unsigned int _size;
unsigned int _sent;
unsigned int _confirmed;
std::string _exchange;
std::string _routingKey;
proton::sender _sender;

public:

explicit Broadcaster(const std::string ,
 const std::string ,
 const std::string ,
 unsigned int port,
 const std::string ,
 const std::string ,
 unsigned int count,
 unsigned int size)
: _account(account)
, _password(password)
, _host(host)
, _port(port)
, _count(count)
, _size(size)
, _sent(0)
, _confirmed(0)
, _exchange(exchange)
, _routingKey(routingKey)
{
}

void on_container_start(proton::container )
{
proton::connection_options connectionOptions;
connectionOptions.sasl_allow_insecure_mechs(true);
connectionOptions.sasl_allowed_mechs("PLAIN");
c.client_connection_options(connectionOptions);

std::string url = "amqp://" + _account + ":" + _password + "@" +
_host + ":" + std::to_string(_port) + "/" + _exchange;

_sender = c.open_sender(url);
}

void on_sendable(proton::sender )
{
while (s.credit() && _sent < _count)
{
proton::message msg;
msg.id(_sent + 1);
msg.subject(_routingKey);
msg.body(std::string(_size, '*'));
msg.durable(true);
s.send(msg);
_sent++;
std::cout << "-I sent " << _sent << " of " << _count <<
std::endl;
}
}

void on_tracker_accept(proton::tracker )
{
_confirmed++;
if (_confirmed == _count)
{
std::cout << "-I- All messages (" << _confirmed << ") confirmed"
<< std::endl;
t.connection().close();
}
}

void on_transport_close(proton::transport )
{
_sent = _confirmed;
}

void run()
{
try
{
proton::default_container(*this).run();
}
catch (const std::exception )
{
std::cerr << "-E- Caught exception: " << error.what() <<
std::endl;
throw error;
}
}
};

int main(void)
{
Broadcaster("C7",
"C7",
"pc1wj611",
20001,
"broadcast",
"broadcast.C7_CashTransaction",
1000,
1024).run();
return 0;
}




--
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: Java Broker performance

[Vavricka]

Hi, 

when consumer is not attached sending of messages is slow too. We were
running performance tests for Java Broker 6.1.1 before 6 months and there
were no issues (throughput for 1K messages was around 10MB/s).


rgodfrey wrote
> Hi Tomas, 
> 
> are you saying that there is a significant degradation in performance 
> between 7.0.0 and prior versions for this scenario, or do you see the same 
> performance in 6.1.x? 
> 
> In terms of consuming - is the performance slow if you are consuming from
> a 
> queue with 1000 messages already in it, or is the slowness just caused by 
> the slow producer? 
> 
> Thanks, 
> Rob

Code below is for JMS client 0.27.0 (without catching exceptions) which
behaves similarly as client based on proton 0.18.1.

Properties properties = new Properties();
properties.setProperty(Context.INITIAL_CONTEXT_FACTORY,
"org.apache.qpid.jms.jndi.JmsInitialContextFactory");
properties.setProperty("connectionfactory.connection",
"amqp://localhost:20406?jms.username=C7=C7");
properties.setProperty("topic.broadcastAddress", "broadcast");
InitialContext context = new InitialContext(properties);

Connection connection = ((ConnectionFactory)
context.lookup("connection")).createConnection();
Session session = connection.createSession(false,
Session.CLIENT_ACKNOWLEDGE);
MessageProducer broadcastProducer = session.createProducer((Destination)
context.lookup("broadcastAddress"));
connection.start();
char[] chars = new char[1024];
Arrays.fill(chars, 'f');
TextMessage message = session.createTextMessage(new String(chars));
message.setJMSDeliveryMode(DeliveryMode.PERSISTENT);
message.setJMSType("broadcast.C7_CashTransaction");
System.out.println(Instant.now());
int messageCount = 1000;
for (int i = 1 ; i <= messageCount ; i++)
{
broadcastProducer.send(message, DeliveryMode.PERSISTENT,
Message.DEFAULT_PRIORITY, Message.DEFAULT_TIME_TO_LIVE);
if (i % 100 == 0)
{
System.out.println(Instant.now() + " sent " + i + " messages");
}
}
System.out.println(Instant.now());

Output of client is below

[main] INFO com.deutscheboerse.amqp_1_0.examples.BroadcastSender - Creating
connection
[AmqpProvider :(1):[amqp://localhost:20406]] INFO
org.apache.qpid.jms.sasl.SaslMechanismFinder - Best match for SASL auth was:
SASL-SCRAM-SHA-256
[AmqpProvider :(1):[amqp://localhost:20406]] INFO
org.apache.qpid.jms.JmsConnection - Connection
ID:0333e24e-c00a-4dd7-91af-57fd1366512c:1 connected to remote Broker:
amqp://localhost:20406
2017-11-10T08:46:31.135Z
2017-11-10T08:46:41.770Z sent 100 messages
2017-11-10T08:46:52.449Z sent 200 messages
2017-11-10T08:47:03.958Z sent 300 messages
2017-11-10T08:47:15.174Z sent 400 messages
2017-11-10T08:47:25.514Z sent 500 messages
2017-11-10T08:47:36.045Z sent 600 messages
2017-11-10T08:47:46.432Z sent 700 messages
2017-11-10T08:47:57.797Z sent 800 messages
2017-11-10T08:48:09.434Z sent 900 messages
2017-11-10T08:48:20.419Z sent 1000 messages
2017-11-10T08:48:20.419Z


Keith Wall wrote
> Hi Tomas,
> 
> That does sound surprising.  These performance tests[1] are run, with
> BDB and using the latest Qpid JMS Client,  against both the Broker-J
> 7.0.0 and 6.1.4 code lines each day, which is consistently showing
> v7.0.0 is faster for the five use-cases exercised by the tests (see
> perftests/etc/testdefs/defaultTests.js).  I am interested to hear
> about your use-case.   Do you have code you can share?
> 
> cheers, Keith.





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