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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.