We have an framework 3.5 app that needs to interact with some RabbitMQ queues
RabbitMQ's .net client 3.4.3 does support framework 3.5, however is quite old, and I want to known if this version of the client can work out as a consumer for RabbitMQ newests versions
Does anyone knows?
Yes, the 3.4.3 .NET client should work with current RabbitMQ versions. The AMQP protocol has not changed.
The easiest way to verify is to try it out yourself, or, check out the .NET client code at that version and run the tests yourself.
https://github.com/rabbitmq/rabbitmq-dotnet-client/tree/rabbitmq_v3_4_3
NOTE: the RabbitMQ team monitors the rabbitmq-users mailing list and only sometimes answers questions on StackOverflow.
Related
We are using rabbitmq 3.6.9 version install on a single linux box. As part of the client security vulnerability check following concerns are raised for rabbitmq server.
Can anyone please guide us on resolving the following vulnerabilities.
DOM-based Cross Site Scripting Vulnerability (http-client-side-xss)
jQuery Vulnerability: CVE-2012-6708 (jquery-cve-2012-6708)
jQuery Vulnerability: CVE-2014-6071 (jquery-cve-2014-6071)
Kindly provide your inputs.
RabbitMQ 3.6.9 is over two years old!
It makes absolutely no sense to run security checks on old software!
You should be using RabbitMQ 3.8.0 or 3.7.19.
NOTE: the RabbitMQ team monitors the rabbitmq-users mailing list and only sometimes answers questions on StackOverflow.
I'm involved in a project with many others companies. We started to develop our systems at the same time but only at the end the communication problem was taken into account.
I've developed my system on Linux with Mono (Linux is mandatory for me). I have to communicate with a Windows .Net system which is exposing a Wcf web services. Unfortunately they told me only now they are using wsHttpBinding and I've just discovered that this communication protocol is not supported by Mono.
I'm here to ask if there is a way to communicate with that web service. They are not going to change the wsHttpBinding because is used by many other companies. I cannot change my OS and my code base is too big to leave Mono now. I can only add a layer (always on Linux) between my Mono implementation and their web services.
Any suggestions?
Microsoft has recently released the .NET source code as MIT licence (open source).
This means that, if something is not supported by Mono, you can just bring the code yourself and incorporate it, so that it becomes officially supported.
Some Mono developers have actually been doing this the past weeks to incorporate things that they had not implemented yet. So you could bring the wsHttpBinding along to Mono. An example of such a change is this commit.
Is it possible to implement a RabbitMQ RPC between Java (acting as a client) and a .NET application (server/worker) using the RabbitMQ .NET library?
It seems like it should be possible, as RabbitMQ broker handles the queues and the socket connections are established between party and the RabbitMQ broker.
Are there any practical considerations in doing so?
The short answer is yes. In fact, my company uses RabbitMQ for that very reason - it offers a platform-neutral (as close as possible anyway) way to communicate between different applications. So in theory, I could have Java applications running on Linux and .NET applications running on Windows, and everything works together just fine.
You will need to come up with a common serialization format for your messages; I recommend using JSON as there are JSON libraries in every major programming language.
If you have any trouble with the RabbitMQ .NET library, feel free to post more questions :-)
What is the impact on existing code to migrate from WebSphere MQ V6 to V7?
Can we make simply the change?
Like all good questions, the answer here is "it depends."
First of all, don't go to v7.0, go to V7.1 at least, better yet to V7.5.
Using client or bindings mode connections? You can upgrade the QMgr without touching a client-based app in most cases. Any version of WMQ client can talk to any version of WMQ server, however its best not to leave apps on an unsupported version of WMQ client. Of course, the app running on the old client won't get the new function such as automatic reconnect or performance improvements, even though the QMgr is at V7.5.
Using SSL? The SSLPEER element order changed and the commands to manage certificates changed. Good news, cert management is now performed with runmq*km commands living in the {mq install}/bin directory so you don't need to hunt down the GSKit directory and figure out whether to use gsk6*, gsk7* or gsk8* commands.
If you go from 32 to 64 bit, you may need to recompile programs or exits.
Correct settings for PATH, CLASSPATH and LIBPATH change across versions.
There's much more and it's well covered in the Infoceenter. Each Infocenter has a section on migration. Within that section, there's subsections by version and within those there are subsections by platform. Pick the target version of WMQ (that's V7.5, right? Say yes!) and and drill down. Start here:
Migration from V6.0 to V7.5
Migration from V6.0 to V7.1
Migration from V6.0 to V7.0
There is NServiceBus handler run on .net 4.0. I need to start it from VS 2008 project with 3.5 runtime (more specifically from SSIS 2008). The message to be send to the handler is parameter-less. What I tried:
I can not use NServiceBus API because of different .net versions, just can not add reference to the newer runtime library.
My other idea was to use NServicebus Gateway, but it turned out to be too difficult to run (xml+jsonp+get protocol with bunch of params) and lack of documentation.
Then I tried to send MSMQ message, but it did not work as well, because NServiceBus requires it to has special caption and extension message area which I can not specify, and it would be not reliable enough even if I could.
Are any other ideas on how to run simple parameter-less handler?
You can use the 2.6 version of NServiceBus which supports .net 3.5 - available here: http://www.nservicebus.com/Downloads.aspx