Please watch the vulgar language - there's simply no need for it.
And precisely who are you to say so?
--
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
I'm someone who can, and will, remove your subscription from this list.
Thank you for making clear, absolutely clear, that AOLserver is not a
community-based open source project.
You're doing everyone a favor.
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply
I'm someone who can, and will, remove your subscription from this list.
- n
On 8/3/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Please watch the vulgar language - there's simply no need for it.
And precisely who are you to say so?
--
AOLserver - http://www.aolserver.com/
To Remove
AOLserver is going to become even easier to set up and configure.
Yeah, right...
--
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
[EMAIL PROTECTED] wrote:
On Aug 3, 2007, at 9:39 AM, [EMAIL PROTECTED] wrote:
Please watch the vulgar language - there's simply no need for it.
And precisely who are you to say so?
A member of the community. I'll repeat what he said: please stop
swearing at and insulting people.
Tom
Nathan,
This has to be the most bizzar change to the configuration setup for
AOLserver, is it really true? Now you have to execute commands inside the
config file to set this?
Since some have called for examples, would it be possible for the author of
these changes to provide a few. I have
On 2007.08.02, Tom Jackson [EMAIL PROTECTED] wrote:
Should I step down as project
leader and let someone else take over? The irony is that the title
really doesn't mean much at all.
I suspect that you simply don't understand what it means in the context of
a community-based open source
On Aug 3, 2007, at 3:39 PM, [EMAIL PROTECTED] wrote:
Please watch the vulgar language - there's simply no need for it.
And precisely who are you to say so?
He's someone who is trying to keep the discussion civil and
productive, and trying to be helpful.
Really, I think it's best to
Please, dhogaza, stop.
And, everyone else, please don't feed the troll.
Thanks,
Juan José
--
Juan José del Río
Simple Option / Atención al cliente y soporte técnico
Oficina: 0034 951 930 122
Móvil: 0034 616 512 340
Fax: 0034 952 792 455
[EMAIL PROTECTED]
http://www.simpleoption.com
On Fri,
On 2007.08.03, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Personally I think the proper resolution here is for the AOL team to admit
that this is a private project where they retain the right to do anything
with the public open source code.
Dossy no longer works for AOL, so I think the
Personally I think the proper resolution here is for the AOL team to admit
that this is a private project where they retain the right to do anything
with the public open source code.
Dossy no longer works for AOL, so I think the group is more like those
who've been contributing in the recent
So I guess this pretty much seals the deal we have kings in charge of the code
and kings in charge of our speech.
The only person who called anyone anything was Dossy, who called me a griefer,
based upon his definition of contribution and his perception that he's done
much more of it than I
I'm someone who can, and will, remove your subscription from this list.
Oh, that will earn you brownie points.
--
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
On 2007.08.03, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
I used the phrase I f* up, which in my part of the world, at least,
isn't considered swearing nor vulgar. I was simply suggesting Dossy
admit he made a mistake, and move on.
I thought I did this. Matter of fact, I did this while
On 2007.08.03, Tom Jackson [EMAIL PROTECTED] wrote:
The only person who called anyone anything was Dossy, who called me a
griefer, based upon his definition of contribution and his perception
that he's done much more of it than I have.
Sorry, I shouldn't have used a word that doesn't have a
The reason why I reach out to organizations privately is because some of
them are building commercial products on top of AOLserver and may not be
comfortable discussing their needs in a public forum.
Well, the way we handle such situations in the openacs community is that
changes go through an
On 8/3/07, Dossy Shiobara [EMAIL PROTECTED] wrote:
The reason why I reach out to organizations privately is because some of
them are building commercial products on top of AOLserver and may not be
comfortable discussing their needs in a public forum. However, I
recognize the value in
We actually also tried a similar process a few years ago, but it failed due
to various conflicts and general lack of interest. Would be great to get
something like that going again.
- n
On 8/3/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
The reason why I reach out to organizations privately
We actually also tried a similar process a few years ago, but it failed
due
to various conflicts and general lack of interest. Would be great to get
something like that going again.
Well, as I said in that note, I think the community's too small warrant
the formalism.
But the principle of
Dossy,
Like I said you are the only one making statements about personal qualities.
Others have asked you to simply admit you made a mistake. But if you re-read
my initial emails, I was focused on fixing the problem. I spent a number of
hours researching the issue and writing code. I ran
Hi,
I think it's a fine idea that conn thread pools are a process-wide
resource. I liked the idea so much, I copied it. (Well, the limits
part, so far...)
But I agree with you; although ns_pools/ns_limits enable some handy
new features, such as dynamic configuration, it sure would be
convenient
Stephen,
My concern over this is that one virtual server might have slightly different
code, for instance development vs. production, and would likely share the
same threadpool. What exactly is part of the thread in a pool? Is there any
remaining code or data from one use to another, or is
On 8/3/07, Tom Jackson [EMAIL PROTECTED] wrote:
Stephen,
My concern over this is that one virtual server might have slightly different
code, for instance development vs. production, and would likely share the
same threadpool. What exactly is part of the thread in a pool? Is there any
Stephen,
I agree that you have clearly defined one use of threadpools, essentially
overall limits. But note that threadpools are tied to url patterns. The
concept is that certain urls consume more resources that others, not just
memory, but processor time. Other urls consume few resources,
On 8/4/07, Tom Jackson [EMAIL PROTECTED] wrote:
Stephen,
I agree that you have clearly defined one use of threadpools, essentially
overall limits. But note that threadpools are tied to url patterns. The
concept is that certain urls consume more resources that others, not just
memory, but
Michael,
I have just provided you with information which shows that even this is not
functioning correctly. If you have multiple virtual servers, whichever one
runs the pools.tcl file last will set the default pool parameters, and there
is only one 'default' pool in a single nsd process, no
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 they
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...
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 decisions
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 virtual
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
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
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
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
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
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
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 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 manually tune
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
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 tune
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 with
Better I think to add them (commented out if need be) the default
config file that ships with 4.5. I searched the documentation and
couldn't find any mention of the new setup (until someone pointed it
out) but plenty of talk about the old ones. I think it's in the
release notes, but nobody reads
You are absolutely correct. Lack of documentation continues to be one of the
biggest issues with this project in my opinion. Not sure how best to resolve
this at this point to be completely honest. Would be a great start if other
folks would start contributing to the example configuration files
We should stay away from running commands in the cfg - the server has
not fully started and the main thread is not initialized yet.
I think the best way to manage this change is to run the ns_pools
set default command from the init.tcl and use the cfg params. That
makes it backwards
Yes and no. ;)
Technically everything in the configuration file is a Tcl command
(ns_section, ns_param, etc.) so it's really not that much of a stretch. But
I agree, it is different.
Here's the deal, a decision was made a while back to try some new things
with AOLserver 4.5, some of which we
Nathan,
This has to be the most bizzar change to the configuration setup for
AOLserver, is it really true? Now you have to execute commands inside the
config file to set this?
This is absolutely crazy. The init file has never required dynamic
execution of procs to work, and to have
I think lack of process is a big deterrent. How do changes get
rolled into releases, what are the coding standards, is there a
review process, etc.
On Aug 1, 2007, at 10:29 AM, Nathan Folkman wrote:
You are absolutely correct. Lack of documentation continues to be
one of the biggest
You are absolutely correct. Lack of documentation continues to be one of
the
biggest issues with this project in my opinion. Not sure how best to
resolve
this at this point to be completely honest. Would be a great start if
other
folks would start contributing to the example configuration
I think the best way to manage this change is to run the ns_pools
set default command from the init.tcl and use the cfg params. That
makes it backwards compatible.
If folks agree - I can add that to the head today.
Sounds reasonable to this hacker.
--
AOLserver - http://www.aolserver.com/
Technically everything in the configuration file is a Tcl command
(ns_section, ns_param, etc.) so it's really not that much of a stretch.
But
I agree, it is different.
Technically, the configuration file is a bucket of bits, but that's not a
very useful observation.
Had we ever actually
Yep, the documentationn or lack there of, continues to dog us. Did you
read the release notes at least? It doesn't specifically mention this
incompatibility, but does contain a lot of useful information.
On 8/1/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
You are absolutely correct. Lack of
What about just contributing documentation? What is making that hard?
On 8/1/07, Michael Andrews [EMAIL PROTECTED] wrote:
I think lack of process is a big deterrent. How do changes get
rolled into releases, what are the coding standards, is there a
review process, etc.
On Aug 1, 2007,
As I said before, if you have issues with the changes made in 4.5,
simply do not upgrade. There were a number of factors that led to our
decision to release as we did, when we did. Unfortunately a lot of the
backwards compatibility work never got completed. Sorry.
On 8/1/07, [EMAIL PROTECTED]
The idea of thread pools and allowing the dynamic changing of pool
settings is a great addition to the code base. The failures here
were 1) communication, 2) backward compatibility of the config settings.
I have no disagreement with this, at all.
As Nathan and I pointed out - it would not
Simple answer - don't upgrade to 4.5. As I was trying to explain
before, we knew some things in 4.5 would not be backwards compatible.
On 8/1/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Nathan,
This has to be the most bizzar change to the configuration setup for
AOLserver, is it
I'm currently away on vacation this week (in Ocean City, MD) and writing long
emails on the Treo isn't exactly fun, so I'll keep this short:
1. It's my fault that 4.5 has the pools/limits functionality. I didn't do a
good enough job communicating to everyone about the change. I haven't done a
@LISTSERV.AOL.COM
Subject: Re: [AOLSERVER] configured minthreads, maxthreads doesnt show
up with [ns_server threads] command
Technically everything in the configuration file is a Tcl command
(ns_section, ns_param, etc.) so it's really not that much of a
stretch.
But
I agree, it is different.
Technically
I would just like to point out that 4.5 was released over one year ago, so the
cat is already out of the bag.
But more important: it seems like this is not really a problem. The old
configuration can still be used. All we need is a script which reads the
configuration data and runs the new
Discussion [mailto:[EMAIL PROTECTED] On Behalf
Of Nathan Folkman
Sent: Wednesday, August 01, 2007 9:24 AM
To: AOLSERVER@LISTSERV.AOL.COM
Subject: Re: [AOLSERVER] configured minthreads, maxthreads doesnt show
up with [ns_server threads] command
Simple answer - don't upgrade to 4.5. As I was trying
you --
-- ReC
-Original Message-
From: Rick Cobb
Sent: Wednesday, August 01, 2007 10:04 AM
To: 'AOLserver Discussion'
Subject: RE: [AOLSERVER] configured minthreads, maxthreads doesnt show
up with [ns_server threads] command
I mostly sympathize with your sentiments. Incompatible changes
: [AOLSERVER] configured minthreads, maxthreads doesnt show
up with [ns_server threads] command
Technically everything in the configuration file is a Tcl command
(ns_section, ns_param, etc.) so it's really not that much of a
stretch.
But
I agree, it is different.
Technically
-- but
with community feedback.
-- ReC
-Original Message-
From: AOLserver Discussion [mailto:[EMAIL PROTECTED] On Behalf
Of [EMAIL PROTECTED]
Sent: Wednesday, August 01, 2007 8:57 AM
To: AOLSERVER@LISTSERV.AOL.COM
Subject: Re: [AOLSERVER] configured minthreads, maxthreads doesnt show
Bingo - Michael Andrews just contributed such a script.
- n
On 8/1/07, Tom Jackson [EMAIL PROTECTED] wrote:
I would just like to point out that 4.5 was released over one year ago, so
the
cat is already out of the bag.
But more important: it seems like this is not really a problem. The old
see the file modules/tcl/pools.tcl. It has been added to the HEAD. I
will let Dossy and Nate decide how this should be tagged.
Michael
On Aug 1, 2007, at 1:50 PM, Nathan Folkman wrote:
Bingo - Michael Andrews just contributed such a script.
- n
On 8/1/07, Tom Jackson [EMAIL PROTECTED]
I have added additional code for handling the old style (not too old)
which allows you to set up threadpools for specific methods + url patterns.
Also, I think there is a bug in the new pools.tcl file. The original
maxconnections parameter was
changed to maxconns, can anyone verify that the
Awesome! Thanks! :)
- n
On 8/1/07, Tom Jackson [EMAIL PROTECTED] wrote:
I have added additional code for handling the old style (not too old)
which allows you to set up threadpools for specific methods + url
patterns.
Also, I think there is a bug in the new pools.tcl file. The original
Dossy,
Sounds like a great goal, but there are still other considerations:
1. Even if the server tunes itself, it needs to start somewhere
2. Hard coding defaults already makes it difficult to figure out what the
settings are because usually the programmers don't update the config 'data
To clarify - The pools.tcl file I wrote serves ONE purpose. To set
the default pool's params to what is in the server config. This
was ONLY done because folks expected the default pool to be set at
start up using the config params... as it was in 4.0.10.
My opinion is that any OTHER pools
My opinion is that any OTHER pools should be created and managed by
Tcl Modules and or Tcl Packages, not the server config.
So backwards compatibility with virtual servers disappears, then.
One of the hallmarks of AOLserver has always been ease of configuration.
My sense is that we're
Probably would be that difficult, although honestly not a priority for
anyone here. Have at it! ;)
- n
On 7/30/07, Jeff Rogers [EMAIL PROTECTED] wrote:
Nathan Folkman wrote:
Those parameters moved and are now controlled via the ns_pools Tcl
command:
This issue keeps coming up. How hard
Nathan Folkman wrote:
Those parameters moved and are now controlled via the ns_pools Tcl
command:
This issue keeps coming up. How hard would it be to add in (for the
next point release) compatibility code in init.tcl to parse the
old-style parameters?
-J
--
AOLserver -
What version of AOLserver are you running?
On 7/26/07, Shedi Shedi [EMAIL PROTECTED] wrote:
Hi
Patform: suse 10.1 (2.6.16.21-0.25-default)
I have configured my nsd config.tcl as below:
ns_param maxconnections 100 ;# Max connections to put on queue
ns_param maxdropped 0
Those parameters moved and are now controlled via the ns_pools Tcl
command:
ns_pools:
The ns_pools command enables configuration of one or more
pools of connection processing threads. The pools allow
certain requests to be handled by specific threads. This
could,
Thanks Nathan for the info. I'm trying to configure a pool but ns_server
threads procmsgmgr returns error on server log.
[26/Jul/2007:18:06:07][4968.3074280352][-conn:0-] Error: Tcl exception:
no such pool: procmsgmgr
while executing
ns_server threads procmsgmgr
#
ns_section
Its 4.5.0
On 7/26/07, Nathan Folkman [EMAIL PROTECTED] wrote:
What version of AOLserver are you running?
On 7/26/07, Shedi Shedi [EMAIL PROTECTED] wrote:
Hi
Patform: suse 10.1 (2.6.16.21-0.25-default)
I have configured my nsd config.tcl as below:
ns_param maxconnections 100
You'd actually want to do it by adding the following to the end of your
configuration file:
ns_pools set procsmsgmgr -maxconns 100 -maxthreads 20 -minthreads 10
-timeout 10
ns_pools register procsmsgmgr server1 POST /proc/msgmgr
You can then verify that everything worked via the
76 matches
Mail list logo
