RE: [Webware-devel] print "." in ThreadedAppServer

> On Wednesday October 17, 2001 06:04 am, Chuck Esterbrook wrote:
> > In ThreadedAppServer, this little period is getting on my nerves:
It was such a hack that I was surprised it made it into CVS (happy
though). I would rather understand what is going on and fix the real
problem but I ran out of time. This may be a *nix issue and not just
FreeBSD.
> > Two questions:
> >
> > * Is there a good way to detect FreeBSD so we can reserve=20
> this for that
> > platform?
If this is a *nix problem, we could limit the hack to non "nt" systems
(posix?). In a week or two I should be able to spend some real time on
finding out why the print is needed.
> > * Also, on FreeBSD does sys.stdout.flush() in place of the=20
> > print "." also fix the problem?
I tried using flush but it didn't solve the problem.
> Or, it could be made a config setting, so we're covered when=20
> the same problem=20
> shows up on another OS. While we're at it, we ought to add a=20
> config setting=20
> to suck up stdout and stderr to avoid the _other_ FreeBSD=20
> problem Jeff=20
> reported.
Sounds good, though if daemon mode is selected, it should probably run
silent by default.
Jeff

Thread view

> On Wednesday October 17, 2001 06:04 am, Chuck Esterbrook wrote:
> > In ThreadedAppServer, this little period is getting on my nerves:
It was such a hack that I was surprised it made it into CVS (happy
though). I would rather understand what is going on and fix the real
problem but I ran out of time. This may be a *nix issue and not just
FreeBSD.
> > Two questions:
> >
> > * Is there a good way to detect FreeBSD so we can reserve=20
> this for that
> > platform?
If this is a *nix problem, we could limit the hack to non "nt" systems
(posix?). In a week or two I should be able to spend some real time on
finding out why the print is needed.
> > * Also, on FreeBSD does sys.stdout.flush() in place of the=20
> > print "." also fix the problem?
I tried using flush but it didn't solve the problem.
> Or, it could be made a config setting, so we're covered when=20
> the same problem=20
> shows up on another OS. While we're at it, we ought to add a=20
> config setting=20
> to suck up stdout and stderr to avoid the _other_ FreeBSD=20
> problem Jeff=20
> reported.
Sounds good, though if daemon mode is selected, it should probably run
silent by default.
Jeff

> Geoffrey Talvola <gtalvola@...> wrote:
> > Or, it could be made a config setting, so we're covered when the
> > same problem shows up on another OS. While we're at it, we ought to
> > add a config setting to suck up stdout and stderr to avoid the
> > _other_ FreeBSD problem Jeff reported.
>=20
> The possibility should also be considered that this isn't a FreeBSD
> problem, but a problem of running Webware in daemon mode, under normal
> production conditions.
> Jeff may very well be the only person doing that under significant
> load. I've been running Webware as a daemon happily under Linux, but
> only with insignificant load.
Are you closing the console that started the daemon? If so, are you
redirecting output to /dev/null?
The print "." fixed the problem where the socket took 30 seconds to
after shutdown before the port could bind again. No load required, I
just start, stop, attempt restart which would fail with a socket bind
error. Not even in daemon mode.
The other error isn't Webware, just normal Python, printing to
sys.stdout (just a file) raises an exception when the console is closed
and the file is no longer valid. That can be reproduced with the simple
python program below. Maybe different *nixes will behave differently.
import time, traceback
def w(s):
f =3D open("x.txt","a")
f.write(s)
f.close()
def wtrace():
f =3D open("x.txt",'a')
traceback.print_exc(file=3Df)
f.write("\n")
f.close()
if __name__ =3D=3D '__main__':
while 1:
w("\n")
for x in range(1023,1026):
s =3D "X" * x
w("about to write %d bytes.\n" % x)
try:
print s
except:
w("ERROR")
wtrace()
time.sleep(5)=09
=09

"Jeff Johnson" <jeff@...> wrote:
> The print "." fixed the problem where the socket took 30 seconds to
> after shutdown before the port could bind again. No load required, I
> just start, stop, attempt restart which would fail with a socket bind
> error. Not even in daemon mode.
You're right, I did get this in Webware when I did a quick
start/restart... it was more around less than 4-5 seconds, though it
was unpredictable.
OTOH, on another box where I have a daemon script, I put in this code
for shutdown:
stop)
echo -n "Shutting down WebKit: "
kill -s 2 `cat $PID_FILE`
for SUBPID in `ps aux --cols 200 | grep 'python Launch.py' | awk
'{print $2}'` ; do
kill -s 2 $SUBPID > /dev/null 2>&1
done
success "Shutting down WebKit"
echo
;;
and I haven't had any problem. Otherwise it simply wasn't killing all
the processes, or threads, or whatever they were. There's actually
only one of the "python Launcy.py" processes that needed to be killed
(after which all of the others were killed)... but it wasn't happening
before I did this.
I typically restart this daemon rather quick (just webkit restart,
which takes around 2 seconds maybe), and haven't had a problem since I
changed this.
Ian

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 localhost.8092 localhost.4213
TIME_WAIT
tcp4 0 0 localhost.4212 localhost.8092
TIME_WAIT
tcp4 0 0 localhost.8092 *.*
LISTEN
tcp4 0 0 localhost.4209 localhost.8092
TIME_WAIT
tcp4 0 0 localhost.4207 localhost.8092
TIME_WAIT
I refreshed a browser page a few times to create those sockets. The
only one that will cause a bind problem on restart is this one:
tcp4 0 0 localhost.8092 localhost.4213
TIME_WAIT
For some reason, webkit owns the connection to the adaptor instead of
the other way around (notice which side the 8092 is on). I use 8092
instead of the default 8086 for this instance of webkit..
So, to fix the problem we need to figure out why this socket is
backwards. Any ideas?
Jeff