> -----Original Message-----
> From: resin-interest-boun...@caucho.com [mailto:resin-interest-
> boun...@caucho.com] On Behalf Of Scott Ferguson
> Sent: Wednesday, February 22, 2012 1:17 PM
> To: firstname.lastname@example.org
> Subject: Re: [Resin-interest] Resin 4.0 Clustering and HTTP MULTIPART
> On 02/22/2012 11:08 AM, Aaron Freeman wrote:
> > Does Resin 4.0 have any notion of handling a situation where a large
> > HTTP MULTIPART POST request has come in (a large file transfer for
> > example), and then when one of the nodes of the cluster that is
> > handling that MULTIPART POST were to go offline, another node would
> > take over with no interruption between the client and the cluster?
> > If not, is there any technology that handles large MULTIPART POSTs in
> > some redundant form like that?
> I'm not sure I understand the question.
> At the base level, a POST is just a stream of bytes. The multipart/mime
> handling is just a convenience parser on top so you don't have to parse it
> yourself. A half-parsed POST (or fully parsed, but not processed) isn't
> something that can be failed over automatically, because the individual
> aren't really meaningful.
> But we also can't failover POSTs at all once the dispatch has begun,
> there's no way for Resin to know if the application's POST handling is
> idempotent, safe to retry. We can failover on a load-balancer/app-server
> connection failure, or on a 503 response, but not on any other kind of
Right, I had a hard time articulating the problem, but I think you did get
the gist of it based on your response.
I guess what I was hoping for is if there is a technology that can multicast
(wrong word because multicast works on UDP, but I mean _conceptually_
multicast) an HTTP POST to multiple servers simultaneously such that both
servers receive the inbound stream and can record it, then possibly only one
sends back the response (perhaps both nodes send the response back, but the
triad chooses one as the final response and ignores the other). I am
architecting off the cuff here, but was just wondering if something like
that or some alternative exists. Sounds like your answer is a clear "no".
But if you could multicast an HTTP POST like that, wouldn't it be
conceptually feasible to have an automatic failover? Or is there something
lower level going on that I am completely missing (probably the case).
resin-interest mailing list