On Feb 25, 2016, at 7:19 PM, Victor Orlikowski <[email protected]> wrote: > > I am wondering if RyuApp event queues should either be: > 1) unlimited, or > 2) able to grow, in a stepwise fashion, without a size bound - but logging on > each size increase.
Actually, an obvious third solution presents itself, once I thought about it some more: 3) Retain the bounded queues, but implement a mechanism similar to a Java "thread dump" that provides: - The number of items in each RyuApp's event queue - The number of greenlets waiting (if any) to put() to a given event queue - The stack backtraces of all currently running greenlets >From some portion of this information (and maybe some additional information), >it should be possible for a user of Ryu to determine if their application has >created a deadlock. Given that I was already planning on implementing something like this, modeled after: https://wiki.openstack.org/wiki/GuruMeditationReport My concerns should be addressed, after I get done implementing the above. I think that the stability patch, as submitted in v5, is therefore "good enough" - and does not need unbounded event queues. We should also recommend as a "best practice" that applications that need to send multiple events to other applications should do so in a worker greenlet, rather than in the greenlet that services the event loop for that application. Sound good? Best, Victor -- Victor J. Orlikowski <> vjo@[cs.]duke.edu ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 _______________________________________________ Ryu-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ryu-devel
