I'm trying to implement a solution using HornetQ. Since I need to access it through a C++ application, that raises me a problem. I'm compiling the activemq-cpp builtin example, and changing it to work with stomp instead of openwire (HornetQ doesn't understand openwire). The application refuses to produce messages on the intended queue. Seems that a lot of people are having the same issue, but no one has the answer. (someone said it's a bug on the cms API)
Anyone has a pratical example of HornetQ working with a C++ app?
PS: Obviously the activemq-cpp example works with an activemq server using openwire.
HornetQ is probably mapping destination names differently then the ActiveMQ C++ Stomp client, for instance in ActiveMQ a topic destination is prefixed with /topic/ and a queue is /queue/. I beleive this is different in HornetQ but not really sure. You may want to look in their docs for what they use, if its configurable then you could alter it to match what the CMS client is sending. You could also modify your local copy of CMS to send the destination name using the HornetQ prefix.
Regards
Tim.
www.fusesource.com
The only solution I have seen is a HornetQ to ActiveMQ bridge written in java then have the C++ app work with ActiveMQ. You might be able to do something with JNI to handle marshaling messages into your app.
Related
While running through the qpid c++ api tutorial I ran into "Session ended by peer with amqp:internal-error" which i assume is because of different versions of the qpid api and my broker (Rabbitmq).
I have changed the rabbitmq to use protocol 1.0, but it looks like qpid defaults to 0-10. I have found a bunch of articles saying I should move up to version 1.0 of the api, but I have not been able to find out how. Does anyone know how to do this?
Figured out the solution, when creating connection you can set protocol there, though i think you may need qpid-proton installed as well.
Connection connection("rabbitmq-serv:5672","{protocol: 'amqp1.0'}");
It still gets failures, but rabbitmq seems to acknowledge that it exists
Also qpid-proton seems to connect to rabbitmq no problem, using the amqp1.0 by default
I am trying to to implement interprocess communication in my C++ project using ActiveMQ CMS library. For this matter I use the following URI:
failover:(vm:(broker:(tcp://localhost:6000)?persistent=false)?marshal=false)
Though it does not seem to work. The connection to broker stucks while waiting for a response from it. I think maybe VM protocol is not implemented in CMS. In fact I could not find any "VM" string reference in CMS source code.
If so what is the best library for inter-process communication. I need consumer/producer pattern that works really fast.
There is no VM transport in CMS as there is no 'VM' since it is a C++ client. You need to look into more standard mechanisms for interprocess communication.
I have a C++ application that needs to send structured data to an Akka actor. The best option I found (Google, stackoverflow...) is to use protocol buffer and ZeroMQ, since it looks like everyone recommends it.
However I struggled the whole day trying to make it work, having various crashes into my Scala actor code (with strange Windows socket errors). And when I take a deeper look at it, I notice that it seems zeromq disappeared from the Akka official documentation a while ago, and the most recent documentation I read about it said that ZeroMQ 3 was still not supported by zeromq-scala-bindings underneath (while the version 4 is already out).
Would it be a better option to use the Camel-netty extension and pass the information through JSON ?
Thanks !
A fairly simple way would be to write a HTTP endpoint using Spray.io. Spray has JSON support and since it is built on Akka it communicates seamlessly with other Actors. This has the advantage that the data you send to the endpoint does not have to match the message format the Actor is expecting. You can change the message the actor is expecting without changing what your C++ code sends. For bi-directional communication there is also web socket support.
I am a little new to active MQ so please bear with me.
I am trying to take advantage of the ActiveMQ priority backup feature for some of my Java and CPP applications. I have two brokers on two different servers (local and remote), and I want the following behavior for my apps.
Always connect to local broker on startup
If local broker goes down, connect to remote
While connected to remote, if local comes back up, we then reconnect to local.
I have had success with testing it on the java apps by simply adding priorityBackup to my uri options
i.e.
failover:(tcp://local:61616,tcp://remote:61616)?randomize=false&priorityBackup=true
However stuff isn't going as smoothly on the CPP side.
The following works fine on the CPP apps (with basic working failover functionality - aka jumping to remote when local goes down )
failover:(tcp://local:61616,tcp://remote:61616)?randomize=false
But updating the uri options with priorityBackup seems to break failover functionality completely (my apps never failover to the remote broker, they just stay in some kind of broker-less/limbo state when their local broker goes down)
failover:(tcp://local:61616,tcp://remote:61616)?randomize=false&priorityBackup=true
Is there anything I am missing here? Extra uri options that I should have included?
UPDATE: Transport connector info
<transportConnectors>
<transportConnector name="ClientOpenwire" uri="tcp://0.0.0.0:61616?wireFormat.maxInactivityDuration=7000"/>
<transportConnector name="Broker2BrokerOpenwire" uri="tcp://0.0.0.0:62627?wireFormat.maxInactivityDuration=5000"/>
<transportConnector name="stompConnector" uri="stomp://0.0.0.0:62623"/>
</transportConnectors>
backup and priorityBackup parameters are handled in completely different way in Java and C++ implementation of the library.
Java implementation works well but unfortunately C++ implementation is broken. There are no extra options that can fix this issue. Serious changes in library are required to resolve this issue.
I was testing this issue using activemq-cpp-library-3.8.3, and brokers in various versions (5.10.0, 5.11.1). Issue is not fixed in 3.8.4 release.
I have some framework doing specific task in C++ and a django-based web app. The idea is to launch this framework, receive some data from it, send some data or request and check it's status in some period.
I'm looking for the best way of communication. Both apps run on the same server. I was wondering if a json server in C++ is a good idea. Django would send a request to this server, and server would parse it, and delegate a worker thread to complete the task. Almost all data that need to be send is string-like. Other data will be stored in database so there is no problem with that.
Is JSON a good idea? Maybe you know some better mechanism for local communication between C++ and django?
If your requirement is guaranteed to always have the C++ application on the same machine as the Django web application, include the C++ code by converting it into a shared library and wrapping python around it. Just like this Calling C/C++ from python?
JSON and other serializations make sense if you are going to do remote calls and the code needs to communicate across machines.
JSON seems like a fair enough choice for data serialization - it's good at handling strings and there's existing libraries for encoding/decoding JSON in both python & C++.
However, I think your bigger problem is likely to be the transport protocol that you use for transferring JSON between your client and server. Here's some options:
You could build an HTTP server into your C++ application (which I think might be what you mean by "JSON server" in your question), which would work fine, though might be a bit of a pain to implement unless you get a hold of a library to handle the hard work for you.
Another option might be to use the 0MQ library to send JSON (or otherwise) messages between your client and server. I think this would probably be a lot easier than implementing a full HTTP server, and 0MQ has some interprocess communication code that would likely be a lot faster than sending things over the network.
A third option would just be to run your C++ as a standalone application and pass the data in to it via stdin or command line parameters. This is probably the simplest way to do things, though may not be the most flexble. If you were to go this way, you might be better off just building a Python/C++ binding as suggested by ablm.
Alternatively you could attempt to build some sort of job queue based on redis or something other database system. The idea being that your django application puts some JSON describing the job into the job queue, and then the C++ application could periodically poll the queue, and use a seperate redis entry to pass the results back to the client. This could have the advantage that you could reasonably easily have several "workers" reading from the job queue with minimal effort.
There's almost definitely some other ways to go about it, but those are the ones that immediately spring to mind.