cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daan Hoogland <>
Subject Re: [DISCUSS] Leaky abstractions [was review requests 13238, 13896, 14320]
Date Sat, 05 Oct 2013 09:28:20 GMT
H Chiradeep,

I am hesitating to keep on about my case of httpClose as this is about the
more general subject you gave this thread, so please take my referals to it
as examples.

so it is in a sense keepAlive (formerly known as ! httpClose) we are
talking about. Then there is a matter of how to implement it as I
understand you have objections to the part where it is in the
networkoffering. Let's take that back to the review thread, alright?

Remains the question of the new feature X that will be common good in next
generations. How art we dealing with that?

And in this case maybe X is default for most but !X is default for
implementation c. To that I'd say implement the options as and take the
default from the largest group of implementations. In httpClose you could
think of default is to keepAlive. I didn't do this to remain backwards
compatible. If that is not a problem I think the engineers at Schuberg
Philis can live with a change of hardcoded settings. I don't like that,
hence my implementation.


On Sat, Oct 5, 2013 at 12:56 AM, Chiradeep Vittal <> wrote:

> I've checked the Netscaler and HAProxy docs, this appears to be artifact
> of the HAProxy implementation (inability to support keep-alive).
> For a cloud operator that chooses Netscaler or F5 for load balancing, this
> won't make any sense.
> On 10/3/13 12:55 PM, "Daan Hoogland" <> wrote:
> >On Thu, Oct 3, 2013 at 9:02 PM, Chip Childers
> ><>wrote:
> >
> >> a model for extensions like that makes perfect sense.
> >
> >
> >
> >This model sound fine indeed. It makes no sense for httpClose however.
> >
> >Here's my concern:
> >So when an early adapter is implemented and the rest of the market comes
> >to
> >their senses, how do we migrate without running into migration/upgrade
> >problems?
> >httpClose is a flag controlling connection pooling. I probably choose the
> >wrong name. It is something that any implementation will support or should
> >have supported already. Am I going to implement it as a key/value now to
> >later implemented as I have done anyway? I don't like this idea.
> >
> >Don't get me wrong the pattern described by you guys is fine in some
> >situations. I don't think it is applicable to this feature.
> >
> >regards,
> >Daan

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message