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 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 patch. This is
done.
I explained why this is not true. The new code in pools.c is not
using the
virtual server information to separate threadpools. If you cannot
acknowledge
the difference, or if you are not aware of the difference, this
would be a
good place to start. Your work and mine from yesterday was pretty
much a
complete waste of time due to the bad code in pools.c.
The OTHER issue is the ns_pools command itself. This command is a
Tcl command to create and register pools. It is NEW in 4.5. If there
are bugs/issues with this command - they should be addressed for the
next release or patch.
This is not separate! AOLserver 4.0.10 combined configuration with
registration, just because the AOL team replaced working code with
broken and
separate code doesn't make this a separate issue. The only thing
new in 4.5
is the lack of recognition for virtual servers, how threadpools are
defined,
stored and retrieved is the same.
I am very very very happy to see so much enthusiasm over AOLServer.
The contributions made here have been valuable. Without the
community AOLserver would have been dead 2 years ago. So now we just
need to get a few things in place to facilitate continued
development. 1) We should use the SourceForge site to enter bugs and
feature requests so they are documented. Tom - it would be great if
you could document your findings concerning ns_pools there. 2)
Project owner(s) to determine roadmaps, releases, features, and
schedules. 3) Volunteers to do work, commit code, and lead
discussions. I think we are on the right track for most of this, and
I am sure Dossy has thoughts on it all. :-)
I'll continue to document problems here so everyone knows about
them, not
everyone subscribes to the sucky sourceforge bug tracker. About the
only
thing I can ever figure out from those emails is that someone made
a change,
issue emails are impossible to quickly understand.
Second, you really need to stop asking for volunteers to do work,
we are all
here volunteering to discuss what should be done, which is what
really needs
to be done first. The first thing that should be discussed is some
frank
statements of the situation inside AOL:
* who is working on AOLserver at AOL,
* how much time is assigned for this work,
* any unstated policies or goals which would cause AOL developers
to ignore
the community,
* why AOL thinks this is acceptable behavior for developers,
* if AOL developers should pledge to submit to community goals and
standards
for all public code.
Most long time members of the AOLserver community are well aware of
the
history of AOL employees ignoring us, but this is usually backed up
with
superior code. That has been the one saving grace, now that is gone
and
nobody should be excusing AOL's BS any longer (I'm guilty of it up
through
yesterday, sorry). What is needed is some indication that the AOL
developers
understand the problem (they are 100% responsible for creating),
otherwise we
just have ass covering, there is simply no nicer way of putting it.
tom jackson
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to
<[EMAIL PROTECTED]> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the
Subject: field of your email blank.
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]>
with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject:
field of your email blank.
