perl-asp mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Chamas <>
Subject Re: Apache::ASP locking up
Date Mon, 22 Nov 2004 07:59:00 GMT
Hi Warren,

At this point, I would recommend setting Debug -1 and then
stop/start apache, and send me error_log from start until freeze.
Then stop apache, and get me a tar/gzip copy of the directory /tmp/asp
*unless* there is sensitive data in the data structures in
which case you should not be sending me that.

It may be something that is being stored in $Session or $Application
that is killing things, and is only specific to that DBM format.

Also, if all this debugging is just taking too long, then you
might do something like this just for this one server:

# httpd.conf
   use Apache::ASP::StateManager;
   $Apache::ASP::State::DefaultStateDB = 'DB_File';
PerlSetVar StateDB DB_File
# end httpd.conf

By default Apache::ASP uses SDBM_File for the internal database
storage.  You can also try the new PerlSetVar without the <Perl>
block.  You can also try GDBM_File without using DB_File, either
way as you may only have one or the other installed on your system.

Note these things in <Perl> blocks in not officially supported,
but this is a worst case scenario where SDBM_File just isn't working
for you for the internal database, and I think this should work to
override it.  Note also, if you use the <Perl> method, you need
to delete the /tmp/asp directory between changing the DefaultStateDB
setting, as Apache::ASP is not used to this being changed at runtime,
its a hard coded global in the code.



Warren Young wrote:
> Josh Chamas wrote:
>> What is the state of the system when it locks up?
> These systems are installed in schools, so they're only being used from 
> roughly 7am to 4pm.  This problem is happening within that window, while 
> it is being used during the day.  We have never seen it lock up in this 
> way over night.
>> Is the machine under load
> To the extent that 5500 hits per day is "load", yes.  :)
> There seems to be a loose correlation between the problem and load: this 
> site is one of the heaviest users.  We have heavier users, though, that 
> aren't seeing the problem.
>> is a process spinning out of control, 
> We don't notice a busied out CPU, if that's what you mean.  And, I 
> wouldn't think anything is truly deadlocked, since all it takes is 
> removing the ASP state directory to fix the problem.
>> is there any errors in the error_log that look interesting?  
> No, but then we send a lot of stuff to error_log ourselves.  And, we 
> don't have Debug turned up.  Should we?
>> Does restarting the web server help things without removing the /tmp/asp
>> entirely, 
> No.
>> or is removing that directory the only fix?  
> Yes.
>> If the details
>> you provided about /tmp/asp are before removing but after a freeze,
>> then I would say there is nothing that looks out of the ordinary there
>> that would raise concern on my side.
> Hmmm...  Would having the files help?
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message