From: Eric Wong <normalperson@yhbt.net>
To: unicorn list <mongrel-unicorn@rubyforge.org>
Cc: Jesse Storimer <jstorimer@gmail.com>
Subject: Re: What happens when a client terminates a connection?
Date: Mon, 8 Aug 2011 20:13:27 +0000 [thread overview]
Message-ID: <20110808201327.GB7188@dcvr.yhbt.net> (raw)
In-Reply-To: <20110808161915.GA49811@jessebook-2.local>
Jesse Storimer <jstorimer@gmail.com> wrote:
> It seems that in this case the Rails app actually aborts the request,
> wherever it is in the course of it. The issue I ran into is that my app
> made a destructive request to an external service in
> the context of a request, but the client disconnected before the app was
> able to respond. So the external service returned its response but the
> request was aborted before the app was able
> to commit its transaction to the database, confusion ensued.
You should make this request to the external service and wait for this
response inside state 3) as described in my other reply[1].
If you're affected by state 2), you should minimize the time in state 2)
by using PrereadInput middleware to jump to state 3) (and you'll avoid
making the external request entirely if the preread input fails due
to the client aborting).
Your goal is to minimize the time spent processing a non-idempotent
request/parts-of-the-request and isolate where a client can fail (and
maximize the time where they can gracefully recover).
If possible, the request you make to the external service should be
idempotent, but it doesn't seem to be...
I haven't encountered this problem myself in many years, but here's
what I did in the past for similar problems:
Call the external service asynchronously and look at the various
background job/queue libraries available to handle this. The client
should probably auto-refresh on a page (idempotently) until the async
request is complete.
I would even hold off on starting your external request until the client
has hit the auto-refresh page. This way you know the client has started
the refresh cycle and you can fake the idempotency of the external
request on your app side.
[1] - http://mid.gmane.org/20110808192824.GA5759@dcvr.yhbt.net
--
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
next prev parent reply other threads:[~2011-08-08 20:17 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-08 16:19 What happens when a client terminates a connection? Jesse Storimer
2011-08-08 19:28 ` Eric Wong
2011-08-08 20:13 ` Eric Wong [this message]
[not found] <20110808193252.GA7188@dcvr.yhbt.net>
2011-08-08 21:17 ` Jesse Storimer
2011-08-08 21:47 ` Eric Wong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://yhbt.net/unicorn/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110808201327.GB7188@dcvr.yhbt.net \
--to=normalperson@yhbt.net \
--cc=jstorimer@gmail.com \
--cc=mongrel-unicorn@rubyforge.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://yhbt.net/unicorn.git/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).