GUI widget web2py server

[annet]

When I do 'stop server' and 'start server' in the GUI widget, the
server doesn't start, and I get this error:

web2py Enterprise Web Framework
Created by Massimo Di Pierro, Copyright 2007-2010
Version 1.87.3 (2010-10-13 19:44:46)
Database drivers available: SQLite3, PostgreSQL
Starting hardcron...
please visit:
http://127.0.0.1:8000
starting browser...in 5 seconds
TkMacOSXDoHLEvent failed : cppe 1 ,kHighLevelEvent
61657674 0000 tvea,-1708
please visit:
http://127.0.0.1:8000
starting browser...in 5 seconds
ERROR:Rocket.Errors.ThreadPool:Socket 127.0.0.1:8000 in use by other
process and it won't share.
CRITICAL:Rocket.Errors.ThreadPool:No interfaces to listen
on...closing.
TkMacOSXDoHLEvent failed : cppe 1 ,kHighLevelEvent
61657674 0000 tvea,-1708



Kind regards,

Annet.

[Adi]

web2py is already running somewhere else. Kill all web2py processes,
and start a fresh one.

[ron_m]

If you move too quick between pushing the stop button and hitting
start you can get the error because the server hasn't completed the
shutdown yet. I always wait a second between button presses.

[mart]

This is on Mac OS? I get this all the time. I see 3 things that cause
this for me (well, 4 including Ron's comment on being too quick on the
click ;) so that one was 1)

2) the socket/rocket exception I get regularly enough when i try to
open a page with "unforgivable" errors (all of which are mine)

3) I work from home, and prefer to work/play on my mac laptop over
anything else... so I do spend what my wife describes as a 'stupid
amount of my time/life on the laptop),so with all that woth my head
down, typing away, i did get a chance to come to a few conclusions
here: Order is everything. Port 8000 is most certainly used by number
of applications / or there back end secret features. Two applications
which for me are running almost 24/7 are the 2 which act the most like
an old married couple (love/hate/love/hate,etc). These are Web2Py and
Aptana (obviously, eclipse will at times behave as rudely as its
sibling, aptana) where Mac OS + web2py will the first to hit a wall
and crash after a tiff with aptana (and that's if I succeed in making
web2py run without having killed aptana first. So, for me: launch
web2py, then aptana..in that order, always.

4) I removed TKinter, so it bypasses the auto launch of mozilla and
the running of that server dialog. I dd notice some hanging there off
an on... and I'm not patient.

ok, a fifth reason 5) you may think it lame, but I do put much if the
blame on the RAM - have had to reset the PMU on quite a few
occasions. Flawed RAM is one of these "known occurences" at apple
(along with the suddenly not functioning wired net port), and
typically, they don't shy away from owning the issue when confronting
them and will without blinking change the sticks for you (provided you
are still covered by apple care, if not, they may start giggling ;).
TIP: if the number of times this happens increases and regularly, and
if you do start to suspect the RAM, and are not covered, then I
suggest, keep and see if you can buy minimal coverage, then complain
and have them change it :)

[annet]

Yes, this is on Mac OS X, both Leopard and Leopard Server. I am glad
it's not just me experiencing these problems.

Annet.

[mdipierro]

I am teaching a class on Advanced network programming in C?? (nothing
web2py related) and students are reporting to me that Mac OSX takes a
long time to release a port after the program creating the socket has
been killed or crashed. The delay seems to be as large as one minute.
During this time the socket cannot be used again.

It is a OSX weirdness.

Massimo

[ron_m]

Is this the cause of the slow close and the underlying purpose for it?

http://www.freesoft.org/CIE/RFC/1323/24.htm

I believe most systems allow this timer to be adjusted by registry in
Windows and /proc in Linux, not sure on Mac

If the server does the bind call with SO_REUSEADDR for the listen port
it should be able to get back on without waiting for the TIME-WAIT
period.

http://www.unixguide.net/network/socketfaq/4.11.shtml

So those are the parts of the behaviour I would expect to cause a
socket busy when there are no listeners. However what you describe
seems to be beyond the normal timers. A socket can take a very long
time to close if the remote system just crashes and never gets a
chance to send a FIN to the peer.

I am probably stating the obvious, used to do a lot of network
programming about 10 years ago.

[Jonathan Lundell]

On Oct 23, 2010, at 7:54 AM, mdipierro wrote:
>
> I am teaching a class on Advanced network programming in C?? (nothing
> web2py related) and students are reporting to me that Mac OSX takes a
> long time to release a port after the program creating the socket has
> been killed or crashed. The delay seems to be as large as one minute.
> During this time the socket cannot be used again.
>
> It is a OSX weirdness.

This list is useful for all kinds of problems...

> This is quite common. Depending on how the socket it closed, the corresponding TCP connection can enter the TIME_WAIT state, which will keep the port busy for 2 minutes.
>
> <http://www.unixguide.net/network/socketfaq/2.7.shtml>
>
> A server would usually set SO_REUSEADDR to avoid this delay.
>
> <http://www.unixguide.net/network/socketfaq/4.5.shtml>

[Michele Comitini]

On some systems I experimented you can "wake up" the port in TIME_WAIT
state by trying to open a connection to it (i.e. by telnet localhost
80)

2010/10/23 Jonathan Lundell <jlun...@pobox.com>: