On some systems (e.g. my MacOS laptop with a custom Varnish build for testing), PHP will not release the socket fast enough after writing data to the control terminal. Previously I have used a 50ms pause — usleep(50) — between the write and the read in order to compensate this.
A better answer is to give the socket read function the ability to recursively retry if it gets the "temporarily unavailable" error response (code 35).
Attached is a first attempt at adding this capability.
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | varnish-socket-read-retry-3.patch | 1.25 KB | fabsor |
| varnish-socket-read-retry.patch | 1.34 KB | joshk |
Comments
Comment #1
fabsor commentedI looked around for an option to set on the socket that could help, but there doesn't seem to be any good ones, so this looks like a good approach to me. I'm setting this to needs review, I will also test this a little more in depth later.
Comment #2
joshk commentedAgreed on needing more testing. I also feel the recursion itself could be more elegant.
Comment #3
fabsor commentedThe tests run fine with this patch. The attached patch just contains some cosmetic changes.
Comment #4
rjbrown99 commentedI get a number of those temp unavailable messages, despite a high timeout. I popped in #3, we'll see how it goes.
Comment #5
helmo commentedOnly minor merge fix was needed when I applied this after #1089878: Make it possible to execute more than one command in one connection.
Simpletest succeeds and basic functioning seems ok.
Comment #6
fabsor commented@helmo Thanks for the review! This makes us a bit closer to a release, and that's really appreciated!
@rjbrown99 Did the patch work for you? I have never experienced this errors on any of my machines and I would really like to get this in so that we can release the first real release of this module, and this is one of the blockers currently =)
Comment #7
rjbrown99 commentedI suspect this helped things quite a bit. I also made Varnish changes to the VCL, specifically to better handle POSTs. I posted about it here:
http://groups.drupal.org/node/28604#comment-496214
Comment #8
fabsor commentedThis issue is a tough one to determine if it's fixed or not, but since it does not break anything and might improve the situation for certain users, I deem this issue fixed. Commited to head.
Thanks everyone who took the time to review and test, it is really appreciated!