Bug 885848 - Changing WAR/EAR deployment from exploded to unexploded (or vice versa) results in resource always being DOWN/Unavailable
Summary: Changing WAR/EAR deployment from exploded to unexploded (or vice versa) resul...
Status: CLOSED CURRENTRELEASE
Alias: None
Product: JBoss Operations Network
Classification: JBoss
Component: Plugin -- JBoss EAP 5
Version: JON 3.1.1
Hardware: All
OS: All
high
medium
Target Milestone: ER04
: JON 3.3.0
Assignee: Thomas Segismont
QA Contact: Sunil Kondkar
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-12-10 19:31 UTC by Larry O'Leary
Modified: 2018-11-30 20:44 UTC (History)
5 users (show)

(edit)
An issue with the *Deployment Name* being read-only after initial discovery meant that changing a WAR or EAR deployment from exploded to unexploded (or vice versa) after it was initially deployed resulted in the resource always being DOWN or Unavailable. It was not possible to monitor or manage the resource. The fix removes connection setting's "deploymentName" attribute and adds the "deploymentKey attribute. The attribute is only loaded when the component is started, or when it goes down because of NoSuchDeployment. Improvements to the Refresh button on the Monitoring/Calltime page are also implemented as part of this fix.
Clone Of:
(edit)
Last Closed: 2014-12-11 14:00:27 UTC


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 277203 None None None Never

Description Larry O'Leary 2012-12-10 19:31:09 UTC
Description of problem:
WAR is always DOWN and can not be monitored or managed if its deployment type (exploded or unexploded) changes after its initial discovery.

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

How reproducible:
Always

Steps to Reproduce:
1.  Create unexploded admin-console.war using files in deploy/admin-console.war/

        cd <JBOSS_SERVER_HOME>/deploy/admin-console.war/
        zip -r ../admin-console.war.zip .
        cd ..
        rm -rf admin-console.war
        mv admin-console.war.zip admin-console.war
    
2.  Start EAP server
3.  Start ON system
4.  Import EAP server into inventory
5.  Verify that admin-console.war has a *Deployment Name* starting with `vfszip:`
6.  Shutdown EAP
7.  Redeploy admin-console.war in an exploded form

        cd <JBOSS_SERVER_HOME>/deploy/
        unzip admin-console.war -d admin-console.war.dir
        rm -f admin-console.war
        mv admin-console.war.dir admin-console.war

8.  Start EAP
9.  Force service/detail discovery from agent
  
Actual results:
admin-console.war shows a state of DOWN

Expected results:
admin-console.war shows as state of UP

Additional info:
This is due to the *Deployment Name* being read-only/static after initial discovery. When the WAR is redeployed in an exploded form, the deployment ID changes in EAP to reflect vfsfile: instead of vfszip:. This change results in the already inventoried resource failing to locate the managed component in the management view due to the subtle ID change.

Because it is not uncommon for a deployment to change from exploded to unexploded or vice versa, and this is supported and expected within JBoss AS/EAP, this should be addressed either by service discovery itself or via a method to update the *Deployment Name* property in those rare cases that this would be necessary.

Comment 5 Thomas Segismont 2014-09-18 09:25:44 UTC
Fixed in master

commit 54ce392a7e2e8cc58718102f3e3af60d0ef64ab1
Author: Thomas Segismont <tsegismo@redhat.com>
Date:   Thu Sep 18 11:23:01 2014 +0200
    
    Removed connection settings "deploymentName" attribute
    Added connection settings "deploymentKey attribute (upgraded from "deploymentName")
    
    We don't need to know if the deployment points to a "vfsfile:/" or "vfszip:/"
    
    Now the profile service "deploymentName" is lazily loaded when the component is started or when it goes down because of NoSuchDeployment
    
    Tested with EAP5.1.2 on WAR and EAR.
    -> Deploy new package OK
    -> Delete resource OK
    -> Restart application OK

Comment 6 Libor Zoubek 2014-09-24 12:26:59 UTC
branch:  release/jon3.3.x
link:    https://github.com/rhq-project/rhq/commit/5ad0d9836
time:    2014-09-24 14:11:50 +0200
commit:  5ad0d98367ab0e3d67d4cea853e2a85639c69340
author:  Thomas Segismont - tsegismo@redhat.com
message: Bug 1032054 - Refresh button on Monitoring/Calltime page does not move
         'last 8 hour' time range
         Make CalltimeView implement the refresh mechanism instead of
         CalltimeTableView
         The problem was that #refresh was defined both in Table class
         and AutoResfresh interface.
         (cherry picked from commit
         945aeb12cbf8bb3e382d1d222ad54ae1f8f960cf) Signed-off-by: Libor
         Zoubek <lzoubek@redhat.com>

Comment 7 Simeon Pinder 2014-10-01 21:33:36 UTC
Moving to ON_QA as available for test with build:
https://brewweb.devel.redhat.com/buildinfo?buildID=388959

Comment 8 Sunil Kondkar 2014-10-10 13:35:31 UTC
Verified on JON 3.3 ER04

Followed the steps and verified that admin-console.war connection settings does not have"deploymentName" attribute. It shows the 'Deployment Key. property. After final step verified that admin-console.war is up and operations like stop, start, restart are successful on EAP resource.


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