Im use a Elasticsearch 5.1.2 (docker installation) and integrated with a project generated with jHipster 4.0.2.
After configure Elasticsearch, Elastic show the message:
java.lang.IllegalStateException: Received message from unsupported version: [2.0.0] minimal compatible version is: [5.1.2]
sn_elasticsearch |
Its posible to upgrade the client version of Spring Data Elastic integration in jHipster project? Someone knows how to?
[]s
spring-data-elasticsearch does not support version 5 yet. It is a work in progress by a team of volunteers (not driven by the Spring Data team).
According to the latest post on GitHub where you can track the issue:
Given that we will look into upgrading elasticsearch to latest version and as #olivergierke suggested it will be released with Kay if we will be able to merge changes before RC1 which is in mid March [2017].
This pull request still require major week or two of a work, its not straight forward merge. We are independent resource(s) willing to contribute on this project wherever we can, anyone who is willing to do the same is more than welcome to contribute.
We will keep posting update from our side about upgrade on the same thread.
Related
We have passed Apiman-2.0.0.final through security scans and came up with some critical/high vulnerabilities, mostly relevant to keycloak-core-10.0.2.
Fixes for this vulnerability are available in higher versions of keycloak.
I would like to know how do you handle these scenarios.
Should we repackage the war locally for us to use? We can create a pull request if it works.
Should we open a Jira item? I cannot see 2.0.0 being supported on red hat Jira. https://issues.redhat.com/projects/APIMAN/summary
Please post issues on our GitHub issue tracker, not stack overflow https://github.com/apiman/apiman/issues
We're using a newer version of Keycloak for the upcoming community release. You can indeed use your own separate Keycloak instance (recommended for a real deployment), rather than the one bundled in the quickstart.
I'm relying on Node version 12.17.x to make use of a specific feature (AsyncLocalStorage) in Lambda and Elasticbeanstalk. But for some reason, the Node.js version does not seem to publicly available. Why do they think that platform "12.x" tells me the real Node version? I want to know the exact minor and patch version, or at least give some news about it...
I had to create a test lambda function that prints process.version, but surprisingly, platform 12.x still uses v12.16. When will they upgrade to the latest stable version that came out more than 2 weeks ago? Are they publishing those releases somewhere? Google tells me nothing useful.
The same applies to Elasticbeanstalk instances. Node v12.17 does not exist in /opt/elasticbeanstalk/node-install/*
I've just checked in our sentry and the current version is newer-v12.18.4 so you can safely use AsyncLocalStorage now on v12 lambdas.
But AWS should really show this in the lambda administration panel. The fact that this is not shown anywhere and we have to use console logs or third party tools to get this info is a very poor DX.
I need to upgrade my solr search from 4.7 version to 5.3.1 .
I am working on a linux platform.
Can you please provide me the steps that i need to follow .
Thank you!
I do not think that there is a definitive step by step guide for the upgrade that you are looking for.
I have a 4.3.x SOLR running in a production environment and I am contemplating the leap to upgrade to 5.x. However its clear that a lot has changed and that my upgrade is not going to be straight forward.
Also other priorities in my project have kept me from doing the upgrade.
So rest of the discussion is more a thought process than actual upgrade experience.
Last I researched I found the below links useful
https://support.lucidworks.com/hc/en-us/articles/203776523-How-to-upgrade-between-major-Solr-Versions
https://cwiki.apache.org/confluence/display/solr/Major+Changes+from+Solr+4+to+Solr+5
From the Major changes link you will notice that a lot has changed ..
Most notably there are changes to the index format, SolrJ removal of deprecated API and that the deployment is now as a standalone server instead of a war file.
So I would suggest that you ask yourself the following questions ...
Is it possible to recreate the index from scratch ? How much time does it take to create your complete index ? If your index can be recreated quickly then , I would suggest that you do that using 5.x engine on a separate machine, while your production environment is served by your existing server. Then plan a complete upgrade from 4.x to 5.x by simply pointing your Production instance to the new SOLR engine. This approach will give you a clean slate to start with and a brand new index (but with existing data).
If you have a very large index (e.g. it takes several days to recreate it from scratch), then you may want to perform an upgrade of the live index. In that case I suggest that you consider the following.
The SOLR upgrade guide mentions 4.10 as a version that is 4.x (so I assume its is easy to upgrade from any 4.x to 4.10) and has some features built in to help with the move to 5.x. So first upgrade to 4.10 ensure that your index continues to work properly. Then use the guides mentioned above to upgrade to 5.x
I've been trying to work through an issue that developed while attempting to upgrade our testing environment from 12.04 to 14.04 ubuntu on aws. Prior to this, the Package repository version of solr was 1.4.1 which matched our 1.4.1 solrj client integrated with our application.
Changing the base AMI to the 14.04 latest and running our default deploy caused solr 3.6.2 server to be installed. It appears it was accepting our configs without issue, however when our client tried to connect we received different errors:
The first was an unknown custom field, which we traced back to our deployment scripts not moving our schema.xml and solrconfig.xml to /etc/solr/conf/ but keeping it in the base directory.
We corrected this issue, and then ran into the following:
'exception: Invalid version or the data in not in 'javabin' format'
This was generated by a wrapper ontop of solrj, but I'll be honest and say I know nothing regarding Solr and that this may be on our end. I've asked our dev team to look at 2 options:
1) enabling: 'server.setParser(new XMLResponseParser());'
Which is the recommendation on the backwards compatibility for an older client.
2) updating our client in the application to 3.6.2
-I know less about the requirements on this.
My fall back is to revert to 1.4.1, but it appears it hasn't been touched since 2011, which makes me hesitant.
Any thoughts / suggestions would be appreciated!
Thanks!
I think the best option is to maintain the same version of Solr and Solrj.
I used for a lot of time Solr 1.4.1 and, while as you said, the most part of it works with newer versions without any problem, actually a lot of things have been changed since 1.4.*
I did your same porting last year, (from 1.4.1 to 3.6.1) and I can confirm you that the 2nd way is the right one: all changes you must do in your client code are just "formal" and very very quick.
Any workaround you could do for being able to communicate with a different version (between Solrj and Solr) is just, as the word says, a "workaround" and it could lead to unexpected (hidden) side-effects later.
We have a liferay portal running on a hosting company, and We want to bring it to our own structure. So, I've downloaded the excellent bitnami stack and loaded it in our vmware server.
I've no experience on liferay whatsoever, all I know its that it uses mysql as database. Is there any docs on how to do it?
Tks!
Use the Liferay's Wiki:
5.0 to 5.1: http://www.liferay.com/community/wiki/-/wiki/Main/Upgrade+Instructions+from+5.0+to+5.1
5.1. to 5.2: http://www.liferay.com/community/wiki/-/wiki/Main/Upgrade+Instructions+from+5.1+to+5.2
I recommend to do a 2-step upgrade since direct upgrade from 5.0 to 5.2 is more troublesome.
There have been reports that it's some work to upgrade older versions to the latest and greatest, so you should be prepared for some efforts.
That said, the way you should go is to backup the previous installation (e.g. all directories, database entries etc) and deploy that on your own server. This installation then is updated to the latest version by installing the latest version and pointing it to the data from the previous installation. During the first startup, liferay will (given sufficient privileges on mysql) update the database structure and everything it needs. Keep your backup ready and test thoroughly if everything is upgraded the way you intended it to be.
Also you need to keep an eye on your customized stuff - if you have portlets or other components that use the liferay api, you might need to upgrade those manually to take changed APIs into account.
Theoretically that should be it. I've heard of people having had some problems with this - but it all depends on your level of customization and utilization of features in liferay.
The liferay folks intend to circumvent this in future with their EE environment, where you get better defined upgrade paths and long term support with minor upgrades to your environment, keeping APIs and database requirements stable. I'd hope that even upgrades between major versions will benefit from this, but have not yet tried it.