Startup/shutdown anecdote

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Startup/shutdown anecdote

Schwab,Wilhelm K
I just had an experience that fuels my session manager fire.  I loaded Pharo, and it was totally unresponsive.  Why?  I can't be absolutely certain, but here's my story: last night, I had an open connection to a system visible only with a vpn.  With the vpn not in use, either Pharo (or more likely ODBC) went nuts because it could not find the server, and I finally killed the process, started the vpn, and all was well on the next startup.  IMHO, hanging like that is one of the worst things software can do, and I think we can do a lot to fix it with a few simple changes.

Linux ODBC is probably partly to blame, but it should not have been invoked so early in statup.  Someone recently argued against lazy connections, but this would not have happened if they were part of the design.  The image would have become helpless once I did something that triggered database activity, but that is where overlapped calls enter the picture.  Even without the, at least I would have been able to use the image.  Note that if I had taken the offending image to another machine, it could have been useless - not good.

Bill


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Startup/shutdown anecdote

Mariano Martinez Peck


On Tue, Sep 15, 2009 at 1:55 PM, Schwab,Wilhelm K <[hidden email]> wrote:
I just had an experience that fuels my session manager fire.  I loaded Pharo, and it was totally unresponsive.  Why?  I can't be absolutely certain, but here's my story: last night, I had an open connection to a system visible only with a vpn.  With the vpn not in use, either Pharo (or more likely ODBC) went nuts because it could not find the server, and I finally killed the process, started the vpn, and all was well on the next startup.  IMHO, hanging like that is one of the worst things software can do, and I think we can do a lot to fix it with a few simple changes.

Linux ODBC is probably partly to blame, but it should not have been invoked so early in statup.  Someone recently argued against lazy connections, but this would not have happened if they were part of the design.  The image would have become helpless once I did something that triggered database activity, but that is where overlapped calls enter the picture.  Even without the, at least I would have been able to use the image.  Note that if I had taken the offending image to another machine, it could have been useless - not good.


I don't know if I understood you. What does your ODBc drivers do on startup ? did you put some object in the startup/shutdown list ?

best

Mariano
 
Bill


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Startup/shutdown anecdote

Schwab,Wilhelm K
Mariano,
 
I did not have to put anything in the startup/shutdown lists.  In keeping with the state of the art in Squeak/Pharo, the ODBC package breaks and reconnects everything across snapshots vs. on shutdown and true starts.  Add to that a pre-production vpn (University's fault) and a particularly stubborn odbc driver[*], and Pharo came to a grinding hault.  There was no way to tell it to back off on the Sisyphean task.  Still being on that machine, I restarted the vpn, loaded the image, and save it again, but a change to session managment would skip the hassle.
 
Bill
 
 
 
[*] I assume that is the problem at least.  It had no hope of finding the server, and appeared not to recognize same and report it as an error.  Ubuntu informed me that the vm was waiting on a connecting socket, so it fits.
 


From: [hidden email] [mailto:[hidden email]] On Behalf Of Mariano Martinez Peck
Sent: Tuesday, September 15, 2009 1:52 PM
To: [hidden email]
Subject: Re: [Pharo-project] Startup/shutdown anecdote



On Tue, Sep 15, 2009 at 1:55 PM, Schwab,Wilhelm K <[hidden email]> wrote:
I just had an experience that fuels my session manager fire.  I loaded Pharo, and it was totally unresponsive.  Why?  I can't be absolutely certain, but here's my story: last night, I had an open connection to a system visible only with a vpn.  With the vpn not in use, either Pharo (or more likely ODBC) went nuts because it could not find the server, and I finally killed the process, started the vpn, and all was well on the next startup.  IMHO, hanging like that is one of the worst things software can do, and I think we can do a lot to fix it with a few simple changes.

Linux ODBC is probably partly to blame, but it should not have been invoked so early in statup.  Someone recently argued against lazy connections, but this would not have happened if they were part of the design.  The image would have become helpless once I did something that triggered database activity, but that is where overlapped calls enter the picture.  Even without the, at least I would have been able to use the image.  Note that if I had taken the offending image to another machine, it could have been useless - not good.


I don't know if I understood you. What does your ODBc drivers do on startup ? did you put some object in the startup/shutdown list ?

best

Mariano
 
Bill


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project