I'm new to JMS. I'm using ActiveMQ CPP (C++ version), but most probably my questions are language agnostic:
I saw that using didn't worked
failover:(tcp://N.N.N.N)?timeout=1000
while this works
failover://(tcp://N.N.N.N)?timeout=1000
When this change occurred and why?
According to TCP configuration, there's option connectionTimeout, but I don't see in a code. Do I miss something?
Connection options (e.g. connnection.closeTimeout) in case uri looks like failover:://(tc://N.N.N.N?a=b)?x=y should be applied to tcp or failover. Is there good link describing these options in depths?
Thanks
See the ActiveMQ-CPP URI configuration reference here:
http://activemq.apache.org/cms/configuring.html
There are some differences in the URI parsing between the C++, Java and .NET clients due to the available SDKs of each language.
Tim
www.fusesource.com
Related
A little background: I would like to build my API in Chapel as a docker container on Azure (or AppEngine) using a Crate.io database and ODBC drivers.
Is there an HTTP server I can use with Chapel?
Currently, there is no official HTTP server support in Chapel, but the Chapel
team does plan to work on this in the future.
The project "Write a web server in Chapel" is listed as a suggested
project idea on Chapel's Google Summer of Code (GSoC) page. For GSoC 2016, Chapel had several applicants for this specific project, one of
which even coded up a toy web server in Chapel. However, this project was not
selected for GSoC 2016.
Hopefully this is a project that will get more attention in the near future.
We are working in an simple http server (based on libevent2) at https://github.com/marcoscleison/chapel-http .
The project is in inital commits but you can see and have an idea how to create an http server.
One more note - see https://github.com/briangu/chearch/ for an example program that rolls its own server in Chapel. Also, note that ZeroMQ support is in progress in this pull request: https://github.com/chapel-lang/chapel/pull/3592. Hopefully you can find alternative solutions from one of those resources, although I don't think there's really anything wrong with using stdout and CGI.
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.
Does the Jetty Servlet container use OpenSSL, and is it vulnerable to the Heartbleed bug?
I think it should not be impacted as it is supposed to use its own implementation of SSL but I don't know enough of what's going on under the hood to be sure.
From older Jetty docs:
This is an overview of how to configure SSL for Jetty, which uses Sun's reference implementation for the Java Secure Sockets Extension (JSSE).
I would imagine this still holds, though depending on your use case you may want to wait for a more authoritative answer (or ping Jetty devs directly).
EDIT: bumping this up from the comments below. This question has been answered on the jetty-users list:
http://dev.eclipse.org/mhonarc/lists/jetty-users/msg04624.html
I need opensource Web Sockets API using libevent in C/C++. Please show me where to find it.
You could use evws or libwebsock which is based on libevent. I haven't used it yet for myself but it looks quite promising.
If it doesn't match your requirements you could build something yourself (probably based on libevtp which provides an improved HTTP API for libevent). See RFC 6455 for the protocol specification.
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.