Re: [Resin-interest] Resin 4.0 Clustering and HTTP MULTIPART

2012-02-22 Thread Aaron Freeman
> -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: resin-interest@caucho.com
> 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
Parts
> aren't really meaningful.
> 
> But we also can't failover POSTs at all once the dispatch has begun,
because
> 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
> response.

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).

Thanks,

Aaron




___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest


Re: [Resin-interest] Resin 4.0 Clustering and HTTP MULTIPART

2012-02-22 Thread Scott Ferguson
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 Parts aren't really meaningful.

But we also can't failover POSTs at all once the dispatch has begun, 
because 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 response.

-- Scott


> Thanks,
>
> Aaron
>
>
>
> ___
> resin-interest mailing list
> resin-interest@caucho.com
> http://maillist.caucho.com/mailman/listinfo/resin-interest
>



___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest


[Resin-interest] Resin 4.0 Clustering and HTTP MULTIPART

2012-02-22 Thread Aaron Freeman
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?

Thanks,

Aaron



___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest