Re: Need help compiling in Visual Studio QPID C++

2017-11-13 Thread Justin Ross
Hi, Paul.  What are the errors you are seeing?

I gave it a try on AppVeyor, and I immediately ran into a problem with a
newer version of msbuild.

  https://ci.appveyor.com/project/ssorj/qpid-cpp/build/1.0.13

Chuck, what does that portend?  Do we need to generate new build metadata
for Windows?

On Mon, Nov 13, 2017 at 2:22 PM, Flores, Paul A. 
wrote:

> Help!
>
>
> CMake is not cooperating/working with Visual Studio and I am about running
> out of hair to pull! Only issues in the Linux world were self induced not
> sure about this windows environment!
>
>
> Can anyone give me a bit of help?  I have a very narrow window to prove
> QPID is a viable alternative for a new manufacturing application,
>
>
> Any help would be greatly appreciated to get QIP CPP compiled!
>
>
> Paul
>
>
> 
>
> This communication (including any attachments) may contain information
> that is proprietary, confidential or exempt from disclosure. If you are not
> the intended recipient, please note that further dissemination,
> distribution, use or copying of this communication is strictly prohibited.
> Anyone who received this message in error should notify the sender
> immediately by telephone or by return email and delete it from his or her
> computer.
>


Need help compiling in Visual Studio QPID C++

2017-11-13 Thread Flores, Paul A.
Help!


CMake is not cooperating/working with Visual Studio and I am about running out 
of hair to pull! Only issues in the Linux world were self induced not sure 
about this windows environment!


Can anyone give me a bit of help?  I have a very narrow window to prove QPID is 
a viable alternative for a new manufacturing application,


Any help would be greatly appreciated to get QIP CPP compiled!


Paul




This communication (including any attachments) may contain information that is 
proprietary, confidential or exempt from disclosure. If you are not the 
intended recipient, please note that further dissemination, distribution, use 
or copying of this communication is strictly prohibited. Anyone who received 
this message in error should notify the sender immediately by telephone or by 
return email and delete it from his or her computer.


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

2017-11-13 Thread Oleksandr Rudyy
There were 5 binding +1 votes, 1 non-binding +1 vote, and no other
votes received. The vote has passed.

The voting thread can be found here:
https://lists.apache.org/thread.html/093f7481ff6814e696b2f5d24d9134fb9d8d960f57b60566489e8a64@%3Cusers.qpid.apache.org%3E

I will add the files to the dist release repo and create the final tag
shortly. The website will be updated after the release has had time to
sync to the mirrors.

Kind Regards,
Alex


Re: HA Cluster using Qpid C++ Broker 1.36.0

2017-11-13 Thread Chester
https://www.clusterlabs.org/doc/en-US/Pacemaker/1.1-pcs/html/Clusters_from_Scratch/index.html
will get you started with pacemaker. The DRBD walkthrough is easy enough to
follow to start understanding the clustering system.

For qpidd, you'll need the following resources:

1. qpidd service clone (1 running on each node) resource
2. cluster vip (service/cluster/VIP address) resource
3. qpidd-primary service resource
4. fence resources

My config looks like this:

[root@node-01 ~]# pcs status

Cluster name: qpid_mgmt_broker_cluster

Stack: corosync

Current DC: node-01.subdomain.domain.com (version
1.1.15-11.el7_3.5-e174ec8) - partition with quorum

Last updated: Mon Nov 13 11:01:38 2017Last change: Thu Nov  9 17:42:21
2017 by root via crm_attribute on node-03.subdomain.domain.com


3 nodes and 8 resources configured


Online: [ node-01.subdomain.domain.com node-02.subdomain.domain.com
node-03.subdomain.domain.com ]


Full list of resources:


 Clone Set: qpidd-service-clone [qpidd-service]

 Started: [ node-01.subdomain.domain.com node-02.subdomain.domain.com
node-03.subdomain.domain.com ]

 cluster-vip  (ocf::heartbeat:IPaddr2): Started node-01.subdomain.domain.com

 qpidd-primary-service  (lsb:qpidd-primary):  Started
node-01.subdomain.domain.com

 node-01_fence_xvm (stonith:fence_xvm):  Started
node-02.subdomain.domain.com

 node-02_fence_xvm (stonith:fence_xvm):  Started
node-03.subdomain.domain.com

 node-03_fence_xvm (stonith:fence_xvm):  Started
node-02.subdomain.domain.com


Daemon Status:

  corosync: active/enabled

  pacemaker: active/enabled

  pcsd: active/enabled


https://qpid.apache.org/releases/qpid-cpp-1.36.0/cpp-broker/book/chapter-ha.html
is good too.

On Fri, Nov 10, 2017 at 4:53 AM, andi welchlin 
wrote:

> 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

2017-11-13 Thread Vavricka
It is ok for us to release 7.0.0 and implement this issue in 7.0.1.

Vast majority of our applications need this functionality.

Tomas


Keith Wall wrote
> 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 

> rob.j.godfrey@

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

> vavricka.tomas@

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

qpidcpp - identifying messages from on_tracker_accept/on_tracker_reject

2017-11-13 Thread Olivier Delbeke
 Hi,

How can I identify the accepted/rejected message from within a 
messaging_handler::on_tracker_accept() or 
messaging_handler::on_tracker_reject() callback ? I get rejections with "please 
retry in 10s" from ServiceBus, and I'd like to know which message I have to 
re-send...
I guess that this info is available in the AMQP packets ('first='?) I can't see 
any way to add a message reference inside a tracker object.

Thank you,