does anyone of you have some experience using OpenWhisk together with an AMQP feed? I have a RabbitMQ infrastructure with multiple queues and events which should feed into Openwhisk triggers and execute my docker containers.
Sadly I did not found much on the Internet about OpenWhisk in connection with AMQP/RabbitMQ
Many Thanks
An example feed provider for AMQP brokers has recently been published:
https://github.com/cliffjansen/amqp-wsk-feed
This is an open-source feed provider and not currently included in the core platform. You will have to manage and run the feed provider service to use this functionality.
Another option would be to enable the webhooks plugin for RabbitMQ: https://github.com/jbrisbin/rabbitmq-webhooks
Webhooks could be configured to invoke Web Actions on the platform.
Related
I need to know basic difference between rabbitmq and "compose for rabbit" as a service in IBM cloud.
There is only one production-level RabbitMQ service in the IBM Cloud catalog: Compose for RabbitMQ.
The other service, rabbitmq, is an old, deprecated, experimental service that was part of Cloud Foundry. It should not be used and when you click it, it should redirect you to the Compose for RabbitMQ service.
I am looking in for the best way to implement the RabbitMQ consumer by using .Net Client which should be run as windows service.
I referred the RabbitMQ documentation and found the way to consume messages by using .Net client (https://www.rabbitmq.com/tutorials/tutorial-one-dotnet.html).
My current scenario is like, RabbitMQ is installed in AWS VM machine. I have to install dotnet client consumer service resides in On-premise network which should consume messages.
Which one is the best way, to always listen the Queue (AMQP protocol) or HTTP API which should get messages on demand (https://pulse.mozilla.org/api/).
Please advise.
Thanks,
Vinoth
I believe the answer is "neither." You should have your message queue as a back-end service behind the firewall, and expose your application functionality through a set of carefully-specified web services. The web services, which are exposed through the firewall but can communicate to services behind the firewall, would produce messages that would be transmitted to the server. Any services needing to produce or consume messages would need to do so via the web services, which would perform safety/security checking prior to forwarding the request on to the AMQP server.
If you need to expose AMQP directly to clients (i.e. that is the purpose of your app), then the recommendation is to do so via STOMP. I think a valid use case for exposing AMQP directly over the internet would be a rare thing to come across. The security implications of doing so would be immense.
I am new to cloud foundry and investigating possible ways for our legacy Java EE application to communicate asynchronously with an application running on cloud foundry.
We are doing a lot of asynchronous work already and are publishing events to Active MQ.
I know that cloud foundry has a possibility to bind with Rabbit MQ and my question is with the possibility for a cloud foundry running application to connect (listen) to an existing out of CF platform Rabbit MQ?
Any idea on other alternatives to achieve this?
Yes, that is possible. You can use a user provided service.
That allows you to inject the environment variables into your app, that are needed to connect to RabbitMQ (like host, port, vhost, username, password).
Once you create that service, you can bind it to your app. Inside your app code, you then can read the environment variables exactly the same way as you would do it, if you had used a RabbitMQ service provided by CloudFoundry.
I have explored the web on MULE and got to understand that for Apps to communicate among themselves - even if they are deployed in the same Mule instance - they will have to use either TCP, HTTP or JMS transports.
VM isn't supported.
However I find this a bit contradictory to ESB principles. We should ideally be able to define EndPoints in and ESB and connect to that using any Transport? I may be wrong.
Also since all the apps are sharing the same JVM one would expect to be able to communicate via the in-memory VM queue rather than relying on a transactionless HTTP protocol, or TCP where number of connections one can make is dependent on server resources. Even for JMS we need to define and manage another queue and for heavy usage that may have impact on performances. Though I agree if we have distributed and clustered systems may be HTTP or JMS will be only options.
Is there any plan to incorporate VM as a inter-app communication protocol or is there any other way one Flow can communicate with another Flow Endpoint but in different app?
EDIT : - Answer from Mulesoft
http://forum.mulesoft.org/mulesoft/topics/concept_of_endpoint_and_inter_app_communication
Yes, we are thinking about inter-app communication for a future release.
Still is not clear when we are going to do it but we have a couple of ideas on how we want this feature to behave. We may create a server level configuration in which you can define resources to use in all your apps. There you would be able to define a VM connector and use it to send messages between apps in the same server.
As I said, this is just an idea.
Regarding the usage of VM as inter-app communication, only MuleSoft can answer if VM will have a future feature or not.
I don't think it's contradictory to the ESB principle. The "container" feature is pretty well defined in David A Chappell's "Enterprise Service Bus book" chapter 6. The container should try it's best to keep the applications isolated.
This will provide some benefits like "independently deployable integration services" (same chapter), easier clusterization, and other goodies.
You should approach same VM inter-app communications as if they where between apps placed in different servers.
Seems that Mule added in 3.5 version, a feature to enable communication between apps deployed in the same server. But sharing a VM connector is only available in the Enterprise edition.
Info:
http://www.mulesoft.org/documentation/display/current/Shared+Resources#SharedResources-DefiningDomains
Example:
http://blogs.mulesoft.org/optimize-resource-utilization-mule-shared-resources/
I have deployed a multi node application to cloud foundry, all connected via a shared rabbitmq service. The application consists of:
A grails app.
3 standalone spring-integration-amqp java apps.
All are communicating to rabbit via spring-integration-amqp, using cloud:rabbit-connection-factory.
All of the applications have the same rabbitmq service bound.
All of the applications start correctly and seem to connect to rabbit ok.
The behaviour I am seeing is that the grails app is timing out whilst waiting for a response from one of the standalone apps. This is consistent with me only starting up the grails app locally and not the message consumers.
What I am struggling with is how to debug where the problem is.
I can't see any errors in the logs
It doesn't seem possible to tunnel to the rabbitmq service in order to query the state of the queues etc.
Any ideas?
Are you pushing to cloudfoundry.com or micro cloudfoundry?
To answer your questions:
Have you tried using "vmc file"? For java web applications cloudfoundry uses tomcat as the app server and you can use that command to navigate to tomcat/logs to have a look. Maybe some stdout was redirected there.
Did you have Caldecott installed? If you did not read this doc, here it is: http://docs.cloudfoundry.com/tools/vmc/caldecott.html