-
Notifications
You must be signed in to change notification settings - Fork 136
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
Question on broken connection from client #186
Comments
just look through history and it mentions a bug report fa3ace9 |
Thank you @kares. I did some monkey patches and tested with client that is writing on port 80 but closes socket before receiving response. but even then I am not getting into NativeException => e (with monkeypatch there). Can you advise me on this? Also - shouldn't this be optional? (same as chunking option), I can imagine situations where changes made by client request should be rollbacked if client did not receive response |
yep, you're right it should have been configurable ... will see what I can do, what is the monkey-patch like ? |
as you already noted it's now supported on 1.1-stable with e075f34 and 82bf64c ... just pushed a SNAPSHOT you can try out: https://oss.sonatype.org/content/repositories/snapshots/org/jruby/rack/jruby-rack/1.1.17-SNAPSHOT/ release shall come still in 2014! |
* 1.1-stable: use distributionManagement instead of (sonatype) pom parent just keep the jruby-home when set by jruby to "uri:classsloader:/META-INF/jruby.home" support configuration of `Response.swallow_client_abort?` (with e075f34 fixes #186) better servlet (3.0) specific API testability [travis-ci] jruby-head should be fine ... from now on :over-9000: [travis-ci] there seems to be a constant failure on TRAVIS=true with the application pool only run t is1_9 he compat-version spec on JRuby < 9k [travis-ci] exclude all of jruby-head with openjdk6 activate -P jars by default due running with `mvn package` only ... setup rubygems repository & let us roll jruby-openssl 0.9.6 setup oss.sonatype.org deployment `gem update --system 2.2.3` on travis-ci travis-ci `sudo: false` is is better client EOF (socket abort "Broken pipe") detection in JRuby::Rack::Response ... we're now "officially" handling Jetty and maybe a bunch of others due EofException allow PATCH verb to be processed by the ruby application
Here: https://github.com/jruby/jruby-rack/blob/master/src/main/ruby/jruby/rack/response.rb#L178
We can see following code
This means that if client connection is broken - there is no exception on server-side (server just does not care if client received response).
My question is - what is the reason for this behaviour? For example i can imagine situation when client posted some data and need to know that it has been processed properly - in such case if connection on response is broken -> we may want to revert change on server side. So this is normal handling of such situations for HTTP requests?
The text was updated successfully, but these errors were encountered: