Bug 952337 - Agent raise OutOfMemoryError when adding new Deployment child resource on AS7
Summary: Agent raise OutOfMemoryError when adding new Deployment child resource on AS7
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: JBoss Operations Network
Classification: JBoss
Component: Plugin -- JBoss EAP 6
Version: JON 3.1.1
Hardware: All
OS: All
urgent
high
Target Milestone: ---
: JON 3.1.3
Assignee: Thomas Segismont
QA Contact: Mike Foley
URL:
Whiteboard:
Depends On: 887861
Blocks: 952341
TreeView+ depends on / blocked
 
Reported: 2013-04-15 17:31 UTC by Larry O'Leary
Modified: 2018-12-02 16:37 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 887861
: 952341 (view as bug list)
Environment:
Last Closed: 2013-09-06 02:25:32 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Larry O'Leary 2013-04-15 17:31:19 UTC
+++ This bug was initially created as a clone of JBoss ON 3.2 Bug #887861 +++

+++ This bug was initially created as a clone of Bug #887320 +++

Description of problem:
When you try to add new deployment child to an AS7 resource, the agent raise an  OutOfMemoryError.

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

How reproducible:
Always

Steps to Reproduce:
1. Find a simple WAR to deploy
I tried with Jenkins http://mirrors.jenkins-ci.org/war/latest/jenkins.war
2. Go to an AS7 resource page, Inventory/Child Resources tab.
3. Click the toggle button Create Child/Deployment and upload you WAR, then Next and Finish
4. Go to the Inventory/Child History tab
  
Actual results:
The new Created Child history record ends with status failed. A big stack trace ending with OutOfMemoryError is in the history details (see attached stack trace).

Expected results:
The new Created Child history record ends with status success.

Additional info:
* Attached is the server stack trace. The error is catched and passed to the server so it's reported on the server but actually raised in the agent.
* Deploying the same war to a Tomcat 7 resource works. So it may be a problem only for the AS7 plugin

--- Additional comment from Thomas SEGISMONT on 2012-12-14 17:50:28 CET ---

Created attachment 663660 [details]
Stack trace

--- Additional comment from Charles Crouch on 2012-12-14 18:29:08 CET ---

Notes:  http://mirrors.jenkins-ci.org/war/latest/jenkins.war is 46mb

Is this also a problem in jon311?

--- Additional comment from Thomas Segismont on 2012-12-17 09:16:18 EST ---

Fixed: jon3.1.x - f87210f

Cherry-picked from master - 52bdd6f

--- Additional comment from Charles Crouch on 2012-12-17 10:00:15 EST ---

Setting back to new. Thomas got a little carried away and committed this too the wrong branch. If this gets triaged into the release it will be cherry-picked to release/jon3.1.x

--- Additional comment from Thomas Segismont on 2013-02-14 08:47:57 EST ---

Fix tested on JON 3.2 Alpha. Master commit: 84b4cbc

--- Additional comment from Thomas Segismont on 2013-04-08 17:38:58 EDT ---

Reworked to upgrade to HttpClient 4

master - 21ec5e2

--- Additional comment from Thomas Segismont on 2013-04-09 06:08:00 EDT ---

Reworked to increased delay in AS7 itests to discover all resources
master - 3b18013

--- Additional comment from Thomas Segismont on 2013-04-10 08:20:18 EDT ---

Changes reported to release/jon3.1.x - 89d941d

All unit and integration tests pass on my box and on Jenkins:
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/RHQ/job/rhq-master/org.rhq$rhq-jboss-as-7-plugin/

Manual testing leads to expected results (see the steps listed in the original description of this bug)

Comment 1 Larry O'Leary 2013-04-15 17:32:19 UTC
As per upstream comment, this has been fixed with commit to release/jon3.1.x branch 89d941d. Setting to MODIFIED in case there is a 3.1.3 release.

Comment 2 Larry O'Leary 2013-09-06 02:25:32 UTC
Closing as there will not be a 3.1.3 release. This is being tracked for 3.2 in the 'depends on' field.


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