GitHub PushEvent at 2014-01-27 19:05:31
Repository: haproxy
Actor: jbuchbinder
Payload: {"shas":[["45b34e8abc1feff7a219354e6295f87c687aa105","aff024fe4ab0fece4091de044c58c9ae4233383a@1wt.eu","MINOR: connection: add more error codes to report connection errors\n\nIt is quite often that an connection error only reports \"socket error\" with\nno more information. This is especially problematic with health checks where\nmany causes are possible, including resource exhaustion which do not lead to\na valid errno code. So let's add explicit codes to cover these cases.","Willy Tarreau",true],["9ce7013429fa5e8be37bf7e450c3566184c204ad","aff024fe4ab0fece4091de044c58c9ae4233383a@1wt.eu","MEDIUM: tcp: report connection error at the connection level\n\nNow when a connection error happens, it is reported in the connection\nso that upper layers know exactly what happened. This is particularly\nuseful with health checks and resources exhaustion.","Willy Tarreau",true],["4bd07de0870d07e5aa202841bd2e73418167a6c0","aff024fe4ab0fece4091de044c58c9ae4233383a@1wt.eu","MEDIUM: checks: make use of chk_report_conn_err() for connection errors\n\nChecks used not to precisely report the errors that were detected at the\nconnection layer (eg: too many SSL connections). Using chk_report_conn_err()\nmakes this possible.","Willy Tarreau",true],["e7054c71773854c40021c3ae042c2e4d8f07b926","15877c8bafb69d687da10456165207a2ed30539a@exceliance.fr","BUG/MINOR: payload: the patterns of the acl \"req.ssl_ver\" are no parsed with the good function.\n\nThe fetch \"req.ssl_ver\" is not declared as explicit acl. If it is used\nas implicit ACL, the acl engine detect SMP_T_UINT output type and choose\nto use the default interger parser: pat_parse_int(). This fetch needs the\nparser pat_parse_dotted_ver().\n\nThis patch declare explicit ACL named \"req.ssl_ver\" that use the good\nparser function pat_parse_dotted_ver().","Thierry FOURNIER",true],["1f0da2485ea53b86a254be061ded69f5371d4a05","aff024fe4ab0fece4091de044c58c9ae4233383a@1wt.eu","BUG/MEDIUM: unique_id: HTTP request counter is not stable\n\nPatrick Hemmer reported that using unique_id_format and logs did not\nreport the same unique ID counter since commit 9f09521 (\"BUG/MEDIUM:\nunique_id: HTTP request counter must be unique!\"). This is because\nthe increment was done while producing the log message, so it was\nperformed twice.\n\nA better solution consists in fetching a new value once per request\nand saving it in the request or session context for all of this\nrequest's life.\n\nIt happens that sessions already have a unique ID field which is used\nfor debugging and reporting errors, and which differs from the one\nsent in logs and unique_id header.\n\nSo let's change this to reuse this field to have coherent IDs everywhere.\nAs of now, a session gets a new unique ID once it is instanciated. This\nmeans that TCP sessions will also benefit from a unique ID that can be\nlogged. And this ID is renewed for each extra HTTP request received on\nan existing session. Thus, all TCP sessions and HTTP requests will have\ndistinct IDs that will be stable along all their life, and coherent\nbetween all places where they're used (logs, unique_id header,\n\"show sess\", \"show errors\").\n\nThis feature is 1.5-specific, no backport to 1.4 is needed.","Willy Tarreau",true],["d153b3b09615d850dbced3ff6362b3117182821d","aff024fe4ab0fece4091de044c58c9ae4233383a@1wt.eu","DOC: fix misleading information about SIGQUIT\n\nSIGQUIT dumps the pools state to stderr, not to the logs. Thanks to\nJim Freeman for reporting this.","Willy Tarreau",true],["4afd70aeaba5ca2952e60f978701c7f98dc438ae","aff024fe4ab0fece4091de044c58c9ae4233383a@1wt.eu","BUG/MAJOR: fix freezes during compression\n\nRecent commit d7ad9f5 (\"MAJOR: channel: add a new flag CF_WAKE_WRITE to\nnotify the task of writes\") introduced this new CF_WAKE_WRITE flag that\nan analyser which requires some free space to write must set if it wants\nto be notified.\n\nUnfortunately, some places were missing. More specifically, the\ncompression engine can rarely be stuck by a lack of output space,\nespecially when dealing with non-compressible data. It then has to\nstop until some pending data are flushed and for this it must set\nthe CF_WAKE_WRITE flag. But these cases were missed by the commit\nabove.\n\nFortunately, this change was introduced very recently and never\nreleased, so the impact was limited.\n\nHuge thanks to Sander Klein who first reported this issue and who kindly\nand patiently provided lots of traces and test data that made it possible\nto reproduce, analyze, then fix this issue.","Willy Tarreau",true],["e6300be8f807858d146d23b4eabb9934b96873ee","aff024fe4ab0fece4091de044c58c9ae4233383a@1wt.eu","BUG/MEDIUM: stream-interface: don't wake the task up before end of transfer\n\nRecent commit d7ad9f5 (\"MAJOR: channel: add a new flag CF_WAKE_WRITE to\nnotify the task of writes\") was not correct. It used to wake up the task\nas soon as there was some write activity and the flag was set, even if there\nwere still some data to be forwarded. This resulted in process_session()\nbeing called a lot when transfering chunk-encoded HTTP responses made of\nvery large chunks.\n\nThe purpose of the flag is to wake up only a task waiting for some\nroom and not the other ones, so it's totally counter-productive to\nwake it up as long as there are data to forward because the task\nwill not be allowed to write anyway.\n\nAlso, the commit above was taking some risks by not considering\ncertain events anymore (eg: state != SI_ST_EST). While such events\nare not used at the moment, if some new features were developped\nin the future relying on these, it would be better that they could\nbe notified when subscribing to the WAKE_WRITE event, so let's\nrestore the condition.","Willy Tarreau",true],["f1ed327a7af2dd4b34b80e5a575f88f5522e61b1","aff024fe4ab0fece4091de044c58c9ae4233383a@1wt.eu","BUILD: fix VERDATE exclusion regex\n\nA backslash was missing. It used to work well with GNU grep anyway but\nbetter fix it.","Willy Tarreau",true],["69a41fa8a397ec9608ce448e2cef4c7480d18433","aff024fe4ab0fece4091de044c58c9ae4233383a@1wt.eu","CLEANUP: polling: rename \"spec_e\" to \"state\"\n\nWe're completely changing the way FDs will be polled. First, let's fix\na few field names which become confusing. \"spec_e\" was used to store a\nspeculative I/O event state. Now we'll store the whole R/W states for\nthe FD there.","Willy Tarreau",true],["8e84c637d1d123ec57441f6ae07dd450b160d6e7","aff024fe4ab0fece4091de044c58c9ae4233383a@1wt.eu","DOC: add a diagram showing polling state transitions\n\nThis is internal stuff.","Willy Tarreau",true],["15a4dec87eac29b45182e0927114d98c7e147d97","aff024fe4ab0fece4091de044c58c9ae4233383a@1wt.eu","REORG: polling: rename \"spec_e\" to \"state\" and \"spec_p\" to \"cache\"\n\nWe're completely changing the way FDs will be polled. There will be no\nmore speculative I/O since we'll know the exact FD state, so these will\nonly be cached events.\n\nFirst, let's fix a few field names which become confusing. \"spec_e\" was\nused to store a speculative I/O event state. Now we'll store the whole\nR/W states for the FD there. \"spec_p\" was used to store a speculative\nI/O cache position. Now let's clearly call it \"cache\".","Willy Tarreau",true],["16f649c82c8119d28d4b9e8c926772f20211c857","aff024fe4ab0fece4091de044c58c9ae4233383a@1wt.eu","REORG: polling: rename \"fd_spec\" to \"fd_cache\"\n\nSo fd_spec was renamed \"fd_cache\" as it's becoming an event cache, and\nfd_nbspec becomes fd_cache_num.","Willy Tarreau",true],["899d95757e74c57feaff9fe0dd62c3327d5681ba","aff024fe4ab0fece4091de044c58c9ae4233383a@1wt.eu","REORG: polling: rename the cache allocation functions\n\n- alloc_spec_entry() becomes fd_alloc_cache_entry()\n- release_spec_entry() becomes fd_release_cache_entry()","Willy Tarreau",true],["033cd9d78c9930677f28d150d8bbb10f50cf6f3d","aff024fe4ab0fece4091de044c58c9ae4233383a@1wt.eu","REORG: polling: rename \"fd_process_spec_events()\" to \"fd_process_cached_events()\"\n\nThis is in order to be coherent with the rest.","Willy Tarreau",true],["f817e9f4732d20911445348ac5ac2b2af1893a20","aff024fe4ab0fece4091de044c58c9ae4233383a@1wt.eu","MAJOR: polling: rework the whole polling system\n\nThis commit heavily changes the polling system in order to definitely\nfix the frequent breakage of SSL which needs to remember the last\nEAGAIN before deciding whether to poll or not. Now we have a state per\ndirection for each FD, as opposed to a previous and current state\npreviously. An FD can have up to 8 different states for each direction,\neach of which being the result of a 3-bit combination. These 3 bits\nindicate a wish to access the FD, the readiness of the FD and the\nsubscription of the FD to the polling system.\n\nThis means that it will now be possible to remember the state of a\nfile descriptor across disable/enable sequences that generally happen\nduring forwarding, where enabling reading on a previously disabled FD\nwould result in forgetting the EAGAIN flag it met last time.\n\nSeveral new state manipulation functions have been introduced or\nadapted :\n  - fd_want_{recv,send} : enable receiving/sending on the FD regardless\n    of its state (sets the ACTIVE flag) ;\n\n  - fd_stop_{recv,send} : stop receiving/sending on the FD regardless\n    of its state (clears the ACTIVE flag) ;\n\n  - fd_cant_{recv,send} : report a failure to receive/send on the FD\n    corresponding to EAGAIN (clears the READY flag) ;\n\n  - fd_may_{recv,send}  : report the ability to receive/send on the FD\n    as reported by poll() (sets the READY flag) ;\n\nSome functions are used to report the current FD status :\n\n  - fd_{recv,send}_active\n  - fd_{recv,send}_ready\n  - fd_{recv,send}_polled\n\nSome functions were removed :\n  - fd_ev_clr(), fd_ev_set(), fd_ev_rem(), fd_ev_wai()\n\nThe POLLHUP/POLLERR flags are now reported as ready so that the I/O layers\nknows it can try to access the file descriptor to get this information.\n\nIn order to simplify the conditions to add/remove cache entries, a new\nfunction fd_alloc_or_release_cache_entry() was created to be used from\npollers while scanning for updates.\n\nThe following pollers have been updated :\n\n   ev_select() : done, built, tested on Linux 3.10\n   ev_poll()   : done, built, tested on Linux 3.10\n   ev_epoll()  : done, built, tested on Linux 3.10 & 3.13\n   ev_kqueue() : done, built, tested on OpenBSD 5.2","Willy Tarreau",true],["310987a0389d01d4472b2c43c0c650c9b254510b","aff024fe4ab0fece4091de044c58c9ae4233383a@1wt.eu","MAJOR: connection: remove the CO_FL_WAIT_{RD,WR} flags\n\nThese flags were used to report the readiness of the file descriptor.\nNow this readiness is directly checked at the file descriptor itself.\nThis removes the need for constantly synchronizing updates between the\nfile descriptor and the connection and ensures that all layers share\nthe same level of information.\n\nFor now, the readiness is updated in conn_{sock,data}_poll_* by directly\ntouching the file descriptor. This must move to the lower layers instead\nso that these functions can disappear as well. In this state, the change\nworks but is incomplete. It's sensible enough to avoid making it more\ncomplex.\n\nNow the sock/data updates become much simpler because they just have to\nenable/disable access to a file descriptor and not to care anymore about\nits readiness.","Willy Tarreau",true],["e1f50c4b025330511cca1b5218d2f4537743ea19","aff024fe4ab0fece4091de044c58c9ae4233383a@1wt.eu","MEDIUM: connection: remove conn_{data,sock}_poll_{recv,send}\n\nWe simply remove these functions and replace their calls with the\nappropriate ones :\n\n  - if we're in the data phase, we can simply report wait on the FD\n  - if we're in the socket phase, we may also have to signal the\n    desire to read/write on the socket because it might not be\n    active yet.","Willy Tarreau",true],["fd803bb4d7272deeb9c6847ca01e9e51bc52ffbb","aff024fe4ab0fece4091de044c58c9ae4233383a@1wt.eu","MEDIUM: connection: add check for readiness in I/O handlers\n\nThe recv/send callbacks must check for readiness themselves instead of\nhaving their callers do it. This will strengthen the test and will also\nensure we never refrain from calling a handshake handler because a\ndirection is being polled while the other one is ready.","Willy Tarreau",true],["708e71725160b2ab10c84045f0e56a3c8ba99518","aff024fe4ab0fece4091de044c58c9ae4233383a@1wt.eu","MEDIUM: stream-interface: the polling flags must always be updated in chk_snd_conn\n\nWe used to only update the polling flags in data phase, but after that\nwe could update other flags. It does not seem possible to trigger a\nbug here but it's not very safe either. Better always keep them up to\ndate.","Willy Tarreau",true]],"size":30,"ref":"refs/heads/master","head":"a84541036066df1fada7ffb3c4c83e6b92500ccb"}