Bug 646631 - (EMBJOPR-366) Update farmed Application Deployment (EAR/WAR) results in non-farmed deployment
Update farmed Application Deployment (EAR/WAR) results in non-farmed deployment
Status: CLOSED CURRENTRELEASE
Product: RHQ Project
Classification: Other
Component: Plugins (Show other bugs)
4.2
All All
urgent Severity high (vote)
: ---
: RHQ 4.5.0
Assigned To: Stefan Negrea
Mike Foley
:
Depends On: 820650
Blocks: jon30-bugs jon310-sprint11/rhq44-sprint11 795918 824502
  Show dependency treegraph
 
Reported: 2010-10-25 15:20 EDT by Larry O'Leary
Modified: 2013-09-03 10:32 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 824498 824502 (view as bug list)
Environment:
JON 2.4 EAP 5.0.1 admin-console
Last Closed: 2013-08-31 05:56:34 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
stack trace (10.67 KB, text/plain)
2012-04-17 16:18 EDT, John Mazzitelli
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
JBoss Issue Tracker EMBJOPR-366 Blocker Closed Updating farmed EAR/WAR fails and un-farms app with error @Out attribute requires non-null value: updateBackingContentAc... 2013-12-14 21:13:31 EST

  None (edit)
Description Larry O'Leary 2010-10-25 15:20:46 EDT
Description of problem:
If an application is deployed to an AS instance's farm directory and the Update Content operation is performed, application is no longer deployed to farm.

Version-Release number of selected component (if applicable):
RHQ 3.0.0
JON 2.4.0
Embedded JOPR (admin-console) with EAP 5.0.0, EAP 5.0.1

How reproducible:
Always

Steps to Reproduce:
1. Setup a two node EAP cluster
2. Deploy an application (EAR/WAR) to node1's farm using admin-console
3. Verify application was deployed to both node1 and node2
4. Update the application using the same EAR/WAR (From admin-console, expand and select the deployed EAR/WAR and select it's Content tab and then click Update)

  
Actual results:
The updated deployed application is now only deployed to node1 in its deploy directory

Expected results:
The updated deployed application is deployed to node1 and node2 and appears in their farm directory

Additional info:
This is a result of the StandaloneManagedDeploymentComponent.deployPackages method invoking DeploymentUtils.deployArchive without a means of passing in whether to deploy farmed or not. Currently, the method appears to support a deployExploded boolean but no method of passing in whether it is farmed or not. The DeploymentUtils.deployArchive method should probably accept a deployFarmed boolean as well as the deployPackages method being updated to check to see if the updated deployment was farmed. Of course, this may be very error prone as this would be directly tied to a hard-coded path name. Maybe we should gather these options from ProfileService or Inventory before we remove the old deployment?
Comment 2 Larry O'Leary 2012-02-10 14:26:30 EST
This issue also appears to be the direct cause of https://issues.jboss.org/browse/JBPAPP-8084
Comment 6 Charles Crouch 2012-04-12 15:14:45 EDT
unassigning from Ian as he's focused on EAP6
Comment 7 John Mazzitelli 2012-04-17 15:08:05 EDT
http://docs.redhat.com/docs/en-US/JBoss_Enterprise_Application_Platform/5/html/Administration_And_Configuration_Guide/clustering-intro.chapt.html#clustering-quickstart

for setting up a cluster. but...

03:05:01 PM) loleary: No need for an actual cluster...
(03:06:07 PM) loleary: Basically... deploy farmed and confirm the app shows up in ${JBOSS_CONF}/farmed
(03:06:29 PM) loleary: Then, re-deploy and you will see it get moved from ${JBOSS_CONF}/farmed to ${JBOSS_CONF}/deploy
Comment 8 Larry O'Leary 2012-04-17 15:11:59 EDT
A cluster is not necessary to confirm the bad behavior of WAR/EAR being deployed to farmed and then re-deployed to deploy, but for testing, an easy way to setup a two node cluster is:

Install EAP 5 as normal
Copy all or production configuration to server1 and server2
Be sure to enable admin account (jmx-console-users.properties) for server1 and serer2
Then start server1 as normal
   # Start EAP server1
   # EAP 5.1.2 
   PRODDIST_BRANCH="origin/jboss-eap-5.1.2"
      pushd "${TESTENV_DIR}/$(basename ${PRODDIST_BRANCH})/jboss-as" \
      && rm -rf server/server1/log \
      && cd bin \
      && ./run.sh -c server1 -b 0.0.0.0 &

Then start server2 using a different port number and ServerPeerID
   # Start EAP server2
   # EAP 5.1.2 
   PRODDIST_BRANCH="origin/jboss-eap-5.1.2"
      pushd "${TESTENV_DIR}/$(basename ${PRODDIST_BRANCH})/jboss-as" \
      && rm -rf server/server1/log \
      && cd bin \
      && ./run.sh -c server2 -b 0.0.0.0 -Djboss.service.binding.set=ports-01 -Djboss.messaging.ServerPeerID=1 &
Comment 10 John Mazzitelli 2012-04-17 16:18:05 EDT
Created attachment 578137 [details]
stack trace

not only did I see the file get deployed to deploy/ and removed from farm/ but I also got the attached exception.
Comment 12 John Mazzitelli 2012-04-17 16:35:20 EDT
looks like we need to do the same thing that org.rhq.plugins.jbossas5.deploy.ManagedComponentDeployer.deploy(CreateResourceReport, ResourceType) does - it appears to switch to farm mode, then deploys:

            DeploymentManager deploymentManager = this.profileServiceConnection.getDeploymentManager();
            boolean deployFarmed = deployTimeConfig.getSimple("deployFarmed").getBooleanValue();
            if (deployFarmed) {
                Collection<ProfileKey> profileKeys = deploymentManager.getProfiles();
                boolean farmSupported = false;
                for (ProfileKey profileKey : profileKeys) {
                    if (profileKey.getName().equals(FARM_PROFILE_KEY.getName())) {
                        farmSupported = true;
                        break;
                    }
                }
                if (!farmSupported) {
                    throw new IllegalStateException("This application server instance is not a node in a cluster, "
                        + "so it does not support farmed deployments. Supported deployment profiles are " + profileKeys
                        + ".");
                }
                if (deployExploded) {
                    throw new IllegalArgumentException(
                        "Deploying farmed applications in exploded form is not supported by the Profile Service.");
                }
                deploymentManager.loadProfile(FARM_PROFILE_KEY);
            }

            String[] deploymentNames;
            try {
                deploymentNames = DeploymentUtils.deployArchive(deploymentManager, archiveFile, deployExploded);
            } finally {
                // Make sure to switch back to the 'applications' profile if we switched to the 'farm' profile above.
                if (deployFarmed) {
                    deploymentManager.loadProfile(APPLICATIONS_PROFILE_KEY);
                }
            }
Comment 13 John Mazzitelli 2012-04-18 15:18:28 EDT
git commit to master 951ddce
Comment 17 Larry O'Leary 2012-05-18 10:34:48 EDT
Mazz, I am reassigning this to you as it fails due to package names not matching. It appears this might be related to the content version hash that is auto-generated and ends up in the file's name.
Comment 18 Charles Crouch 2012-05-21 21:42:53 EDT
Setting Assigned To correctly
Comment 19 Stefan Negrea 2012-05-23 11:22:45 EDT
The AS5 deployer uses the file name as-is to determine the name of the app to be updated/deployed. Instead of adding the random UUID to the archive to be deployed, add the random UUID to a temp folder name and then download content there (leaving the file name unchanged). This issue has been fixed for both farmed and non-farmed deployments.

Another update was to switch to the farm version of the AS5 deployer prior to stopping and deleting existing content. The switch to a farm deployer was happening too late (prior to deployment) and was not stopping and removing the farmed application prior to the new deployment.

master branch commits:
http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=commit;h=b458447208ec5207eea6f29eaafcd3ca9e5371a6

http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=commit;h=c3bbd873832ec7df6d9db4b24190fabad7d1b48f
Comment 20 Eiichi Nagai 2012-05-30 20:11:48 EDT
Update farmed Application Deployment (EAR/WAR) from JBoss ON GUI console was available
Comment 21 Charles Crouch 2012-06-18 17:25:35 EDT
(4:21:56 PM) ccrouch: ips: how come you set the Target Release of https://bugzilla.redhat.com/show_bug.cgi?id=646631 to be RHQ4.3?
(4:22:19 PM) ccrouch: i think it should be 4.5, given stefan_n's commits https://bugzilla.redhat.com/show_bug.cgi?id=646631#c19
(4:24:40 PM) ips: yeah, you're right, i misread the date on his commits
(4:25:05 PM) ccrouch: ok, i'll reset it
Comment 22 JBoss JIRA Server 2012-06-18 17:42:00 EDT
Ian Springer <ian.springer@redhat.com> made a comment on jira EMBJOPR-366

I tried cherry-picking the three commits for bug 646631 to the AdminConsole_EAP_5_1 branch. Mazz's commit merged cleanly, but Stefan's two commits had a lot of conflicts, due to so much time passing since AdminConsole_EAP_5_1 was forked. To fix this, we'll either need to manually fix all those conflicts or upgrade the version of RHQ used by the AdminConsole_EAP_5_1 EmbJopr branch to 4.4 or 4.5.
Comment 23 JBoss JIRA Server 2012-06-27 00:12:28 EDT
Stefan Negrea <snegrea@redhat.com> made a comment on jira EMBJOPR-366

Cherry-picked the two commits to AdminConsole_EAP_5_1. I only merged changes relevant to farmed deployments.

AdminConsole_EAP_5_1 branch commits:
http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=commit;h=8a9c9cbdb14665c4a98dc2c74275a91fe4a9cf0b
http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=commit;h=83656e08b3fec3ffbc877e2603641af59ff24d7f
Comment 24 JBoss JIRA Server 2012-07-09 16:18:14 EDT
Larry O'Leary <loleary@redhat.com> updated the status of jira EMBJOPR-366 to Resolved
Comment 25 JBoss JIRA Server 2012-07-09 16:18:14 EDT
Larry O'Leary <loleary@redhat.com> made a comment on jira EMBJOPR-366

Committed to release branch for 1.3.4.SP6 as per https://issues.jboss.org/browse/EMBJOPR-366?focusedCommentId=12703452&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12703452
Comment 26 JBoss JIRA Server 2013-09-03 10:32:57 EDT
Larry O'Leary <loleary@redhat.com> updated the status of jira EMBJOPR-366 to Closed

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