Project

General

Profile

Bug #598

A 5 second timeout is to small on the proxy interface

Added by Paul Kelly over 8 years ago. Updated over 8 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Host creation
Target version:
Difficulty:
Triaged:
No
Bugzilla link:
Pull request:
Team Backlog:
Fixed in Releases:
Found in Releases:

Description

Some smart-proxy operations take considerable time. The free_ip call could take a very long time so 5 seconds is just not long enough

Associated revisions

Revision 98445b00 (diff)
Added by Ohad Levy over 8 years ago

fixes #598 - A 5 second timeout is to small on the proxy interface

History

#1 Updated by Ohad Levy over 8 years ago

more than 5 seconds is not acceptable in terms of a web request.
in which scenarios does 5 seconds is too short? so far I didn't see such a problem....

#2 Updated by Paul Kelly over 8 years ago

  • Category set to Host creation
  • Status changed from New to Ready For Testing
  • Assignee set to Paul Kelly
  • Branch set to bug/598-short-proxy-timeout

[[4;36;1mSmartProxy Columns (0.7ms)[[0m [[0;1mSHOW FIELDS FROM `smart_proxies`[[0m
[[4;35;1mSmartProxy Load (0.3ms)[[0m ^[[0mSELECT * FROM `smart_proxies` WHERE (`smart_proxies`.`id` = 2) ^[[0m
failed to fetch a free IP from our proxy: Request Timeout

ActionView::MissingTemplate (Missing template subnets/freeip.erb in view path app/views):
/usr/lib/ruby/1.8/webrick/httpserver.rb:104:in `service'
/usr/lib/ruby/1.8/webrick/httpserver.rb:65:in `run'

Add a DHCP reservation for brslc025.brs.infineon.com/172.29.205.25
Failed to set the DHCP record: Request Timeout
Rolling back due to a problem: DHCP Settings for brslc025.brs.infineon.com 10 failed brslc025.brs.infineon.comsetDHCP

It may be possible that the DHCP timeout was due to my code being stopped in the debugger, (but I do not think that it was,) but the freeip was definitely a timeout.

What is the purpose of this timeout? It is so that the system does not lock up and need manual intervention. With this logic then a one minute timeout should be fine. Foreman should never timeout if there is any possibility whatsoever that the operation will complete. ("Slow" is not a bug or failure, though it does need some investigation.)

This slowness has been observed when running the native_ms DHCP proxy. Maybe the Windows box was being hammered when this operation took place. It is a virtual NT machine, and does not host the DHCP server itself, though they are both on the same site.

#3 Updated by Ohad Levy over 8 years ago

  • Target version set to 0.2

#4 Updated by Ohad Levy over 8 years ago

  • % Done changed from 0 to 100

#5 Updated by Ohad Levy over 8 years ago

  • Status changed from Ready For Testing to Closed

Also available in: Atom PDF