Bug 812452 - [eap6] timeout issues - deployment
Summary: [eap6] timeout issues - deployment
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: RHQ Project
Classification: Other
Component: Agent
Version: 4.4
Hardware: Unspecified
OS: Unspecified
high
unspecified
Target Milestone: ---
: RHQ 4.4.0
Assignee: Heiko W. Rupp
QA Contact: Mike Foley
URL:
Whiteboard:
Depends On:
Blocks: as7-plugin rhq-uxd
TreeView+ depends on / blocked
 
Reported: 2012-04-13 18:51 UTC by Libor Zoubek
Modified: 2016-10-04 15:44 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2013-09-01 10:16:56 UTC
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 802796 0 high CLOSED Request more information on Deployment timeout setting 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 1381640 0 high CLOSED DomainDeployment content update fails due to upload or deploy timeouts 2021-02-22 00:41:40 UTC

Internal Links: 802796 1381640

Description Libor Zoubek 2012-04-13 18:51:07 UTC
Description of problem: In general, almost all operations invoked on EAP by agent can timeout. Today I had issues with creating deployment. My machine had swap filled by 700M  and EAP became too slow then.

This BZ might be related to other operations that are adding/removing a child on EAP.

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


How reproducible:hard


Steps to Reproduce:
1.Have an overloaded machine - low memory
2.standup EAP6 on it, inventory it
3.create WAR Deployment on it using JON UI
  
Actual results:

If EAP is too slow, child resource creation fails with timeout. Although, deployment appears on EAP. Further attempts to create a resource will be refused by EAP (duplicate resource). But deployment is not discovered (operation failed and discovery was not triggered) so user expects it really failed.

Expected results: if deploying times out and fails, deployment should not be on EAP. Otherwise deployment must succeed.


Additional info: This can be much bigger issue not only for overloaded machine, but also larger deployments. I was deploying WAR that contains 1 JSP. Customers will more likely deploy larger applications and could potentially run into same issue.

Comment 1 Charles Crouch 2012-04-16 15:25:28 UTC
Potentially related to https://bugzilla.redhat.com/show_bug.cgi?id=802796

Comment 2 Heiko W. Rupp 2012-04-25 04:59:46 UTC
There are two issues to this:

- When you create a deployment, and do not specify a timeout explicitly then a value of 60 seconds is assumed, after which the plugin container reports a failure no matter what happens inside the plugin

- the plugin currently had a fixed timeout of 10s for connecting and 60s for upload.
-- the plugin does not have access to the timeout from the wizard to e.g. set its value to (x-1)s

One could pass the timeout from the UI to the plugin and give the plugin a hint about the minimal timeout requested from the user. Just setting it to e.g. 10min inside the plugin will not work, if the user does not specify a timeout in the UI.

Comment 3 Heiko W. Rupp 2012-04-25 09:01:12 UTC
master 38935c2

Default timeout for uploads is now increased to 120 seconds. The user can override this via timeout setting in the UI; this timeout setting applies to the total time the plugin is working in the createChild method. This means that with a setting of 120sec in the UI, it is possible that the actual time that an upload may take is only 119sec.

Comment 4 Heiko W. Rupp 2013-09-01 10:16:56 UTC
Bulk closing of items that are on_qa and in old RHQ releases, which are out for a long time and where the issue has not been re-opened since.


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