So, in the spirit of open source software meritocracies: please place
your money where your mouth is. Come up with a list of actionable
changes you'd make if you were king. Lets hear it--and if everyone
agrees to a particular change, we'll declare it made. (Note:
declaring
anything to a volu
On 2007.08.02, Tom Jackson <[EMAIL PROTECTED]> wrote:
> Something has to change here. Either AOL needs to come clean, level
> with the community, or we need to simply inform hapless developers
> what they should expect.
As of November 2006, I no longer work for AOL. Yet, I still remain
involved w
On Thursday 02 August 2007 16:18, Dossy Shiobara wrote:
> On 2007.08.01, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > One of the hallmarks of AOLserver has always been ease of configuration.
> > My sense is that we're drifting away from that?
>
> Frankly, one of the biggest FAQ's is "how do I t
There was a desire to be able to tune some of the server parameters while
the server was running in order to avoid certain cases where a restart would
result in the loss of various caches which had already been warmed up.
Admittedly this requirement came from requirements for various AOL
properties
On 2007.08.01, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> One of the hallmarks of AOLserver has always been ease of configuration.
> My sense is that we're drifting away from that?
Frankly, one of the biggest FAQ's is "how do I tune AOLserver?" IMHO,
"ease of configuration" is "less to manua
On 8/2/07, Andrew Piskorski <[EMAIL PROTECTED]> wrote:
>
> On Thu, Aug 02, 2007 at 11:51:07AM -0400, Nathan Folkman wrote:
> > There was a lot of discussion internally about whether or not to support
> > virtual servers going forward.
>
> Uh, was there some good reason that discussion was not carri
Yes. I most certainly acknowledge ns_pools does not work with virtual
servers. And yes, I certainly acknowledge the pool.tcl file only sets
the server-wide "default" pool.
On Aug 2, 2007, at 12:06 PM, Tom Jackson wrote:
On Thursday 02 August 2007 08:17, Michael Andrews wrote:
I think these
On Thu, Aug 02, 2007 at 11:51:07AM -0400, Nathan Folkman wrote:
> There was a lot of discussion internally about whether or not to support
> virtual servers going forward.
Uh, was there some good reason that discussion was not carried out on
this AOLserver email list? Was there in fact any reason
> There was a lot of discussion internally about whether or not to support
> virtual servers going forward. The main impetus was to try and further
> simplify the code base as much as possible.
You could always take out all serving, that would really simplify it.
Nice community-oriented project y
On Thursday 02 August 2007 08:17, Michael Andrews wrote:
> I think these are all valid concerns and comments. But let's not
> confuse the 2 very separate issues here. :-)
>
> The goal of yesterday's pools.tcl was to set the "default" pool's
> params from the config. This was done so it would be bac
There was a lot of discussion internally about whether or not to support
virtual servers going forward. The main impetus was to try and further
simplify the code base as much as possible. Virtual servers, while useful to
many, add a great deal of complexity to the code.
- n
On 8/2/07, Tom Jackson
Yeah. That seems like a bad oversight. But you could just define a
new pool and register "*" to that pool (The registration takes a
server name).
At any rate - let's make sure this is documented on SourceFroge as a
bug or feature requests.
M
On Aug 2, 2007, at 10:41 AM, Tom Jackson wrot
I think these are all valid concerns and comments. But let's not
confuse the 2 very separate issues here. :-)
The goal of yesterday's pools.tcl was to set the "default" pool's
params from the config. This was done so it would be backward
compatible. This is not in the HEAD. This is a good
On Wednesday 01 August 2007 23:53, [EMAIL PROTECTED] wrote:
> > Maybe this is the intent, although it would be easy to add the
> > server
> > name to the key.
>
> ISTM that virtual servers weren't considered when this code was written ...
>
> All code in current versions should be fully aware of vi
> On 2007.08.01, Michael Andrews <[EMAIL PROTECTED]> wrote:
> I'd love to get AOLserver the point
> where you simply specify maximum and minimum boundaries (which default
> to the hardware's limits) and the server tunes itself based on the
> workload it's receiving.
Besides which, shouldn't decis
> On 2007.08.01, Michael Andrews <[EMAIL PROTECTED]> wrote:
> The natural segue with "most settings changeable at runtime" is a body
> of intelligent code that self-tunes and dynamically heals the server
> (ala Oracle's clusterware, etc.).
Oh, lord. There's a reason people avoid Oracle unless th
> Maybe this is the intent, although it would be easy to add the
> server
> name to the key.
ISTM that virtual servers weren't considered when this code was written ...
All code in current versions should be fully aware of virtual servers.
> If this is the first experiment in how things will go.
17 matches
Mail list logo
