On 3 June 2013 23:19, Ali Majdzadeh <ali.majdza...@gmail.com> wrote:
> Thomas, Jonathan
> Thanks for your responses. Well, the problem I currently face, supposing that 
> I am using the correct terminology, is how to maintain a failed HTTP request; 
> (For example, a file download request). Do you aware of any solutions 
> regarding this issue?

You'll need to write code. Either client-side or server-side (in the
middle, in front of HAProxy), you'll need to solve part of this in
code. However ...

> What is your suggested plan in order to achieve such a solution?

... I suggest you don't.

Sincerely. Don't bother solving this problem, would be my strong
professional suggestion, until a cost/benefit analysis from The
Business demonstrates that you have to.

And if there /isn't/ such an analysis -- if you're just up against
morons who spout "failure is not an option; 100% uptime is essential"
without showing /why/ it's essential -- then your problem isn't a
technical problem; it's a person problem :-)

Here's a very simplified rationale for this: as you write down the
list of moving parts that /could/ fail during a single download, you
will eventually come to the conclusion that solving the problem for
each of those parts *when*they*are*in*an*exceptional*situation* would
take hugely more engineering effort than lost sales will cost you.

Well, probably. I don't know what you're actually serving over HTTP,
of course :-)

> Does HAProxy help in this context?

It can do, due to its extremely configurable health checks. If you've
committed to solving this problem entirely, however, it will need more
than just HAProxy. That's the sort of situation into which I normally
step wearing my "consultant" hat, however, and charge you money ;-)

Jonathan Matthews // Oxford, London, UK

Reply via email to