(This is related to Jeff's question about monitoring thread status...)
I've added some extra paranoia to WebKit's socket reading code in
ThreadedAppServer.py. The way it was coded before, WebKit could
potentially get into an infinite loop if less data was sent over the socket
from the adapter
At 05:21 PM 10/18/2001 -0400, Jeff Johnson wrote:
>I tried to redirect stdout and stderr to /dev/null but I get the
>following error. (FreeBSD 4.3) What am I doing wrong?
>
>dev5# ./AppServer start > /dev/null 2>&1
>Ambiguous output redirect.
Different shells have slightly different syntaxes f
> I tried to redirect stdout and stderr to /dev/null but I get the
> following error. (FreeBSD 4.3) What am I doing wrong?
>
> dev5# ./AppServer start > /dev/null 2>&1
> Ambiguous output redirect.
does:
./AppServer start > /dev/null 2> /dev/null
fail as well?
jack.
I tried to redirect stdout and stderr to /dev/null but I get the
following error. (FreeBSD 4.3) What am I doing wrong?
dev5# ./AppServer start > /dev/null 2>&1
Ambiguous output redirect.
___
Webware-devel mailing list
[EMAIL PROTECTED]
https://lists.
> Most of these ideas could be implemented, but they aren't there
> currently. The one thing I don't see how we could do would
> be to stop
> threads that are taking too long. I think there's no way to
> kill a running
> thread in Python, at least not portably. (And even if you
> could do
> I think there's no way to kill a running
> thread in Python, at least not portably. (And even if you could do so, it
> would leave the whole process in an unstable state. The docs on the Win32
> functions for killing threads warn you to do it only as a last resort as it
> makes the whole p
At 01:49 PM 10/17/01 -0400, Jeff Johnson wrote:
>Could webkit monitor the number of live servlet threads and if they die,
>create new threads? Is there a way to stop threads that are taking too
>long? Is there a way already to find out how many threads are healthy?
Most of these ideas could be
> Can you update
> your copy of ThreadedAppServer.py from CVS and verify that it
> fixes the problem?
Yep, it works great, thanks.
___
Webware-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/webware-devel
At 01:26 AM 10/18/2001 -0500, Ian Bicking wrote:
>If you turned off caching (I'm not sure how this would work in MK),
>and you used the ad-hoc-foreign-key trick, would MK work with stock
>schemas and with multiple (non-MK) clients?
Yes.
Note that what is returned from store.fetchObjectsOfClass()
At 04:51 PM 10/18/2001 -0400, Geoff Talvola wrote:
>I've checked into CVS the changes you suggested -- I added the setsockopt
>call, moved up the initialization of self.threadCount and
>self.threadUseCounter, and removed the annoying print ".". Can you update
>your copy of ThreadedAppServer.py
I've checked into CVS the changes you suggested -- I added the setsockopt
call, moved up the initialization of self.threadCount and
self.threadUseCounter, and removed the annoying print ".". Can you update
your copy of ThreadedAppServer.py from CVS and verify that it fixes the
problem?
I can
To fix the bind error, in ThreadedAppServer.__init__:
Change:
self.mainsocket = socket.socket(socket.AF_INET,
socket.SOCK_STREAM)
To:
self.mainsocket = socket.socket(socket.AF_INET,
socket.SOCK_STREAM)
self.mainsocket.setsockopt(socket.SOL_SOCKET,socket.SO_
I did some more experimenting and found the problem with quick restarts
and port bind errors! But not the solution :)
The printing of a "." may lessen the chances of this or have nothing to
do with it.
The real problem is in the following:
dev5# netstat | grep 8092
tcp4 0 0 localhos
13 matches
Mail list logo