[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


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


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