Re: troubleshooting unresponsive pyro processes

I have isolated my thread problem, and I am happy to report it did not
involve Pyro at all.  These concurrency issues are a bear to troubleshoot.

Thank you for your suggestions - and for the awesome software.


On Thu, Jan 17, 2013 at 6:36 PM, Tom Smith <[email protected]> wrote:

> 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 HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and
much more. Get web development skills now with LearnDevNow -
350+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122812

_______________________________________________
Pyro-core mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/pyro-core