Re: troubleshooting unresponsive pyro processes
Tom Smith <[email protected]>
| Newsgroups | gmane.comp.python.pyro |
|---|---|
| Message-ID | <CACkP891Ufy2KXvimkft+YtMZm=LamGLEUL1s4LCS0R=vw-fAag@mail.gmail.com> |
On Thu, Jan 17, 2013 at 6:00 PM, Irmen de Jong <[email protected]> wrote: > Hi Tom, > > On 17-1-2013 19:25, Tom Smith wrote: > > When I augment this code to run inside a Pyro server process, things get > flaky. (I am > > currently using the multiplex server in order to narrow down the > possibilities.) > > Initial connections from a Pyro client may work fine, but within a few > tries, both the > > client and server process will become unresponsive (cannot ^C). The > pattern *seems* to > > be that this occurs after the domain class has done some network I/O, > and then a Pyro > > client connects. (Connections from a Pyro client before the network I/O > seem to work > > better, though maybe not 100%). > > What exactly do you mean by "cannot ^C"? Could it not be that Python is > not responding > to the ^C simply because there is a signal handler installed, or a > background thread > that eats the signal? > Is Pyro still responding to remote method calls? Is your domain class > still responding > to socket communication? > Sorry, I left out this important part. Pyro stops responding to remote method calls (the client blocks). At this point, the server cannot be stopped with ^C. > > > Any ideas on what I should try next? > > Hmm. What happens when you use the normal threadpool server? What happens > when you stub > out your domain class code? Is that C extension doing something weird with > signals/threads/eventloops/socketconfiguration? Is it running its own > eventloop that > blocks execution of Pyro? Normal threadpool server shows the same behavior. When the domain class is not doing its network I/O, then everything works beautifully. The fact that the library I am using for the network I/O (pjsip) spawns its own worker thread leads me to believe that it should not interfere with Pyro execution. And that seems to be supported by the thread state that I see. That being said, it does seems like some interaction with pjsip, since this only occurs after pjsip has handled a call (but not 100% of the time). Strange... > > Regards, > Irmen. > > Thanks for your thoughts, Tom > > ------------------------------------------------------------------------------ > Master Visual Studio, SharePoint, SQL, ASP.NET > > , C# 2012, HTML5, CSS, > MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current > with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft > MVPs and experts. ON SALE this month only -- learn more at: > http://p.sf.net/sfu/learnmore_122712 > > > _______________________________________________ > Pyro-core mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/pyro-core > > > ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 _______________________________________________ Pyro-core mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/pyro-core