I'm currently using infinispan 8.2.11.Final which depends on jgroups-3.6.7.Final. Is this version of infinispan compatible with the latest release of jgroups 3.6.x (3.6.19.Final)?
I would like to bring fixes for MERGE3 and CENTRAL_LOCK protocols into my project.
I think there is a non-binary-compatible change in JGroups 3.6.9.Final, changing the return type of Request.setListener(), which means you need to recompile Infinispan.
But that's just what I noticed after a quick look, running the test suite may reveal other compatibility problems.
Related
I recently set up Directus on my server using the Docker Compose method described in the Docker Guide.
I have also installed a security plugin to check for potential issues with my images. Currently, the Postgis [13-master] and redis:6 versions have been reported as having some security concerns. Would you recommend staying on this version or upgrading to a different one? If upgrading is necessary, what steps can I take to ensure compatibility with the new database version?
We are using apache ignite v2.14.0 in our project. We regularly check for security vulnerabilities coming from our code base or third-party libraries. We are using aquasec for that purpose. In the security scan for ignite, it has shown 2 high severity vulnerabilities associated with jackson-databind which is heavily used. The version of jackson-databind being used in ignite is 2.12.7.
The CVE numbers for the vulnerabilities are :
CVE-2022-42003
CVE-2022-42004
We need to tell our security team how much impact can these vulnerabilities have on our system and any precautions we can take to avoid these.
The jackson jars are used by internal libraries also, so we can not remove them fully even if we override the jackson version in parent pom and that too can only work for our codebase, ignite will still use 2.12.7.
Jackson Databind has been upgraded to 2.14 in IGNITE-18108
The fix should be in Apache Ignite 2.15 release, it's better to ask the DEV community for concrete dates, but most likely it will be delivered in Q1 2023.
I suppose you can do one of the following:
If you are ok with building Ignite from the sources, you might cherry-pick this change and build Ignite from the sources on your own.
You can check if GridGain Community Edition fits your needs. It has a much more frequent release cycle and these CVEs are already fixed in GG 8.8.23
Wait for Ignite 2.15.
We are facing memory leak issue with ConfigurationProviders ConfigurationRoot.
Looks like this issue may have been fixed
https://github.com/aspnet/Extensions/issues/861
However, Microsoft.Extensions.Configuration 3.0.0 requires NETCORE 3.0. Can someone please confirm how this fix can be applied with .NETCore 2.2.7? We do not want to upgrade to NETCORE 3 yet, as we have time constraints for project delivery.
This is specifically related to the reload change token, so I would assume disabling reload on the JSON files would negate the issue. That means you'd have to restart your app if you made any changes to the JSON files, but that really shouldn't be much of an issue, as you should really only be making configuration changes as part of a new build and deployment anyways (via your CI/CD pipeline).
Otherwise, no, you'd have to upgrade to Core 3.0, unless this fix gets back-ported into the 2.1 LTS release. That's actually a possibility, so it might be worth calling it out on the issue, since a memory leak is a pretty serious issue to leave unchecked in an LTS release. It might have just flown under the team's radar.
The other possibility is that is is back-ported into 2.1, but since you're on 2.2, it's not there. I'm not sure if they'd necessarily back port it into 2.2, since that's not an LTS. As such, your choice may boil down to down-grading to 2.1 or upgrading to 3.0. That's the breaks of the game when you're not not on the LTS release - upgrading may be required.
This issue has been sorted, see details here
https://github.com/aspnet/Extensions/issues/2576
I had Erlang/OTP 17 and RabbitMQ Server 3.4.3 installed on my local windows box. Before upgrading to the newer versions in production, I wanted to give it a try on my local box to see if upgrade won't cause any problem. I am trying to upgrade them to the latest versions - Erlang/OTP 21 and RabbitMQ Server 3.7.8. When I do upgrade, I lost all my existing messages.
I had some existing messages in multiple queues. As soon as I upgraded Erlang/OTP (21), I see all my existing messages are gone. I even tried installing the newer RabbitMQ Server (3.7.8), still I don't see my old messages in the queues. I thought mnesia database would help in restoring the messages. I guess either I don't understand the concept or I am missing some settings.
I don't want our production clients complain about the messages being lost. I couldn't find much help online on this topic. But, surely RabbitMQ documentation talks about Blue-Green Deployment Strategy, never did that, so was not sure if that would help in our case, or it is an overkill and has a simpler solution. Also, want to add that I did all manual upgrade. If anyone know a better process of upgrade for single node without losing the existing messages, please guide and help me.
The documentation clearly states that you can't upgrade directly from version 3.4.3 to version 3.7.8: link. You must first upgrade to 3.6.16.
In your case, using a blue-green upgrade would be the only way to avoid having to first upgrade to version 3.6.16 prior to 3.7.8.
I want to know what is the difference between installing HortonWorks HDP vs installing the components directly from Apache projects? One thing I can think of is that Horton works probably has the packages aligned so that the version of each component is compatible with that of the others within the suite, while getting them directly from Apache projects, I may have to handle version compatibility myself. Is that correct? Is there any other difference involved ignoring the support subscription aspect of it.
Thanks.
There are a lot of differences between "roll your own" and using a distribution. Some of the most obvious include:
All of the various components and versions have been tested and built to work together - incompatibility between versions (e.g. Hive, Hadoop, Spark, etc.) can be a painful problem to sort through on your own
Most distribution providers, including Hortonworks, will bring patches in from unstable releases into stable releases, so even for the "same" version (e.g. Hive 1.2.1) you're getting a better release than vanilla - these can include both bug fixes and "safe" feature changes
Most distribution providers, including Hortonworks, provide some flavor of centralized platform management. I'm a big fan of Ambari (the one that comes with HDP), for example - it makes configuration and monitoring significantly easier than coordinating a vanilla install
I would strongly recommend against trying to deploy vanilla, unless it's just for learning and playing. HDP community edition is free (both definitions) and a major improvement over doing it yourself. My last deployment of HDP was entirely based on the community edition.