Bug 765795

Summary: java.lang.StackOverflowError Exception when using createPackageBackedResource method
Product: [Other] RHQ Project Reporter: bkramer <bkramer>
Component: CLIAssignee: Stefan Negrea <snegrea>
Status: CLOSED CURRENTRELEASE QA Contact: Mike Foley <mfoley>
Severity: high Docs Contact:
Priority: urgent    
Version: 4.2CC: hrupp, loleary, snegrea
Target Milestone: ---   
Target Release: JON 3.0.1   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: jon-3.0.1 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 785887 (view as bug list) Environment:
Last Closed: 2013-09-03 15:17:11 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 760116, 781607, 785887, 785899, 806590, 808636, 910832    
Attachments:
Description Flags
Script that can be used to reproduce the problem
none
Test script to deploy the specified WAR to the RHQ Server JBoss AS resource
none
A test WAR that can be used to reproduce the issue
none
Sample script for JBoss EAP5 none

Description bkramer 2011-12-09 13:03:17 UTC
Description of problem:

When using createPackageBackedResource method the java.lang.StackOverflowError Exception is thrown. 


org/rhq/enterprise/server/resource/ResourceFactoryManagerBean.java

516     @Override
517     public CreateResourceHistory createPackageBackedResource(Subject subject, int parentResourceId,
518         int newResourceTypeId, String newResourceName,//
519         @XmlJavaTypeAdapter(value = ConfigurationAdapter.class)//
520         Configuration pluginConfiguration, String packageName, String packageVersionNumber, Integer architectureId,//
521         @XmlJavaTypeAdapter(value = ConfigurationAdapter.class)//
522         Configuration deploymentTimeConfiguration, byte[] packageBits, Integer timeout) {
523 
524         return createPackageBackedResource(subject, parentResourceId, newResourceTypeId, newResourceName,//
525             pluginConfiguration, packageName, packageVersionNumber, architectureId,//
526             deploymentTimeConfiguration, packageBits, (Integer) null);

So it will recursively call itself.

I guess the intention was that it should do:

return createResource(subject, parentResourceId, newResourceTypeId, newResourceName,//
            pluginConfiguration, packageName, packageVersionNumber, architectureId,//
            deploymentTimeConfiguration, packageBits, (Integer) null);




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

How reproducible:
every time

Steps to Reproduce:
1. run a script that invokes createPackageBackedResource method (see attached deploy-script.js and run the following: 
./rhq-cli.sh -s localhost -u rhqadmin -p rhqadmin -f <path to the js script> <path to the application to be deployed> <group name> )
  
Actual results:

The following exception is thrown:

Remote server version is: 3.0.0.GA (e23441b:1ca6ad9)
Login successful
File rhq-cli.bat
About to deploy rhq.bat of type bat with version cli to group myJBossGroup
  Found group: myJBossGroup
  Group ID   : 10001
  Description: null
  Found resource EAP bkramer.fab.redhat.com:1099 default of type JBossAS Server and ID 10993
  Application not found. New deployment....
  AppTypeName: Web Application (WAR)
  AppType: ResourceType[id=10067, name=Web Application (WAR), plugin=JBossAS5, category=Service]
  deploying new application....
Exception in thread "main" org.rhq.enterprise.client.script.CLIScriptException: javax.script.ScriptException: sun.org.mozilla.javascript.internal.WrappedException: Wrapped javax.ejb.EJBException: [Warning] java.lang.RuntimeException: java.lang.StackOverflowError (<Unknown source>#163) in <Unknown source> at line number 163
	at org.rhq.enterprise.client.commands.ScriptCommand.executeScriptFile(ScriptCommand.java:270)
	at org.rhq.enterprise.client.commands.ScriptCommand.execute(ScriptCommand.java:101)
	at org.rhq.enterprise.client.ClientMain.processArguments(ClientMain.java:519)
	at org.rhq.enterprise.client.ClientMain.main(ClientMain.java:106)
Caused by: javax.script.ScriptException: sun.org.mozilla.javascript.internal.WrappedException: Wrapped javax.ejb.EJBException: [Warning] java.lang.RuntimeException: java.lang.StackOverflowError (<Unknown source>#163) in <Unknown source> at line number 163
	at com.sun.script.javascript.RhinoScriptEngine.eval(RhinoScriptEngine.java:110)
	at javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:232)
	at org.rhq.enterprise.client.commands.ScriptCommand.executeScriptFile(ScriptCommand.java:259)
	... 3 more


and the following is logged in rhq-server-log4j.log file:

Caused by: java.lang.StackOverflowError
	at org.rhq.enterprise.server.resource.ResourceFactoryManagerBean.createPackageBackedResource(ResourceFactoryManagerBean.java:524)
	at org.rhq.enterprise.server.resource.ResourceFactoryManagerBean.createPackageBackedResource(ResourceFactoryManagerBean.java:524)
	at org.rhq.enterprise.server.resource.ResourceFactoryManagerBean.createPackageBackedResource(ResourceFactoryManagerBean.java:524)
	at org.rhq.enterprise.server.resource.ResourceFactoryManagerBean.createPackageBackedResource(ResourceFactoryManagerBean.java:524)
...



Expected results:

The script should be executed without any exceptions.

Additional info:

Comment 1 bkramer 2011-12-09 13:04:29 UTC
Created attachment 544537 [details]
Script that can be used to reproduce the problem

Comment 3 Larry O'Leary 2012-01-06 00:03:57 UTC
The original scripts and instructions provided did not allow for this issue to
be reproduced without quite a bit of work. I have reproduced the issue and
simplified the test:

#. Install JON 3.0.0 Server, Agent, and Remote Client API (CLI)
#. Import RHQ Agent and RHQ Server into inventory
#. Copy deploy-script.js and GuessANumber.war to /tmp
#. From Remote Client API, execute test script:
   cd <RHQ_CLI_HOME>/bin
   ./rhq-cli.sh -s localhost -u rhqadmin -p rhqadmin -f /tmp/deploy-script.js
/tmp/GuessANumber.war

Actual Result:
Test WAR did not get deployed to RHQ Server and the following exception
appeared on the console:
Caused by: java.lang.RuntimeException: [Warning] java.lang.StackOverflowError
 at
org.rhq.core.util.exception.WrappedRemotingException.getCause(WrappedRemotingException.java:121)
 at java.lang.Throwable.printStackTraceAsCause(Throwable.java:512)
 at java.lang.Throwable.printStackTraceAsCause(Throwable.java:514)
 at java.lang.Throwable.printStackTraceAsCause(Throwable.java:514)
 at java.lang.Throwable.printStackTrace(Throwable.java:485)
 at java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:1001)
 at java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:992)
 at java.lang.Thread.dispatchUncaughtException(Thread.java:1845)

... 
Server log contains: 
Caused by: java.lang.StackOverflowError
 at
org.rhq.enterprise.server.resource.ResourceFactoryManagerBean.createPackageBackedResource(ResourceFactoryManagerBean.java:524)
 at
org.rhq.enterprise.server.resource.ResourceFactoryManagerBean.createPackageBackedResource(ResourceFactoryManagerBean.java:524)
... repeats many many times


Expected Result:
WAR should be deployed with no error

Comment 4 Larry O'Leary 2012-01-06 00:04:58 UTC
Created attachment 551047 [details]
Test script to deploy the specified WAR to the RHQ Server JBoss AS resource

Comment 5 Larry O'Leary 2012-01-06 00:06:07 UTC
Created attachment 551048 [details]
A test WAR that can be used to reproduce the issue

This is a simple test WAR but any WAR will do.

Comment 6 Stefan Negrea 2012-01-06 22:34:40 UTC
The error was due to a recursive self-call in the method noted above;  updated the code to call the correct method to a new create resource.

Note: there are two variants of createPackageBackedResource; one with a timeout parameter and one without the timeout parameter. Only the variant with the timeout parameter was affected by this BZ. Even without this fix, users could still attempt to create new resources by using the method variant without the timeout. 

The script example posted in comment 4 sets the timeout to null. So the method that works would be invoked just by removing the last parameter. During my tests, I set the timeout to null and resources were created correctly. 


master commit: 
http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=commit;h=3f2e1dd08dfcfb38ef22aba22d6609c1a44b20da

Comment 7 Stefan Negrea 2012-01-06 22:42:19 UTC
Created attachment 551298 [details]
Sample script for JBoss EAP5

Comment 8 Stefan Negrea 2012-01-06 22:44:39 UTC
The script posted in comment 4 works only for JBoss AS4. The script will not work for JBoss EAP5. There are differences in querying for the server, resources, and the actual deployment configuration.

I am attaching a new script for JBoss EAP5. Note that the most important difference is in the deployment configuration, it requires a different set of properties. See attachment 551298 [details].

Comment 10 Stefan Negrea 2012-01-07 00:37:55 UTC
I take back the note from comment 6. The remote interfaces has been cleaned and only one variant of creatPackageBackedResource is now exposed for the CLI (the one with the timeout parameter). To be able to create resources from the CLI, the fix associated with this BZ is required.

Comment 11 Larry O'Leary 2012-01-20 17:09:40 UTC
Committed to release/jon3.0.x branch as: http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=commit;h=1e50f290f975541077728074c0cccdb0b131928c

Comment 12 Charles Crouch 2012-01-24 18:33:29 UTC
The fix for this bug has been back ported to the jon3.0.1 branch however this is likely to cause a merge conflict when Stefan's other content related changes come in for addressing the issues blocking: https://bugzilla.redhat.com/show_bug.cgi?id=758753

So for right now I'm going to put this back to ON_DEV so that we can make sure this fix gets handled probably on merge, and then QE'd

Comment 13 Stefan Negrea 2012-01-24 23:25:57 UTC
This fix was only added to master branch since it was initially scheduled for an earlier patch. The branch with updates for the content system does not have this fix. There will be no merge conflicts.

Comment 14 Charles Crouch 2012-01-30 17:59:39 UTC
(11:32:10 AM) ccrouch: stefan_n_: so 
https://bugzilla.redhat.com/show_bug.cgi?id=765795, the fix went into the 
jon3.0.1 branch as well as  master
(11:32:34 AM) ccrouch: is your point that your branch commits just won't 
conflict with the fix for this issue?
(11:33:24 AM) stefan_n_: ccrouch, that is correct

Comment 15 Mike Foley 2012-02-13 19:28:33 UTC
verified JON 3.01 RC4

Comment 16 Heiko W. Rupp 2013-09-03 15:17:11 UTC
Bulk closing of old issues in VERIFIED state.