I have a mule runtime 3.7.4 installed on my computer, I am wonder if it's possible to set up policies on this mule instance?
UPDATE
I just find this link: https://docs.mulesoft.com/runtime-manager/anypoint-platform-cli#api-mgr-policy-apply, has anyone tried this before? is it possible to set up policy to mule runtime using this CLI?
Policy management capabilities are part of any API Gateway distribution. Since the unification with Mule runtime, you can found those capabilities also in any Mule runtime with version 3.8.0 or greater.
So, replying to your original question, Mule runtimes with version under 3.8.0 have no policy management capabilities no matter the tool used.
Related
While deploying my Mule project with Mule runtime 4.3.0 to cloudhub through maven, i am getting below exception:
Execution default-deploy of goal org.mule.tools.maven:mule-maven-plugin:3.3.5:deploy failed: MessageBodyReader not found for media type=application/json;charset=utf-8, type=class org.mule.tools.client.arm.model.AuthorizationResponse, genericType=class org.mule.tools.client.arm.model.AuthorizationResponse.
Any help will be appreciated.
Thanks
Vikas
The fact that it works with Java 8 indicates it is some Java compatibility issue.
Mule Maven Plugin supports only until Java 11. See the release notes for your version to see software compatibility: https://docs.mulesoft.com/release-notes/mule-maven-plugin/mule-maven-plugin-release-notes
Is a version of MassTransit tested and certified against specific versions of Rabbit MQ prior to its release? If so, is this information published?
On the CI server, MassTransit is tested using the 3.6 version(s). Locally, I test it with 3.7.x, and recently 3.8.x. So it's a variety, depending upon what's installed.
Any relatively recent version of RabbitMQ (3.6.x or later) should work fine.
Update: According to AppVeyor, they use v3.6.15-1
I know Mule ESB Enterprise edition can be installed on Raspberry Pi because it ships with support for arm based processors. Unfortunately, Community edition does not have it. This makes it difficult to use Mule ESB on pi for longer time as I don't have the enterprise license (it's for personal projects and enterprise trial ends in 30 days). I wonder, why community edition does not have this support? Are there any restrictions for using community edition on pi?? Can the support be added to community edition? Has anyone done it and using it?
Yes, it is possible to install and run Mule on Raspberry PI 3 (and by extension any armhf/armel machine). You have to tweak your installation to ensure Mule uses the Linux armhf 32-bit Java Service Wrapper (or the related OS/architecture Wrapper). The steps in details:
Install Mule CE
Install Mule Standalone as you would do on any other machine:
Download the Mule CE Runtime
Unpack the content somewhere, such as in /opt/mule (i.e. MULE_HOME=/opt/mule) and change owner of the content to a Mule user (such as mule:mule)
Optionally, perform some hardening
You should be able to run Mule using $MULE_HOME/bin/mule start|stop|restart
Configure Java Service Wrapper
You need to manually add the Java Service Wrapper support for your OS and processor architecture, for Raspberry PI 3 it would be Linux armhf 32-bit.
Download the Linux armhf 32-bit Community Tanuki Java Service Wrapper and unpack it
Copy the Wrapper lib/libwrapper.so to $MULE_HOME/lib/boot/libwrapper-linux-armhf-32.so, ensure it has read+execute permission and is Mule user owned
Copy the Wrapper lib/wrapper.jar to $MULE_HOME/lib/boot/wrapper-{version}.jar (replace {version} by your Wrapper version), ensure it's Mule user owned and remove or backup somewhere else the previous wrapper-{oldVersion}.jar
Copy the Wrapper bin/wrapper to $MULE_HOME/lib/boot/exec/wrapper-linux-armhf-32, ensure it has read+execute permission and is Mule user owned
This one is a bit tricky, you have to update the $MULE_HOME/bin/mule launch script. Look for the line case "$PROC_ARCH" in, Such as:
'x86_64')
DIST_ARCH="x86"
DIST_BITS="64"
break;;
Each case match a specific hardware name to define DIST_ARCH and DIST_BITS variables, allowing to use the proper Wrapper files. Add a new case to handle your Raspberry PI hardware. For Raspberry 3, it's should be something like armv71 (check with uname -m if required):
'armv71')
DIST_ARCH="armhf"
DIST_BITS="32"
break;;
You may need to update $MULE_HOME/conf/wrapper.conf to avoid memory related issues. I usually have to play around with the following properties:
wrapper.java.initmemory=512
wrapper.java.maxmemory=512
wrapper.java.additional.X=-XX:PermSize=256m
wrapper.java.additional.Y=-XX:MaxPermSize=256m
wrapper.java.additional.Z=-XX:NewSize=512m
wrapper.java.additional.V=-XX:MaxNewSize=512m
When Mule will run on armv71 hardware, it will now use wrapper-{OS}-{DIST_ARCH}-{DIST_BITS}, in our case wrapper-linux-armhf-32. You should be able to run Mule as usual - check the logs for any error on start-up.
This method has been tested with Raspberry PI 2 and 3 for Mule CE 3.7 and 3.8 (it should work for previous versions). It may be a bit tricky, if you have any issue post a comment I'll update this post to add details.
By the way, this method can be used to add support for any architecture and OS as long as it is supported by Java Service Wrapper.
I wonder, why community edition does not have this support?
I don't know, Mule CE simply does not support ARM architecture - for now. Only a limited list of platform and architecture is supported by CE (i.e. the launch script filtering architecture types). Maybe they simply did not take the time (~money) to add support, or they purposefully prevent ARM support to favor Mule EE. Considering Mule CE is open-source, in theory someone could contribute to add such support... (just saying ! :)
Which version of MULE will be compatible for AWSSDK for Datapipeline, We need to activate Datapipeline through Enterprises version of Mule. Since its Cloud, we can use any mule version from 3.6. Please help us. Right now the Jar version are causing issues, such as NoSuchmethod error or Field not found.
You should be able to use the latest version of AWS SDK.
We are planning on using JDK 1.8 for Mule 3.7 CE.
In the past we edited wrapper.conf to tweak the memory JDK 1.6/1.7 uses. We did this by editing:
wrapper.java.initmemory=256m
wrapper.java.maxmemory=512
wrapper.java.additional.7=-XX:PermSize=256m
wrapper.java.additional.8=-XX:MaxPermSize=512m
Looking into the processes that are running in linux we see that Mule still uses xmx settings. If not mistaken, this no longer works in java 1.8 because it has been removed. Instead JDK 1.8 uses metaspace.
Now my question is, how/where to we make memory tweaks for Mule 3.7 using JDK 1.8? Or does Mule 3.7 CE not support this yet?
Do we simply add to wrapper.conf the following settings?:
wrapper.java.additional.16=-XX:MetaspaceSize=100M
wrapper.java.additional.17=-XX:MaxMetaspaceSize=2024m
And remove:
wrapper.java.initmemory=1024
wrapper.java.maxmemory=1024
Or we do still use the following settings?
wrapper.java.initmemory
wrapper.java.maxmemory?
Thanks!
You can keep using the initmemory and maxmemory.
Changing to Java 1.8 doesn't impact this.
We use Java 1.8 with Mule 3.7 in Linux and we are able to successfully control the heap allocation with the current setting of initmemory and maxmemory.
You might want to use Metaspace configuration only to replace PermGen settings.
wrapper.java.additional.16=-XX:MetaspaceSize=100M
wrapper.java.additional.17=-XX:MaxMetaspaceSize=2024m
Go through the following link for more understanding.
http://www.infoq.com/articles/Java-PERMGEN-Removed
Hope this helps.