Hi Eric, Eric,
take a look at:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/aolserver/aolserver/nsd/encoding.c
encoding.c is new in AOLserver 4.0. There seems to be no downloadable
4.0 (beta) version at the moment/anymore but you can browse the CVS
repository.
The patches from Rob Mayoff
How exactly does PHP run under AOLserver? I understand it can run as a
module instead of just CGI, but does anyone know the gory details? Is
there a PHP engine loaded per thread? Is it pre-loaded or is it loaded
when a PHP script is hit?
(should this be directed to the php-dev list?)
--
Gabriel
On Friday, October 18, 2002, at 11:39 AM, Psycho Tux wrote:
[18/Oct/2002:17:27:51][1480.1024][-main-] Error: nscp:
could not listen on 127.0.0.1:
[18/Oct/2002:17:27:51][1480.1024][-main-] Error:
modload: failed to load '/usr/local/aolserver/bin/n
scp.so': 'Ns_ModuleInit' returned -1
I think that modules should not issue fatal errors and terminate the
server unless the module determines that the error it has encountered will
absolutely prevent correct operation of any part of the server. For
example, the current nscp module will terminate the server with a fatal
error if it
Perhaps something else is already using that port?
Psycho Tux wrote:
Hi all,
please help me, please share your knowledge with me! I
started nsd whit the command ./nsd -u nsadmin -g
nsadmin -t config, then i had these errors in my log
[18/Oct/2002:17:27:51][1480.1024][-main-] Notice:
nsmain:
Personally, I like hard failures.
If I configure a database in my nsd.tcl, it seems obvious that I want
a database. If the server starts anyway without one, then instead of
having an immediate, obvious error to handle, I have a subtle one. I
go to my home page, and the page comes back, so I
I agree with Jim's position. If the module isn't working or can't get
what it needs to run, a hard failure will force you to work out the
problem instead of assuming that all the parts were working fine. If the
server continued to roll, you'd really have to test all your modules (by
connecting to
Exactly... If I load a module, I intend for that module to work... if it
doesn't work there is a problem that needs to be eliminated...
- Original Message -
From: Scott S. Goodwin [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, October 18, 2002 11:12 AM
Subject: Re: [AOLSERVER]
One of the reasons I raised this point is that, today, modules are wildly
inconsistent about fataling. If the nssock module fails to load or to
listen, the server continues, ever hopeful; if the nscp module fails, on
the other hand, it's going down and it's not going alone! Between the two,
I
On 2002.10.18, Peter M. Jansson [EMAIL PROTECTED] wrote:
I think that modules should not issue fatal errors and terminate the
server [...]
Anybody have any feelings one way or the other?
What business does someone have putting a server into production use if
its got modules that aren't
On 2002.10.18, Peter M. Jansson [EMAIL PROTECTED] wrote:
One of the reasons I raised this point is that, today, modules are wildly
inconsistent about fataling. If the nssock module fails to load or to
listen, the server continues, ever hopeful; if the nscp module fails, on
the other hand,
On Friday, October 18, 2002, at 02:37 PM, Jim Wilcoxson wrote:
What is the point of having the DB module load, if it can't connect to
the DB server?
I use the external database driver interface to wire up AOLservers to
things that aren't really databases, so I can take advantage of pooling.
On 2002.10.18, Jim Wilcoxson [EMAIL PROTECTED] wrote:
What is the point of having the DB module load, if it can't connect to
the DB server?
While I personally agree with you, the point (I think) that Pete is
making is that for DB modules, this behavior should be up to the admin's
control.
If
On 2002.10.18, Peter M. Jansson [EMAIL PROTECTED] wrote:
I'm not saying you can't make your server fail hard, I'm saying that the
driver author should be the one to make the call.
I see what you're literally saying, but are you saying what you mean?
I think you meant to say that the driver
On Friday, October 18, 2002, at 02:50 PM, Dossy wrote:
On 2002.10.18, Peter M. Jansson [EMAIL PROTECTED] wrote:
I'm not saying you can't make your server fail hard, I'm saying that the
driver author should be the one to make the call.
I see what you're literally saying, but are you saying
Ok, this makes sense to me. You're right, when your server has to rely
on other servers out there being up at startup time, some of which you
may not have direct control of, then the ability to move on and retry
the connect later is a good idea, and I think that kind of thing
shouldn't have to be
This is the kind of inconsistency I am working to fix, across all of the
modules. Not sure adding a default handler is the right way to go; the
80% case is for a straight failure. nssock, in my opinion, should fail
if it can't bind to a port. Adding a default handler will add some
complexity that
17 matches
Mail list logo
