IN the following link:
http://www.mulesoft.org/documentation/display/current/Mule+ESB+3.4.0+Release+Notes
I see the following
EE-3141 When using a Throttling policy with throttling statics enabled, limit headers are swapped.
However, I can find no example of throttling policies within Mule ESB, but there is possibly a throttling policy within the Anypoint API Manager
Could someone please provide a link to how to use a Throttling policy within Mule ESB?
Thanks
To achieve correct Throttling behaviour you can follow below steps:
Configure a queue (for example, a persistent VM or a JMS queue to avoid message lost during the Mule server crash) after your inbound endpoint.
Configure scheduled delay, for example AMQ_SCHEDULED_DELAY in case of ActiveMQ, to a desired value. If the queue does not support scheduled delay, then we need to find our way to achieve the delay, probably using a Java component.
Finally, configure the outbound endpoint.
The Throttling module (which can be configured as throttler or rate limiter) comes out of the box with any Mule API Gateway distribution. Mule EE comes with a light weight version of it. If you are using Anypoint API Platform, then you don't need to pay attention to the internals of how it is being done: Simply apply/unapply the policy to your managed API and it will work like a charm.
Even i tried implementing the Throttling concept in mule flows. There is no exact way of implementation for this , but i was able get that nature into the flows using the receiver thread profiling at inbounds and dispatch threading profiles on outbound connectors.
Related
We have a requirement where we want mule to be invoked with fixed frequency we want to utilise control-m for that.
If the Control-M agent is running on your Mule ESB server, then you can use it to invoke a script which uses curl to invoke an http inbound endpoint flow, or to send a JMS message for a Mule flow with a JMS inbound endpoint, or place a file in a directory for a file inbound endpoint, etc... You get the idea, right? Any of the inbound endpoints are a possible candidate for the kickoff. Whether you are running Mule under Windows or Nix is another question as well, but it will work either way with some mods as to the scripting approach.
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 working with Mule ESB and instead of using Mule Management Console (MMC). I just want to load balance so that if I am exposing my Mule ESB as a Service so in that case I don't want to use load balancer to balance my Mule ESB , because once the request will come Load Balancer, it is the single point of failure in case if it is down. So I just need a use case how to Expose Mule as a Service with Optimized Load Balancing without using MMC (Mule Management Console).
For load balancing incoming HTTP request, over multiple Mule instances, you will need a external loadbalancer. Mule ESB Enterprise Edition nor MMC will help you with that.
You can use a commercial one, such as a F5 BIP-IP, or setup a HAProxy. To avoid the loadbalancer to be a single point of failure you can setup a redundant HAProxy.
For JMS make sure to setup a external message broker cluster and connect to it using the normal jms:inbound-endpoint that way Mule will act as a competing consumer and you will achieve load balancing of messages.
I would also advice you to have a look at "MuleSoft Blueprint: Load Balancing Mule for Scalability and Availability" that covers this. It is a bit dated but most of the information in there is still valid.
It's unclear what transport are you using, anyhow you have just limited number of options.
Use Mule EE clustering feature for the VM transport.
Use a load balancer
Use a transport that support competing consumers like JMS or AMQP.
Could you provide a more detailed explanation of you deployment so I can provide more extact info?
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 tried and tested the JMX API and it is pretty simple to use and provides a vast number of statistics required for monitoring ActiveMQ.
But the problem is, i dont want to monitor my ActiveMQ remotely and also i dont want to use another API.To be more precise, i want to use the JMS API itself to get statistics related to various destinations and the broker itself.
Advisory messages seem to be an alternative but they provide limited Amount of Administrative Messages to monitor.
Any input is highly appreciated...
There is no built-in support for this. But you can implement a JMS topic which publishes the monitoring data every few seconds. Make the connection non-persistent so that it doesn't pile up when there are no listeners or when they loose connection.
Now you can write a client that connects to this topic and it will receive updates.
AMQ-2379 resulted in a broker plugin for grabbing statistics from destinations by sending a simple JMS message. Check out the docs that show how to use it here:
http://activemq.apache.org/statisticsplugin.html
The statistics plugin is available in the 5.3 release.
You can checkout this http://issues.apache.org/activemq/browse/AMQ-2379, it will be avaiable in upcoming 5.3.0 release
There's a blog post queued up to go on http://issues.apache.org/activemq/browse/AMQ-2379 - will post it in a couple of days or so