What are the major differences between the ECS Free & Frictionless Community Edition and the official ECS Appliance Software listed on EMC's support site?
Will the Free version track all the official version's releases?
To be more specific, is the "emcvipr/object" docker container the same for both the free version and the EMC Official release?
If so, will they be kept in sync?
The software releases are one and the same, however the license for the Community Edition is for non-production use only.
-Andrew
I recently came across the information in an EMC dev training session by the ECS community edition maintainers. They have code releases sort of in sync with paid versions, and you can check for release info of the docker containers from docker hub here. Most major/minor releases and some patched versions will be available.
Related
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 am using datastax enterprize 5.1 version in Analytics mode. Is it free to use in production environment?
No, it is only free in development
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 ! :)
I'm starting to use redis for my applications as a cache backend and "shared memory" store.
I've asked the servers maintenance team to install Redis on our CentOS 6.5 production environments. From EPEL, the version is 2.4.10, which we hope will upgrade in the future. Also, on our internal registry, we have a 3.0.7 available. The maintenance team would prefer the EPEL version.
I'm not quite sure of the differences between the versions. I haven't found a document listing major changes from 2.x to 3.0. Are there major features/ performance improvements/bugfixes in 3.0 that I MUST have?
My first guess is that 2.4.10 would be sufficient enough for my needs.
The most significant change from 2.x to 3.0 is that Redis 3.0 introduces Redis Cluster which is a distributed implementation of Redis.
You can also get change list (bug fix, new features and so on) of other versions from 00-RELEASENOTES file of each version: github link:
I am looking at Nexus 3.00 OSS Edition.
The recent release of Nexus 3.0 (OSS Edition) seems to have dropped support for rpms.
I don't see any specific note declaring that they are going to be dropping some features from 2.x.
So i am not sure whether the rpm/ yum repositry support is actually removed Or is it being supported differently with the new Nexus 3.0 or this feature has been made exclusive for the Paid version.
Not yet. The progress of this can be tracked in http://issues.sonatype.org/browse/NEXUS-10191. Feel free to watch for release details.