Which GridGain version is compatible with Apache Ignite 2.11.0 - ignite

We use Apache Ignite 2.11.0 and plan to migrate to GridGain.
Which version is compatible and how to migrate to GridGain Community?
We use .NET Core. Do we change the program code or migrate without change?

GridGain is based on Apache Ignite, but they are not 100% compatible, and there is no 1-to-1 version mapping.
Having said that:
In most cases the migration is smooth - just change the package reference.
Latest available GridGain version is recommended.

Related

Apache Karaf 4.2.3 update ActiveMQ version

I'm using Karaf 4.2.3 over JDK 1.8. I had ran a Black Duck Scan, and it is pointing to Apache ActiveMQ -5.15.9 with some vulnerabilities, one of them is critical. I'd like to know if it is possible to get this updated to the recommended version which is 5.17.1. Please if you have some advice it'd be highly appreciated. I'd like to point out that in the current project, I'm not really using ActiveMQ.
ActiveMQ 5.17.1 requires Java 11 so you won't be able to use that. You should upgrade to ActiveMQ 5.16.5 instead. It's the latest version which supports Java 8. That said, if you're not using ActiveMQ in your project then the simplest (and most secure) thing you can do is just remove it.

Zabbix Agent installation on OpenSuse 13.2 with yum fails

when installing Zabbix v3.4 I get the following error message: http://imgur.com/a/xo3tg
Looks like an error in the yum repository. Do you have any suggestions for solutions or something similar?
Best regards
As you can see, there is just 2.2 version of Zabbix (agent, server, proxy, etc.) in that repository.
It seems Zabbix 2.2 (LTS) is the latest version supported by OpenSUSE using its repositories.
By the way, you can install older versions of Zabbix-agent (like 2.2) sending data correctly to newer server/proxy versions (like 3.0 or even 3.2).
I think the major item you will miss with using zabbix-agent older than 3.X is encryption. Other major features work very good.

Redis v2.4.10 versus v3.0.7

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:

Which Phoenix version should I use with HBase in Cloudera 5.5 and Hortonworks 2.4?

Is there a single version of phoenix that is compatible with HBase provided in both Cloudera 5.5 and Hortonworks 2.4?
Hortonworks provides custom fixes and "backports" to their version of Phoenix in their HDP distribution. Cloudera may do the same as well.
I am assuming that you are asking about a client version that is compatible with both server versions.
Are you using the "thin" client jars? Do you find that your application does not work for one distribution or the other (dependent on which version jars you have)? Your application may work for both distributions if you use the non-thin jars.
If you would like to continue using the thin client, you may have to set phoenix.queryserver.serialization to JSON. HDP 2.3.4+ use PROTOBUF by default whereas CDH does not currently support PROTOBUF.
If you are asking about manually installing a version of the Phoenix server that can be installed on both distributions, both use HBase 1.1.x. Any Phoenix version 4.4+ can be used on either distribution. But I recommend using the version that is distributed with the platform.
A Phoenix 4.5.2 package for CDH 5.5.x is available via Cloudera Labs:
http://blog.cloudera.com/blog/2015/11/new-apache-phoenix-4-5-2-package-from-cloudera-labs/
Note however that Cloudera Labs packages are for dev/test only (not supported by Cloudera).

Spring data redis mock

I need to do integration testing for a spring cloud application running with spring data on redis.
Tests work locally with the regular redis server instance and I need to run this on a Jenkins CI server that is controlled by the corporate CI engineering group.
Obviously I can attach to a redo server there so I used an embedded redis server (from here: https://github.com/kstyrc/embedded-redis).
Running tests locally with this redis server works well since there is a test profile to inject the embedded server in place of the production one.
Now the problem is that when we run this in the Jenkins environment this is the error we see.
/tmp/1430170830037-0/redis-server-2.8.19: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by /tmp/1430170830037-0/redis-server-2.8.19)
So this version of redis has specific dependency on a specific version of glibc. I tried a couple of other libraries but they all depend on the same underlying version of the embedded redis server.
Is there a spring data mock framework that can be used to get around this sort of issue?
This might come a little late for you, but there is indeed a Spring Data Mock framework that you can use, which let's you mock repositories (regardless of the specific backend solution) without a real database connection.
Here is a link: https://github.com/mmnaseri/spring-data-mock
You don't have a high enough version of libc6, that is causing the error.
From How to fix “/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found”? – Super User:
That means the program was compiled against glibc version 2.14, and it requires that version to run, but your system has an older version installed. You'll need to either recompile the program against the version of glibc that's on your system, or install a newer version of glibc (the "libc6" package in Debian).
So, you just need to upgrade your libc6 package. All versions of Ubuntu have at least version 2.15 because it's a faily important package (reference).
To upgrade it, use these commands in a terminal:
sudo apt-get update
sudo apt-get install libc6
p.s. This is answer from askubuntu.com by minerz029