Re: Pyro 3 event server hang
Irmen de Jong <[email protected]>
| Newsgroups | gmane.comp.python.pyro |
|---|---|
| Message-ID | <[email protected]> |
On 22-4-2013 9:54, Christoph Gohle wrote: > Dear Irmen, > > thanks for your message. We started using Pyro3 and it's event service when it > already was in maintenance. Our hope was that it is a stable piece that we can build > our project on. To a large part, this worked out nicely. Well, Pyro3 does have a respectable track record if I may say so. It does appear that there are some corner cases especially with the less-used parts such as the Event Server that raise some problems now and then, which is unfortunate. Thankfully these have been few. It happens that only when starting to work on Pyro4 I've put a lot of effort into quality and correctness, using a large set of unit tests and better cross-platform and cross-version testing (on not very ancient Python versions). Pyro3 doesn't have all this, which makes debugging and fixing stuff all that more time consuming. Hence my decision to leave it behind and focus only on Pyro4. This doesn't mean we can't at least try to help with your problem :) > Event rate is definitely not too high. The queue only starts filling after the worker > has stopped delivering. I did play with the PYRO_ES_BLOCKQUEUE. That helps keeping > the producers happy (as they don't block once the worker is and it's queue fills). > But of course this does not fix that the listener does not recieve events anymore. I > checked that the event handler finishes normally after the last event it recieved. I > found that we are running an older version of Pyro on our event server machine (3.14) > and I have seen that some modifications regarding timeouts were done in 3.16. Could > it be that the socket.send is blocking in the worker? I will try to upgrade and see > if it helps. Please let us know. Btw, what platform are you working on (OS/python version)? > Yes, this might be an option. Although we were hoping to not have to do the debugging > of an event service our selves… oh well. [...] > Yes, debugging race conditions is a pain. That's why we liked the idea of using > established code. Fair enough. Too bad you're encoutering one of the problems. How easy/hard is it to reproduce it? Do you have a minmal set of test scripts that reliable make the problem occur? What feature set of the event server are you using? > Anyway, I thank you very much for this nice package. Apart from this issue we are > very happy with it's features and ease of use. > > Best, Christoph I'm very glad Pyro is of use to you! Regards, Irmen de Jong ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter