BUG/MINOR: stream: use atomic increments for the request counter
The request counter is incremented when creating a new stream and when
resetting a stream, preparing for a new request. Unfortunately during
the thread migration this was missed, leading to non-atomic increments
in case threads are in use. The most visible side effect is that two
requests may have the same ID from time to time in the logs. However
the SPOE also uses this ID to route responses back to the stream so it
may also lead to occasional spurious SPOE timeouts.
Note that it still doesn't guarantee temporal unicity in the stream
identifiers since a long and a short connection could technically use
the same ID. The likeliness that this happens at the same time is almost
null (roughly threads*runqueue_depth/2^32 that it happens in the same
poll loop), but it will have to be addressed later anyway.
This patch must be backported to 1.8 with the other one it relies on
("MINOR: thread: implement HA_ATOMIC_XADD()").
diff --git a/src/proto_http.c b/src/proto_http.c
index 29b1b68..8ccbc2b 100644
--- a/src/proto_http.c
+++ b/src/proto_http.c
@@ -8364,7 +8364,7 @@
s->target = NULL;
/* re-init store persistence */
s->store_count = 0;
- s->uniq_id = global.req_count++;
+ s->uniq_id = HA_ATOMIC_XADD(&global.req_count, 1);
s->req.flags |= CF_READ_DONTWAIT; /* one read is usually enough */