Target version : 7.7 Enterprise (also tried with 7.9.1 enterprise) Java 11
error observed
2019.07.17 07:53:33 INFO app[][o.s.a.es.EsSettings] Elasticsearch listening on /127.0.0.1:9001
2019.07.17 07:53:33 INFO app[][o.s.a.ProcessLauncherImpl] Launch process[[key='es', ipcIndex=1, logFilenamePrefix=es]] from [/opt/sonarqube/elasticsearch]: /opt/sonarqube/elasticsearch/bin/elasticsearch
2019.07.17 07:53:34 INFO app[][o.s.a.SchedulerImpl] Waiting for Elasticsearch to be up and running
OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release.
_Unrecognized VM option 'UseParNewGC'_
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
2019.07.17 07:53:34 WARN app[][o.s.a.p.AbstractManagedProcess] Process exited with exit value [es]: 1
2019.07.17 07:53:34 INFO app[][o.s.a.SchedulerImpl] Process[es] is stopped
2019.07.17 07:53:34 INFO app[][o.s.a.SchedulerImpl] SonarQube is stopped
steps to reproduce
Install Java 11 on sonar server
Upgrade the sonar instance with Java 11 and then ry the upgrade
Aah, thanks for the hint. I removed the arguments from java.search.opts and now the error is gone.
But a new error has cropped up:
While trying to bring up the server on OpenShift cluster (with the docker Images created ourselves), we get the below error:
max virtual memory areas ***vm.max_map_count [65530]*** is too low, increase to at least [262144]
Now I understand the this has to be fixed on the Docker hosts, but we would like to avoid that. Incidentally, we also have an elasticsearch infrastructure in our organisation.
So my concerns would be:
Do we need to stick to the internal implementation of ES? is it possible to leverage an external ES implementation?
If that is not possible, can we have another solution which does not involve changing system configurations on OpenShift cluster?
Elasticsearch won’t start without this check being passed, but unfortunately, we aren’t Docker experts here (yet) and currently don’t recommend using Docker to run SonarQube outside of demonstration purposes. Sorry I can’t be more help on this point Maybe somebody else has a better idea. Elasticsearch seems to have some docs.
All problems ironed out and instance is up an running now. All that is pending is migrating the DB from MySQL to MSSQL, and I face an issue here:
Current setup:
SQ: 7.7
DB : MySQL
Desired Setup:
SQ: 7.9 (or 7.9.1)
DB: MS-SQL
What I did:
I started the Desired Setup SQ instance and initiated the DB on MSSQL.
now while migrating the DB from Current Setup to Desired setup I face a problem Problem faced:
I get the below error
c:\>mysql-migrator.bat -source ..\DB-Migration-source.txt -target ..\DB-Migration-Target.txt
Versions in source and target database don't match: 2612 != 2804
Using the mysql-migrator, you need to first migrate your source database to a target database that uses the same schema (was created when started against the same SonarQube version as your source database), and after you migrate the database you can upgrade to v7.9
Start then stop your SonarQube version on your non-MySQL database (for example, if you’re currently using SonarQube 7.3, run then stop SonarQube 7.3 on your non-MySQL database).
Hey Amit , How did you overcome the virtual memry error. I’m struck at the same issue. I tried to disable it and run the sonar container but it is leading to the error when I perform the analysis.
Maybe somebody else has a better idea.