-
-
Notifications
You must be signed in to change notification settings - Fork 925
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unix sockets raise exception on long writes #3799
Comments
Nice, haven't had a good UNIXSocket bug in a while. What are UNIX sockets used for in a puma set up? I've got some long flights today so I may have time to look into this. |
Puma can use a UNIX socket to listen/respond to HTTP requests. For example, you can proxy requests from Nginx to Puma over a UNIX socket. |
@headius What @TheKidCoder said. |
Ok that makes sense. |
Does this issue correspond to this constant? |
@ericqweinstein Seems plausible...I'm not familiar with that value. |
We may be able to make progress on this with @etehtsea helping work on sockets. Sadly it won't be in 9.1.3.0. |
Hopefully, I have a fix for this. |
Do the same as in 857b76f
@etehtsea Got that fix in a releasable state? We're hoping to push 9.1.6.0 tomorrow. |
@headius no, I don't have better solution for now. |
@etehtsea I guess what I was asking is if the commit above is a "good enough" fix. If so, do you want to throw it in a PR for testing? Status of testing is unclear and this is a key core API. Punting. |
@headius you said earlier that this fix couldn't be "good enough" because possibly it masks real issue. As far as I remember I tested this issue using this app so if needed I could try to convert it to regression spec. |
@headius we never merged following commit to master. etehtsea@613c99f |
@headius This is still happening on 9.1.7.0 for long writes and Unix sockets with Puma. Switching to TCP port configuration for Puma has resolved it temporarily, but that's not a viable solution IMO. Any ETA on the fix? |
@etehtsea I can reproduce on linux. This commit etehtsea@613c99f I've tested, supposed to fix it but it never got merged to master. Only next commit after this was merged. |
Fixed code from jnr-enxio is not used anymore after updating to jnr-unixsocket 0.15.
See jnr/jnr-unixsocket#38 Fixed code from jnr-enxio is not used anymore after updating to jnr-unixsocket 0.15. Regression spec accidentally passes on TravisCI and Ubuntu xenial. In the meantime there are bug reports that issue still reproduces in some environments. Personally I caught it under macOS.
@etehtsea Thanks! Will fetch master and verify this. |
Environment
jruby 9.0.5.0 (2.2.3) 2016-01-26 7bee00d Java HotSpot(TM) 64-Bit Server VM 25.72-b15 on 1.8.0_72-b15 +jit [darwin-x86_64]
Darwin veritas.local 15.4.0 Darwin Kernel Version 15.4.0: Fri Feb 26 22:08:05 PST 2016; root:xnu-3248.40.184~3/RELEASE_X86_64 x86_64
https://github.com/cdonadeo/puma_big_response_test
Expected Behavior
Long strings passed to
UNIXSocket#write
writes the data and returns the number of bytes written.Actual Behavior
#write
writes a subset of the data and raises an exception:#<SystemCallError: Unknown error - >}
. The amount of data varies but I've seen 8192 show up not-randomly, almost like there was a 8k buffer somewhere.The git repo linked to above shows the behavior. The exception in question is raise inside
#fast_write
. Changing the code to use#write
instead of#syswrite
does not change the behavior.The text was updated successfully, but these errors were encountered: