I have a spring boot app that is running well on AWS Linux VM. Now, I am trying to run it on Azure Linux VM.
I am launching the application using this command (just like I am doing on AWS):
java -Dspring.profiles.active=prod -jar /home/azureuser/myapp/myapp-server.jar
But nothing happens after this. It doesn't exit but there is no output/log message at all. Ideally, I should see output generated on the shell but it prints nothing. There is no error/exception stack trace.
The same jar is working fine on AWS Linux VM.
The only difference in my AWS and Azure VMs is that on AWS, I have Java 16:
openjdk version "16.0.2" 2021-07-20
OpenJDK Runtime Environment Corretto-16.0.2.7.1 (build 16.0.2+7)
OpenJDK 64-Bit Server VM Corretto-16.0.2.7.1 (build 16.0.2+7, mixed mode, sharing)
while on Azure VM, I have Java 17:
openjdk version "17.0.4.1" 2022-08-12 LTS
OpenJDK Runtime Environment Microsoft-40354 (build 17.0.4.1+1-LTS)
OpenJDK 64-Bit Server VM Microsoft-40354 (build 17.0.4.1+1-LTS, mixed mode, sharing)
But I have tested the jar on my local windows machine on Java 17 and it works fine.
Any idea what might be the issue? Is the output going somewhere else that I don't know about?
It is working. I launched the application and then got busy with something else. When I checked back on the window after 10-15 minutes, I saw the output.
The issue was that Azure VM is a lot slower/underpowered than AWS VM. Since the app starts up in a few seconds on AWS, I never imagined that it would be that slow on Azure. It is taking more than one minute for the first line of output to show and more than 5 minutes for the app to finish start up.
Related
I am trying to run the sonar scanner on a docker virtual machine as part of my private Azure DevOps build server and am getting an error with the pagefile not having enough memory to complete the analysis. My docker image is running windows server core 2019 base image with JDK 11.0.13 installed and Sonarqube scanner 5.0.0. The server also has the following environment variables set to try and increase the Java VM size:
JAVA_OPTS="-Xms1024m -Xmx4608m"
SONAR_SCANNER_OPTS="-Xmx4608m"
My image is running with 5GB RAM and monitoring the container is showing that there is plenty of memory still available to use. I have noticed that the first time I run the scan after starting the container it runs fine but each attempt afterwards gets the error:
##[error]Java HotSpot(TM) 64-Bit Server VM warning: INFO: os::commit_memory(0x0000000789c00000, 703594496, 0) failed; error='The paging file is too small for this operation to complete' (DOS error/errno=1455)
Can someone please help me with why it is failing to allocate around 700MB when there is more than 2GB RAM available.
The versions of everything are:
Azure DevOps agents: 2.194.0
JDK: 11.0.13
Sonarqube scanner extension: 5.0.0
Docker: 20.10.7
Docker base image: dotnet/framework/sdk:4.8-gbt-windowsservercore-ltsc2019
The issue turned out to be related to the JavaXmlSensor detecting some very large xml test files in the test project, it was trying to load them into memory and analyse them causing the out of memory error.
To fix it I added **/*.xml to the sonar.exclusions and also added the same list of exclusions to the sonar.test.exclusions setting.
I just installed a fresh copy of weblogic server and OSB.
After the successful installation of weblogic 10.3.6 on the quick start screen I tried to configure domain. however the screen doesn't processed any further giving the error in the screenshot below.
Also, in eclipse, when i try to add the server, It prompts me to create a domain, but that doesn't work either.
The error am getting in the console is:
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option
MaxPermSize=128m; support was removed in 8.0
Unrecognized VM option 'UseSpinning'
It looks like Java 8 is being picked up elsewhere on your system.
Check to see if you have Java 8 installed and look at you path environment variable.
That warning you are getting is from Java 8. 10.3.6 would use Java 5 or 6...
Logged into Windows Server 2016 as Administrator, I can run Solr from the command line: bin\solr.cmd start -p 8983 -f
I have configured a Solr to run as a Windows Service - running as the same user, with the same command, same startup directory, etc. - however under load, the following error comes back from the upstream application (Sitecore xConnect, though this shouldn't make a difference)
{metadata={error-class=org.apache.solr.common.SolrException,root-error-class=org.apache.solr.common.SolrException},msg=SolrCore is loading,code=503}
To reiterate, everything works fine when Solr is started from the command line, only when it's run as a Windows Service does it error.
Solr version: 6.6.3
Windows version: Server 2016
Environment: AWS (m5.large EC2 instance)
Sitecore compatibility table says to use Solr 6.6.1 with Sitecore, You should still use 6.6.2 as it fixes a bug in Solr 6.6.1 that can affect the installation of SIF. Read here
I recommend you try again with Solr 6.6.2
It turns out that the service was configured to run without the -f flag. So the process would continually stop and re-spawn.
Texte d'origine Ecoutez le texte source
Hi
Please, can you give me your opinions about this subject :
1.I have instaled Jenkins on VM Linux Centos
2.I have installed Jenkins on VM Windows 7 which contains the project Java Maven.
3.I shared the project from VM Windows 7 to VM Linux Centos and I succed to the project from my VM Linux
My goal is to make Jenkins Master on VM linux and Jenkins slave on VM Windows.
What I should do for creating the communication between all jenkins.
Thanks in Advance.
Best Regards,
Two ways of making a Windows slave (after defining nodes on master), on Windows server:
-browse to Jenkins node listing and launch web agent (Java Web Start) which has to be done manually each time the server starts up
-after starting the agent, register the slave as a service
Plenty of documentation, I found this just now.
Definitely prefer a service you don't have to worry about the web agent dying for some unknown reason and no one noticing, much better to have it auto start.
I have a really basic play! app which simply handles a couple of normal GET and POST requests and talks to a MySQL database, nothing fancy.
I ran play dist and transferred the zip file to my EC2 instance. After unzipping it, going to the bin folder and running ./myapp, I get a message:
Java HotSpot(TM) 64-Bit Server VM warning: Info: os::commit_memory ... error='Cannot allocate memory' (errorno=12)
There is insufficient memory for the Java Runtime Environment to continue.
I'm running Play version 2.2.1 and this instance has about 512MB of ram, with the 64-bit version of the Oracle JDK. Is this not enough to run a play! app or am I missing something?
Thanks.
Play Framework 2.3 now has a nifty little feature.
$ /path/to/bin/<project-name> -mem 512 -J-server
Shoule get the job done.
Read http://www.playframework.com/documentation/2.3-SNAPSHOT/ProductionConfiguration
Specifying additional JVM arguments
You can specify any JVM arguments to the start script. Otherwise the default JVM settings will be used:
$ /path/to/bin/ -J-Xms128M -J-Xmx512m -J-server
As a convenience you can also set memory min, max, permgen and the reserved code cache size in one go; a formula is used to
determine these values given the supplied parameter (which represents maximum memory):
$ /path/to/bin/ -mem 512 -J-server
Using play 2.2.1 I had to run play dist to generate the zip file. Then I copied that to the aws instance.
Once there, I extracted the zip and changed the executable file:
from:
local mem=${1:-1024}
to:
local mem=${1:-512}
That did it for me. I got the idea from here but I didn't want to just delete the logic they had there, so I just reduced the default value.
Also please note that on aws ec2 micro:
$ java -version
java version "1.6.0_24"
OpenJDK Runtime Environment (IcedTea6 1.11.14) (amazon-65.1.11.14.57.amzn1-x86_64)
OpenJDK 64-Bit Server VM (build 20.0-b12, mixed mode)
So you have to use the same Java JDK when runnin play dist.
EDIT:
I updated java to openjdk 7 and was able to run the sample play applications without any errors.