Skip to content
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

Closed
dfens opened this issue Nov 10, 2014 · 4 comments
Closed

Question on broken connection from client #186

dfens opened this issue Nov 10, 2014 · 4 comments
Assignees

Comments

@dfens
Copy link

dfens commented Nov 10, 2014

Here: https://github.com/jruby/jruby-rack/blob/master/src/main/ruby/jruby/rack/response.rb#L178

We can see following code

rescue NativeException => e
# Don't needlessly raise errors because of client abort exceptions
raise unless e.cause.toString =~ /(clientabortexception|broken pipe)/i
ensure
@body.close if @body.respond_to?(:close)

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?

@kares
Copy link
Member

kares commented Nov 10, 2014

just look through history and it mentions a bug report fa3ace9

@dfens
Copy link
Author

dfens commented Nov 14, 2014

Thank you @kares.
Problem is that I need to know that client connection was broken not between beginning of request (which is handled) and writing response (which is not handled).

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

@kares
Copy link
Member

kares commented Nov 17, 2014

yep, you're right it should have been configurable ... will see what I can do, what is the monkey-patch like ?
in terms of not-getting the failure you want, does it come back wrapped to you or something, if not I might not be able to help you without knowing (looking at) your servlet container specifics ... do not expect much!

@kares
Copy link
Member

kares commented Dec 29, 2014

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!

@kares kares closed this as completed Dec 29, 2014
kares added a commit that referenced this issue Dec 30, 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants