aceyangnuuo / hudson-tray-tracker

Automatically exported from code.google.com/p/hudson-tray-tracker
0 stars 0 forks source link

HTTP sessions are not reused #12

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
HTTP sessions are not reused. This is a problem because lots of sessions
are kept open in Hudson.

Original issue reported on code.google.com by Alexis.S...@gmail.com on 13 May 2009 at 12:27

GoogleCodeExporter commented 8 years ago

Original comment by Alexis.S...@gmail.com on 13 May 2009 at 12:28

GoogleCodeExporter commented 8 years ago
Reopening: behavior was improved but the sessions are not completely reused.

Original comment by Alexis.S...@gmail.com on 13 May 2009 at 2:30

GoogleCodeExporter commented 8 years ago
This is causing issues for me too.
It appears that instead of opening one TCP/IP connection to each server being 
monitored and then firing a series of HTTP requests down that single 
connection, it's opening one TCP/IP connection per request.
We've got HTT monitoring dozens of projects on my Jenkins server, which 
therefore results in dozens of TCP/IP connections every few seconds.  Whilst 
the Jenkins server can cope with this traffic, the Cisco firewall we've got 
between the developers and the Jenkins server often can't, resulting in HTT 
showing grey projects.  This is a PITA for us.

What I would suggest is that HTT should:
 - have a queue of HTTP requests for each server.
 - have at most one connection per Hudson/Jenkins server.  HTT should start trying to open a connection whenever [the queue of requests goes from empty to non-empty] and [there is no open connection].
 - not add duplicates of requests when adding to the queue (otherwise a HTT would build up a long list of pending requests if the target server is slow).
 - flush the list of pending requests wheneever the HTTP connection failed (as there's no point throwing more traffic at a problematic server - it can wait until the next batch of requests gets triggered)

i.e. minimise the number of TCP connections, maximise the use of each TCP 
connection, and back off if a server doesn't answer nicely.

Original comment by pet...@intrinsica.co.uk on 7 May 2013 at 11:35