OpenSRF 2.5
Using an nginx proxy (and likely haproxy, though unconfirmed) results in the osrf-http-translator module seeing the client IP address as that of the proxy instead of the true client. This makes it possible, though still very unlikely given that jabber IDs are randomized, for 2 clients to attempt to talk to the same opensrf worker process.
What's worse, though, the IP address reported by Apache for the connecting proxy (confirmed with nginx) toggles between the IPv4 address and the IPv6 address, preventing the translator from maintaining long-lived transactions (e.g. evergreen pcrud transactions), since the IP of the client must be consistent with every call within the transaction.
These may not be identical problems, but they have identical solutions, which is to extract and use the client IP address from the headers provided by the proxy and use those as the client IP address.
To confirm the bug in Evergreen land, configure the proxy for use, then try to create an Acquisitions provider. For me, it fails every time. Regardless of whether if fails, though, it will report 127.0.0.1 (or similar) as the client IP in the activity logs, even for remote clients (which most are).
Note this does not affect WebSockets or the JSON Gateway -- only the translator.
One solution that I have confirmed works in Apache 2.4:
1. apt-get install libapache2-mod-rpaf
2. Add to Apache configuration:
<IfModule mod_rpaf.c>
RPAFenable On
RPAFsethostname On
# Extract IP's from any proxy in 127.* -- change to taste.
RPAFproxy_ips 127.0.0.0/8
</IfModule>
I also tried mod_remoteip, but could not get it to work -- it may not be has comprehensive as mod_rpaf. Specifically, we need the value applied to (in C) request_rec->connection->client_ip (or ->remote_id for Apache 2.2).
Alternatively, we could teach the translator to read the headers (or a custom header) directly.
Confirming this issue since I just hit it with the hard due date editor. Also noting that berick's proposed additions worked for me on Ubuntu 16.04 system.