Bug 1031152 - Deployment of EAP 6.1.0 cartridge takes ~3 minutes and validation times out
Summary: Deployment of EAP 6.1.0 cartridge takes ~3 minutes and validation times out
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: ImageStreams
Version: 2.0.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: ---
Assignee: Jason DeTiberus
QA Contact: libra bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-11-15 18:02 UTC by Jesse Sightler
Modified: 2017-03-08 17:35 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-11-21 20:06:23 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Jesse Sightler 2013-11-15 18:02:14 UTC
Every deployment of a non-scaled EAP 6.1 gear takes ~3 minutes. I see these lines in the log that seems to indicate the cause:
November 14 14:29:03 INFO oo_spawn buffer(11/) Starting jbosseap cartridge
November 14 14:29:28 INFO oo_spawn buffer(11/) Found 127.1.244.1:8080 listening port
November 14 14:29:28 INFO oo_spawn buffer(11/) Found 127.1.244.1:9999 listening port
November 14 14:30:58 INFO oo_spawn buffer(11/) CLIENT_MESSAGE: Could not connect to JBoss management interface, skipping deployment verification

Using curl -v http://127.1.244.1:8080 and curl -v http://127.1.244.1:9990/ on the node itself provides the expected result. Setting selinux to permissive still results in the same errors, so I don't think that selinux is restricting the network calls from the node itself either.

Hitting the external url in the browser works as well.

Comment 2 Jesse Sightler 2013-11-20 21:51:20 UTC
This is now looking like a firewall issue with my local node (specific to the iptables configuration in our environment). I'm still investigating, but I think this might be closable soon...

Comment 3 Jesse Sightler 2013-11-21 20:06:23 UTC
This was due to a dns server taking a long time to respond in our environment. And that was due to an iptables restriction.

I do not believe that there is a bug here. Closing.


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