C++ client options

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

C++ client options

Daniel Pocock

Hi,

There are various C++ clients listed on the RabbitMQ web site:

https://github.com/alanxz/SimpleAmqpClient
- depends on boost
- MIT license

https://github.com/akalend/amqpcpp
http://code.google.com/p/rabbitcpp/
- no boost dependency
- MIT license (no license info in the github site though, it only
mentions the license on Google Code)

Can anybody comment on which of these projects (or others) to go with?

If we select one of these, I will probably make an official package for
it in Debian+Ubuntu

Regards,

Daniel


_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: C++ client options

Gotthard, Petr
All the C++ clients listed are wrappers around https://github.com/alanxz/rabbitmq-c.

I may be too old fashioned, but-- did you consider using the C client without any wrappers?


Petr

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Daniel Pocock
Sent: 7. srpna 2013 15:46
To: [hidden email]
Subject: [rabbitmq-discuss] C++ client options


Hi,

There are various C++ clients listed on the RabbitMQ web site:

https://github.com/alanxz/SimpleAmqpClient
- depends on boost
- MIT license

https://github.com/akalend/amqpcpp
http://code.google.com/p/rabbitcpp/
- no boost dependency
- MIT license (no license info in the github site though, it only mentions the license on Google Code)

Can anybody comment on which of these projects (or others) to go with?

If we select one of these, I will probably make an official package for it in Debian+Ubuntu

Regards,

Daniel


_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: C++ client options

alan.antonuk
As Petr mentioned: all of the C++ libraries listed wrap rabbitmq-c.  The major difference I see between the the different libraries mentioned is how well they handle asynchronous events. rabbitmq-c doesn't provide a lot of support API wise for dealing with async events like basic.deliver, or a channel.close as a result of a basic.publish failure.

SimpleAmqpClient tries to make some of the async bits more synchronous at the expense of performance. As far as I can tell the others listed don't do much in the way of error handling at a protocol level. 

My (biased) opinion is to use SimpleAmqpClient.  That said, you should evaluate the API and the performance of the library and see if it fits your needs.

Full disclosure: I'm the maintainer behind both SimpleAmqpClient and rabbitmq-c

-Alan


On Wed, Aug 7, 2013 at 9:16 AM, Gotthard, Petr <[hidden email]> wrote:
All the C++ clients listed are wrappers around https://github.com/alanxz/rabbitmq-c.

I may be too old fashioned, but-- did you consider using the C client without any wrappers?


Petr

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Daniel Pocock
Sent: 7. srpna 2013 15:46
To: [hidden email]
Subject: [rabbitmq-discuss] C++ client options


Hi,

There are various C++ clients listed on the RabbitMQ web site:

https://github.com/alanxz/SimpleAmqpClient
- depends on boost
- MIT license

https://github.com/akalend/amqpcpp
http://code.google.com/p/rabbitcpp/
- no boost dependency
- MIT license (no license info in the github site though, it only mentions the license on Google Code)

Can anybody comment on which of these projects (or others) to go with?

If we select one of these, I will probably make an official package for it in Debian+Ubuntu

Regards,

Daniel


_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss


_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: C++ client options

Chris-3
My team went through this decision a few months ago.  We decided to go with SimpleAmqpClient for a few reasons:
  • Its author (Alan) is very involved in the community and very responsive to questions.
  • Its author is intimately familiar w/ rabbitmq-c, so likely knows best how to leverage its capabilities
  • It seems to be better documented and more frequently maintained than the alternatives
Several months in, we're still happy with the choice we have made.  Of course we have our list of features we'd love to see implemented, but everything it does so far, it does well!  (Thanks, Alan!)

-Chris



On Wed, Aug 7, 2013 at 2:10 PM, Alan Antonuk <[hidden email]> wrote:
As Petr mentioned: all of the C++ libraries listed wrap rabbitmq-c.  The major difference I see between the the different libraries mentioned is how well they handle asynchronous events. rabbitmq-c doesn't provide a lot of support API wise for dealing with async events like basic.deliver, or a channel.close as a result of a basic.publish failure.

SimpleAmqpClient tries to make some of the async bits more synchronous at the expense of performance. As far as I can tell the others listed don't do much in the way of error handling at a protocol level. 

My (biased) opinion is to use SimpleAmqpClient.  That said, you should evaluate the API and the performance of the library and see if it fits your needs.

Full disclosure: I'm the maintainer behind both SimpleAmqpClient and rabbitmq-c

-Alan


On Wed, Aug 7, 2013 at 9:16 AM, Gotthard, Petr <[hidden email]> wrote:
All the C++ clients listed are wrappers around https://github.com/alanxz/rabbitmq-c.

I may be too old fashioned, but-- did you consider using the C client without any wrappers?


Petr

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Daniel Pocock
Sent: 7. srpna 2013 15:46
To: [hidden email]
Subject: [rabbitmq-discuss] C++ client options


Hi,

There are various C++ clients listed on the RabbitMQ web site:

https://github.com/alanxz/SimpleAmqpClient
- depends on boost
- MIT license

https://github.com/akalend/amqpcpp
http://code.google.com/p/rabbitcpp/
- no boost dependency
- MIT license (no license info in the github site though, it only mentions the license on Google Code)

Can anybody comment on which of these projects (or others) to go with?

If we select one of these, I will probably make an official package for it in Debian+Ubuntu

Regards,

Daniel


_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss


_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss



_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: C++ client options

Daniel Pocock
In reply to this post by alan.antonuk


On 07/08/13 20:10, Alan Antonuk wrote:
> As Petr mentioned: all of the C++ libraries listed wrap rabbitmq-c.  The
> major difference I see between the the different libraries mentioned is how
> well they handle asynchronous events. rabbitmq-c doesn't provide a lot of
> support API wise for dealing with async events like basic.deliver, or a
> channel.close as a result of a basic.publish failure.

Does this mean we need to block and/or use threads to receive messages?

Do you envisage making it work like boost::asio or have you seen
anything like that for AMQP?

> SimpleAmqpClient tries to make some of the async bits more synchronous at
> the expense of performance. As far as I can tell the others listed don't do
> much in the way of error handling at a protocol level.
>
> My (biased) opinion is to use SimpleAmqpClient.  That said, you should
> evaluate the API and the performance of the library and see if it fits your
> needs.
>
> Full disclosure: I'm the maintainer behind both SimpleAmqpClient and
> rabbitmq-c

Did you collaborate with anybody for the Debian package of the C client?
http://packages.debian.org/jessie/librabbitmq-dev

Has anybody discussed a package of the C++ client?


Just some background: I'm mentoring a student with Google Summer of
Code, he is making some changes to the reSIProcate project

reSIProcate is a strongly object-oriented C++ project, so to remain
consistent with the code style, using C++ would be nice.  Regular C
could be used too.  Some parts of the stack use asio, other parts use a
similar, single threaded async model.

What we have here is a SIP voice conferencing application:

  https://github.com/resiprocate/reConServer

The original version of the code just takes commands and prints
responses through stdin/stdout.  We would like to replace that with JSON
over RabbitMQ / AMQP

E.g.

- when a new caller dials in, a JSON message goes out on a topic

- the admin can send an instruction over a queue (e.g. move caller A
from room 1 to room 2)

_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: C++ client options

alan.antonuk

On Wed, Aug 7, 2013 at 1:49 PM, Daniel Pocock <[hidden email]> wrote:
Does this mean we need to block and/or use threads to receive messages?

Yes, the state of rabbitmq-c and SimpleAmqpClient when waiting for a delivery from a consumer is you need to block, optionally with a timeout.
 
The problem I'm stating is that AMQP has some async parts to the protocol, and rabbitmq-c doesn't do anything to handle these events as they're fired from the broker.  They're only 'seen' by rabbitmq-c when synchronous calls are made.


Do you envisage making it work like boost::asio or have you seen
anything like that for AMQP?

A few years back I started to implement a pure C++ AMQP client library leveraging boost::asio.  You can find it here:
The project was not completed. I don't have plans to resume work it.

Recently I have been doing a bit of design work to see what would be necessary to create an library that leverages libuv to make a fully-functional native AMQP client.
 
Did you collaborate with anybody for the Debian package of the C client?
http://packages.debian.org/jessie/librabbitmq-dev

That package is very old.  People have come to me time-to-time for assistance in creating a Ubuntu and/or Debian package, and not having a lot of knowledge in the process I do what I can to help out.  Currently there is some packaging material in the debian directory of the rabbitmq-c repo.  It is somewhat out of date, though not as old as what you've linked.

I personally would like to move the packaging details out of the repository to allow for different distributions to come up with their own independent packaging, as each distribution seems to do things in a slightly different and incompatible way. If you or someone you know is willing to step up and help maintain said package, I will do what I can to help out.


Has anybody discussed a package of the C++ client?

I haven't heard of anyone doing so.  One roadblock is that when SimpleAmqpClient was created it used a newer version of boost than came packaged with the LTS version of Ubuntu because it needed the boost.chrono library which was fairly new at the time.  I'm not sure if the situation has changed since then.

Again if you or someone you know is willing to step up and help maintain an SimpleAmqpClient package, I will do what I can to help out.


_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: C++ client options

Daniel Pocock
On 08/08/13 00:57, Alan Antonuk wrote:

On Wed, Aug 7, 2013 at 1:49 PM, Daniel Pocock <[hidden email]> wrote:
Does this mean we need to block and/or use threads to receive messages?

Yes, the state of rabbitmq-c and SimpleAmqpClient when waiting for a delivery from a consumer is you need to block, optionally with a timeout.
 
The problem I'm stating is that AMQP has some async parts to the protocol, and rabbitmq-c doesn't do anything to handle these events as they're fired from the broker.  They're only 'seen' by rabbitmq-c when synchronous calls are made.


Do you envisage making it work like boost::asio or have you seen
anything like that for AMQP?

A few years back I started to implement a pure C++ AMQP client library leveraging boost::asio.  You can find it here:
The project was not completed. I don't have plans to resume work it.

Recently I have been doing a bit of design work to see what would be necessary to create an library that leverages libuv to make a fully-functional native AMQP client.

Personally, I wouldn't want to favour any of these solutions over any other, they are all good.

The most important thing will be demonstrating how it integrates with higher level code, particularly if the high level code is using an event loop other than the one you choose yourself.  E.g. will the end user have to run your event loop in a thread and when they get callbacks from your code, they will have to pass data to their own event loop thread in a thread-safe manner?

Another thing that comes to mind is the question of adding an abstraction layer, just like JMS in the Java world.  The only one I've come across so far is OpenMAMA:
http://www.openmama.org - do you believe RabbitMQ users could benefit from coding to the OpenMAMA API and using some low-level driver for AMQP or RabbitMQ specifically?  This would be more like the JMS programming paradigm.


 
Did you collaborate with anybody for the Debian package of the C client?
http://packages.debian.org/jessie/librabbitmq-dev

That package is very old.  People have come to me time-to-time for assistance in creating a Ubuntu and/or Debian package, and not having a lot of knowledge in the process I do what I can to help out.  Currently there is some packaging material in the debian directory of the rabbitmq-c repo.  It is somewhat out of date, though not as old as what you've linked.


I'll contact the maintainers and if they are not actively updating it, I might volunteer to refresh it


I personally would like to move the packaging details out of the repository to allow for different distributions to come up with their own independent packaging, as each distribution seems to do things in a slightly different and incompatible way. If you or someone you know is willing to step up and help maintain said package, I will do what I can to help out.


Debian often maintains packaging artifacts in git repositories in alioth these days.  When we import your release tarball into our git repository, we can easily tell it to ignore any debian/ directory you have.  For older versions of Debian this was problematic though.  My own suggestion is that you can include your own debian/ artifacts in your repository if you wish to maintain them, but when you prepare a release tarball, exclude that subtree.


Has anybody discussed a package of the C++ client?

I haven't heard of anyone doing so.  One roadblock is that when SimpleAmqpClient was created it used a newer version of boost than came packaged with the LTS version of Ubuntu because it needed the boost.chrono library which was fairly new at the time.  I'm not sure if the situation has changed since then.


I would be aiming to introduce something in Debian unstable to begin with.  From there, it will propagate to other distributions over time and if those distributions operate commercially (like Ubuntu) and their clients really want it, they will hopefully collaborate with you to resolve the problem and contribute fixes for you.

Again if you or someone you know is willing to step up and help maintain an SimpleAmqpClient package, I will do what I can to help out.


I'd like to understand your feelings about the future of the API before committing to that - do you see something based on libuv happening in the near future, e.g. within 6 months?




_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: C++ client options

alan.antonuk
On Thu, Aug 8, 2013 at 1:46 AM, Daniel Pocock <[hidden email]> wrote:
The most important thing will be demonstrating how it integrates with higher level code, particularly if the high level code is using an event loop other than the one you choose yourself.  E.g. will the end user have to run your event loop in a thread and when they get callbacks from your code, they will have to pass data to their own event loop thread in a thread-safe manner?

Noted. 

Another thing that comes to mind is the question of adding an abstraction layer, just like JMS in the Java world.  The only one I've come across so far is OpenMAMA:
http://www.openmama.org - do you believe RabbitMQ users could benefit from coding to the OpenMAMA API and using some low-level driver for AMQP or RabbitMQ specifically?  This would be more like the JMS programming paradigm.

I believe something like this would be something layered on top of the protocol library, and not necessarily baked into the library itself. As to whether you should go this direction, I would imagine it depends on the requirements for whatever you're doing.


I'd like to understand your feelings about the future of the API before committing to that - do you see something based on libuv happening in the near future, e.g. within 6 months?


I don't plan on making any drastic API changes to SimpleAmqpClient, its purpose in my eyes is to give an easy interface to using rabbitmq-c from C++, so it will continue to develop SimpleAmqpClient to support the various bits of functionality that rabbitmq-c supports.  A libuv-based library will likely be developed under a different library name, whether or not the functionality gets rolled back into an existing library is TBD.  Will this happen in 6 months? I have no idea - it depends on how much free time I have to work on these kinds of projects.


_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: C++ client options

Daniel Pocock


On 08/08/13 20:05, Alan Antonuk wrote:

>
>>
>> Another thing that comes to mind is the question of adding an abstraction
>> layer, just like JMS in the Java world.  The only one I've come across so
>> far is OpenMAMA:
>> http://www.openmama.org - do you believe RabbitMQ users could benefit
>> from coding to the OpenMAMA API and using some low-level driver for AMQP or
>> RabbitMQ specifically?  This would be more like the JMS programming
>> paradigm.
>>
>
> I believe something like this would be something layered on top of the
> protocol library, and not necessarily baked into the library itself. As to
> whether you should go this direction, I would imagine it depends on the
> requirements for whatever you're doing.

I agree - the Avis MQ solution appears to work like that:

- C++ Application code
- OpenMAMA C++ API
- OpenMAMA itself
- Avis "bridge" code (part of OpenMAMA repository)
- Avis C client layer

So to phrase my comments another way: instead of re-inventing or
extending the C++ API that exists now, maybe the work involved in making
such a bridge module delivers more benefit for the C++ user and/or is
easier to achieve

Here are some demos that show how a C++ user codes to the OpenMAMA API:

http://git.openmama.org/?p=OpenMAMA.git;a=blob;f=mama/c_cpp/src/examples/cpp/mamapublishercpp.cpp;hb=HEAD

http://git.openmama.org/?p=OpenMAMA.git;a=blob;f=mama/c_cpp/src/examples/cpp/mamasubscribercpp.cpp;hb=HEAD


and here are the bridges for Qpid and Avis:

http://git.openmama.org/?p=openmama-qpid.git;a=tree;f=mama/c_cpp/src/c/bridge;h=f4747d48a008bae21891b78d5cfeb5fd8f47713c;hb=HEAD


>>
>>
>> I'd like to understand your feelings about the future of the API before
>> committing to that - do you see something based on libuv happening in the
>> near future, e.g. within 6 months?
>>
>>
>> I don't plan on making any drastic API changes to SimpleAmqpClient, its
> purpose in my eyes is to give an easy interface to using rabbitmq-c from
> C++, so it will continue to develop SimpleAmqpClient to support the various
> bits of functionality that rabbitmq-c supports.  A libuv-based library will
> likely be developed under a different library name, whether or not the
> functionality gets rolled back into an existing library is TBD.  Will this
> happen in 6 months? I have no idea - it depends on how much free time I
> have to work on these kinds of projects.
>

Ok, that's fine - I didn't want to put any urgency on it, just to get a
feeling for the future direction of each component


_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: C++ client options

Gordon Sim-2
In reply to this post by Daniel Pocock
On 08/07/2013 09:49 PM, Daniel Pocock wrote:

> Just some background: I'm mentoring a student with Google Summer of
> Code, he is making some changes to the reSIProcate project
>
> reSIProcate is a strongly object-oriented C++ project, so to remain
> consistent with the code style, using C++ would be nice.  Regular C
> could be used too.  Some parts of the stack use asio, other parts use a
> similar, single threaded async model.
>
> What we have here is a SIP voice conferencing application:
>
>    https://github.com/resiprocate/reConServer
>
> The original version of the code just takes commands and prints
> responses through stdin/stdout.  We would like to replace that with JSON
> over RabbitMQ / AMQP

Would publishing over MQTT be an option? That might give further choices
in client library.
_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: C++ client options,sending message

vinod
This post has NOT been accepted by the mailing list yet.
In reply to this post by Daniel Pocock

issue is facing when run
AMQP error UNEXPECTED_FRAME - expected content header for class 60, got non content header frame instead
Error reading:system:104


















#include <iostream>
#include <boost/date_time/posix_time/posix_time.hpp>
#include <thread>
#include "asiohandler.h"

int main(void)
{
        try
        {

                boost::asio::io_service ioService;
                AsioHandler handler(ioService);
                handler.connect("localhost", 5672);
                AMQP::Connection connection(&handler, AMQP::Login("guest", "guest"), "/");
                AMQP::Channel channel(&connection);
                std::thread t([&ioService](){ioService.run(); });
                //ioService.run();
                boost::asio::deadline_timer tm(ioService, boost::posix_time::millisec(100));
                int i=0;
                while(1)
                {
                        channel.onReady([&]()
                                        {
                                        if(handler.connected())
                                        {

                                        {
                                        const std::string msg="A missed call on Nirmal's father Prasanna's cellphone on August 14 got the police going. Vasaigaon inspector Sampatrao Patil activated his contacts and traced the call to Surat. He contacted his counterparts in Amroli and traced Nirmal to a shanty belonging to a pani puri vendor Karan Singh.While it is unclear whether the call was made by Singh to extort money from Prasanna, he admitted to having failed in intimating the cops about Nirmal. The teen is believed to have approached Singh for a job when he learnt that had lost his direction. Nirmal during his stay with Singh had shared his family details.Nirmal who lost his mother a few months ago used to speak about wanting to fight terrorists in Kashmir. His friends had ridiculed him. According to Prasanna who works in the BMC, Nirmal loves history and has spoken about wanting to go to Kashmir. But I never thought he would think of venturing out alone. The current crisis in Kashmir had disturbed the boy.\n";
                                        //Envelope Emsg(msg.c_str(),msg.length());
                                        channel.publish("", "hello", msg);
                                        std::cout <<":Time:"<<time(0)<<",[x] Sent 'Hello World!'\n" << std::endl;
                                        }
                                        }
                                        });

                        //tm.async_wait([&](const boost::system::error_code&){ioService.stop();});
                        usleep(5);
                }
                t.join();
        }
        catch (std::exception& e)
        {
                std::cerr << "Exception: " << e.what() << "\n";
        }
        return 0;
}
~





Loading...