Bug 857692 - JBoss startup failure: -XX:+UseCompressedOops java option unsupported with OpenJDK 1.7.0_05-icedtea [CodeChange]
Summary: JBoss startup failure: -XX:+UseCompressedOops java option unsupported with Op...
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-setup
Version: 3.1.0
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
: ---
Assignee: Moran Goldboim
QA Contact: Yaniv Kaul
URL:
Whiteboard: infra
Depends On: 852037
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-09-16 10:15 UTC by Juan Hernández
Modified: 2016-02-10 19:31 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 852037
Environment:
Last Closed: 2012-09-24 13:18:06 UTC
oVirt Team: Infra
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Juan Hernández 2012-09-16 10:15:31 UTC
+++ This bug was initially created as a clone of Bug #852037 +++

Description of problem:

When running "engine-setup" the JBoss service fails to start with:

Error: There's a problem with JBoss service.Check that it's up and rerun setup.

and writes the following error to /var/log/ovirt-engine/console.log:

Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

Version-Release number of selected component (if applicable):

[root@server ~]# cat /etc/redhat-release 
Fedora release 17 (Beefy Miracle)

[root@server ~]# java -version
java version "1.7.0_05-icedtea"
OpenJDK Runtime Environment (fedora-2.2.1.fc17.9-i386)
OpenJDK Server VM (build 23.0-b21, mixed mode)

[root@server ~]# rpm -qa | grep openjdk
java-1.7.0-openjdk-devel-1.7.0.5-2.2.1.fc17.9.x86_64
java-1.7.0-openjdk-1.7.0.5-2.2.1.fc17.9.x86_64
java-1.7.0-openjdk-1.7.0.5-2.2.1.fc17.9.i686

[root@server ~]# rpm -qa | grep ovirt
ovirt-engine-userportal-3.1.0-2.fc17.noarch
ovirt-engine-setup-plugin-allinone-3.1.0-2.fc17.noarch
ovirt-iso-uploader-3.1.0-0.git1841d9.fc17.noarch
ovirt-engine-dbscripts-3.1.0-2.fc17.noarch
ovirt-engine-notification-service-3.1.0-2.fc17.noarch
ovirt-engine-backend-3.1.0-2.fc17.noarch
ovirt-engine-setup-3.1.0-2.fc17.noarch
ovirt-engine-tools-common-3.1.0-2.fc17.noarch
ovirt-engine-sdk-3.1.0.4-1.fc17.noarch
ovirt-engine-restapi-3.1.0-2.fc17.noarch
ovirt-engine-config-3.1.0-2.fc17.noarch
ovirt-engine-webadmin-portal-3.1.0-2.fc17.noarch
ovirt-image-uploader-3.1.0-0.git9c42c8.fc17.noarch
ovirt-engine-3.1.0-2.fc17.noarch
ovirt-release-fedora-4-2.noarch
ovirt-log-collector-3.1.0-0.git10d719.fc17.noarch
ovirt-engine-genericapi-3.1.0-2.fc17.noarch

How reproducible:

Every time.

Steps to Reproduce:
1. Install Fedora 17 with java-1.7.0-openjdk-1.7.0.5-2.2.1.fc17.9.x86_64 and ovirt 3.1
2. Run "engine-setup" and see JBoss service failure
  
Actual results:

JBoss service fails to start and console.log shows a JVM startup error

Expected results:

ovirt-engine service starts and boot.log, server.log and engine.log files are present.

Additional info:

Applying the following patch to /usr/share/ovirt-engine/scripts/engine_service.py to remove the offending Java command-line option resolves the issue:

diff --git a/engine-service.py b/engine-service.py
index aa80e32..85195b3 100755
--- a/engine-service.py
+++ b/engine-service.py
@@ -197,7 +197,6 @@ def startEngine():
     engineArgs.extend([
         # Virtual machine options:
         "-server",
-        "-XX:+UseCompressedOops",
         "-XX:+TieredCompilation",
         "-Xms%s" % engineHeapMin,
         "-Xms%s" % engineHeapMax,

--- Additional comment from juan.hernandez on 2012-08-27 11:55:28 EDT ---

I am a bit confused, you say that the x86_64 machine doesn't support the flag but you are given the output of "java -v" of the i386 version, which is probably what you have configured by default with "alternatives".

I have exactly that version installed and the option works fine:

  # rpm -qa | grep openjdk
  java-1.7.0-openjdk-1.7.0.5-2.2.1.fc17.9.x86_64
  java-1.7.0-openjdk-devel-1.7.0.5-2.2.1.fc17.9.x86_64

  # java -version
  java version "1.7.0_05-icedtea"
  OpenJDK Runtime Environment (fedora-2.2.1.fc17.9-x86_64)
  OpenJDK 64-Bit Server VM (build 23.0-b21, mixed mode)

Are you sure you are using the 64 bits of the virtual machine to run the engine and not the 32 bits version that you have installed? It is very easy to check, just change with the "alternatives" command with version is in use, and maybe change it:

  # alternatives --display java
  java - status is auto.
    link currently points to /usr/lib/jvm/jre-1.7.0-openjdk.x86_64/bin/java
  ...

If you see that you are using the 32 bits please change to the 64 bits version:

  # alternatives --config java

If you see the the problem with the 32 bits version we might need to remove that option when running in 32 bits environments (it is mainly a performance improvement).

--- Additional comment from keith on 2012-08-28 16:06:26 EDT ---

Yes, you're right, the -XX:+UseCompressedOops option works fine with 64-bit java:

[keith@server ~]$ /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.5.x86_64/jre/bin/java -XX:+UseCompressedOops test
Error: Could not find or load main class test

but fails with 32-bit java:

[keith@server ~]$ /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.5/jre/bin/java -XX:+UseCompressedOops test
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

Thanks for spotting the problem with my setup.

--- Additional comment from iheim on 2012-08-29 00:09:34 EDT ---

not sure if we should fix to work on 32bit, or just validate its 64bit jvm

--- Additional comment from juan.hernandez on 2012-08-29 03:48:18 EDT ---

As we have to check if it is 64 or 32 bits anyhow, I would just remove that option of it is 32bit.

--- Additional comment from juan.hernandez on 2012-09-12 06:07:08 EDT ---

The suggested fix for this issue is here:

http://gerrit.ovirt.org/7949

--- Additional comment from juan.hernandez on 2012-09-16 06:12:46 EDT ---

The fix has been merged:

http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=commit;h=bc8709e4c28384386aed39ee1f7d25ee70e063b7

Comment 1 Juan Hernández 2012-09-16 10:17:51 UTC
Although downstream is 64 bits only it would be convenient to have this change there as well, in order to simplify future patching and in case one want to support 32 bits in the future.

Comment 7 Barak 2012-09-24 13:17:14 UTC
We don't need this one downstream, as we don't build & test 32 bit

Comment 8 Barak 2012-09-24 13:18:06 UTC
Moving to CLOSE UPSTREAM - patch was accepted upstream


Note You need to log in before you can comment on or make changes to this bug.