Hi,

This is definitely a bug in FDB event handling, but tricky one. It seems
to me that root of this problem is that exception raised in
EventBlock.__wait_for_events is not properly handled in upper levels,
which in turn causes accumulation of blocks in queue. The circular
reference you pointed out just made it visible. So fixing the circular
reference with weakref.proxy will probably not fix the problem. I'm
working on proper fix, but it's hard to test. Can you help me with
testing if I'll create a patch?

best regards
Pavel Cisar
IBPhoenix

Dne 7.11.2014 v 08:56 Dominik Psenner dominik.psenner@...
[firebird-python] napsal(a):

> Good morning,
>
> as written yesterday we have recently implemented a way to react on database events in our python based program. But we are facing several outages with that implementation. First we encountered at least three errors when invoking event_conduit(events), namely:
>
> * Error reading data from the connection.
>
> * Error writing data to the connection.
>
> * unknown ISC error 0
>
> Then I had the suspicion that the private memory was increasing and never dropping, thus I investigated a little further and used the dummy program from yesterday and let it run overnight. It produced and consumed about 1.250.000 events and the process memory raised from 27mb to roughly 400mb. Luckily I was wise enough to start the test script with pdb and this is the outcome:
>
> A memory leak in the class EventBlock(object), defined in dbcore.py at line 1687 caused by the cyclic reference introduced in its constructor at lines 1705 and 1709:
>
> 1705: self.__queue.put((ibase.OP_RECORD_AND_REREGISTER,self))
> 1709: self.__queue = queue
>
> The events issue is now officially promoted to be a blocker for us. Looking at what the code does, it looks mostly like a chicken and egg problem. Ideas / suggestions? Is this the right place to come up with such problems (i.e. do the maintainers of the fdb python package read this mailinglist)?
>
> Best regards,
> Dominik
>