I'm reading the Mule ESB documentation, and there is a lot of references to VM Queues. Is this some sort of JMS implementation? What is meant by it, and where can I find more info?
Thanks in advance,
It is a Mule specific transport for messaging within the same VM (i.e. the mule standalone server or the tomcat instance mule has been deployed to). The transport can implement queuing with in-memory or on-disk storage, but there aren't any reliability guarantees.
See here:
http://www.mulesoft.org/documentation/display/MULE2USER/VM+Transport
http://mulesux.tumblr.com/post/3102264921/murphys-law-or-dropping-the-ball
I've never worked with Mule, but I read some docs a few years ago.
I believe VM queues would reside in memory within the JVM. I think it's a way to use SOA constructs between Java Beans, so that local POJO methods can be treated as services. That way, if you some day want to replace that POJO with an external service or host it elsewhere, you only have to change the configuration of that service.
This is all conjecture from the small amount of Mule I recall, so definitely verify, verify, verify. :-)
Related
I would like to know are there feature wise same or different? Could you also mention any pros and cons about both of these? Also please mention real-world use case for both Embedded BrokerService vs installed ActiveMQ broker. Thanks in advance!
ActiveMQ is just a Java application, and the embedded version offers essentially the same features as the stand-alone version. In fact, you can configure an embedded broker to take its configuration from an XML file, in which case it will look very similar to the stand-alone broker.
Embedding a broker is a reasonable thing to do if you need the benefit of programmatic configuration; that is, you want to configure things according to rules which are hard to implement in an XML file. It also makes sense if you want close-coupled operation between the broker and the application components, with message data being passed in memory. This might be the situation if you're using JMS as an inter-module communication mechanism within the application.
Embedding a broker has the disadvantage -- and it can be a profound one -- of making it difficult to disentangle problems in the broker from problems in your application. Figuring out the cause of, say, runaway memory consumption could be very difficult. You can get commercial support for ActiveMQ, should you need it, but it will be hard for any commercial organization to support a hybrid broker+application installation.
I wanted to use queueing in my Mule applications deployed on cloudhub.
what are the options available?
As per my learning I think if we add VM component then we will be able to see the queue in cloudhub persistence queue option.
I have seen Anypoint MQ connectors as well..
are these two options are same?
If not, then which one is better?
Any other options??
VM queues are very basic point-to-point queues. You won't be able to browse the queue, access it through apis, use publish-subcribe, app to app, org to org and others.
For any non basic point-to-point use case, consider Anypoint MQ. Otherwise, any other cloud messaging solution could be used too if it has the appropriate connector.
use anypoint MQ, its easier to config with client. i suggest anypoint MQ becuz of pub/sub msgs
I am getting my data through ActiveMQ which I want to process in real time with Apache Flink DataStreams. There is support for many messaging services like RabbitMQ and Kafka but I can't see any support for ActiveMQ. How can I use it?
Since there is not support for ActiveMQ, I would recommend implement a custom source.
You basically have to implement the SourceFunction interface.
If you want to have exactly-once semantics, you can base your implementation on the MultipleIdsMessageAcknowledgingSourceBase class.
I would recommend you to start with implementing a SourceFunction
Found a JMS connector for Flink:
https://github.com/jkirsch/senser/blob/master/src/main/java/edu/tuberlin/senser/images/flink/io/FlinkJMSStreamSource.java
I have a cluster of Mule ESB containers, each of which is running an (identical) application which share responsibility for handling work which arrives as objects in a Hazelcast Distributed Queue.
Question: What's the best way to have these applications monitor the queue?
Conceptually, I imagine a "Hazelcast Queue Endpoint" that sits blocked on the queue until an object shows up-- but I'm not quite sure how to realize this.
(Mule ESB 3.3, community edition).
Thanks.
I would use DevKit to create a custom a Hazelcast Queue Endpoint and build it as a custom module.
This custom module would be usable in Studio and raw Mule.
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/