| 00:00.44 | *** join/#storm wallflower (n=wallflow@ip-205-246-113-216.pool.grokthis.net) |
| 01:11.01 | *** join/#storm kov (n=kov@debian/developer/kov) |
| 03:21.28 | *** join/#storm bigdo1 (n=scmikes@72-197-8-8-arpa.cust.cinci.current.net) |
| 03:27.59 | *** join/#storm reacocard1 (n=reacocar@rccy-06-1010.dsl.iowatelecom.net) |
| 03:39.34 | *** join/#storm reacocard (n=reacocar@rccy-06-1010.dsl.iowatelecom.net) |
| 04:09.57 | *** join/#storm bigdog (n=scmikes@72-197-8-8-arpa.cust.cinci.current.net) |
| 05:13.09 | *** join/#storm dobee (n=dobee@lsfw01.lovelysystems.com) |
| 05:23.02 | *** join/#storm jukart (n=jukart@lsfw01.lovelysystems.com) |
| 07:15.38 | *** join/#storm goschtl (n=goschtl@p5B0BF743.dip.t-dialin.net) |
| 08:10.00 | *** join/#storm reacocard (n=reacocar@rccy-06-1010.dsl.iowatelecom.net) |
| 08:46.41 | *** join/#storm goschtl (n=goschtl@p5B0BF743.dip.t-dialin.net) |
| 09:16.00 | *** join/#storm mcella (n=mcella@ip-176-85.sn2.eutelia.it) |
| 11:16.32 | *** join/#storm dobee (n=dobee@lsfw01.lovelysystems.com) |
| 11:18.44 | *** join/#storm jukart (n=jukart@lsfw01.lovelysystems.com) |
| 11:41.17 | *** join/#storm andrea-bs (n=andrea@ubuntu/member/beeseek.developer.andrea-bs) |
| 12:11.28 | *** join/#storm niemeyer (n=niemeyer@201-40-139-76.pltce701.dsl.brasiltelecom.net.br) |
| 12:18.20 | *** join/#storm andrea-bs (n=andrea@ubuntu/member/beeseek.developer.andrea-bs) |
| 12:20.28 | *** join/#storm kov (n=kov@debian/developer/kov) |
| 12:56.06 | *** join/#storm niemeyer_ (n=niemeyer@201-40-139-76.pltce701.dsl.brasiltelecom.net.br) |
| 13:04.20 | *** join/#storm fcorrea (n=fcorrea@c953f91f.virtua.com.br) |
| 13:48.13 | *** join/#storm bigdog (n=scmikes@72-197-8-8-arpa.cust.cinci.current.net) |
| 14:28.45 | *** join/#storm fcorrea_ (n=fcorrea@c953f94e.virtua.com.br) |
| 15:02.17 | *** join/#storm lightyear (n=ben@nat/fluendo/x-a274783760be365a) |
| 15:02.41 | lightyear | guys... big problem... I think that relations inside storm are leaking |
| 15:03.28 | lightyear | the relation creates a strong reference between the necessary objects, so that they stay in memory but it seems that it is not breaking this references for each of them |
| 15:03.36 | lightyear | in fact, it breaks only every 24th here... |
| 15:22.34 | lightyear | it seems that the hook is not called to break the references... |
| 15:34.07 | tlynn | got a minimal test case? |
| 15:44.39 | lightyear | I'll try |
| 16:03.15 | *** join/#storm oohlaf (n=olaf@85.149.152.99) |
| 16:15.12 | lightyear | tlynn: http://pastebin.com/m5006b48 |
| 16:15.22 | lightyear | and watch the numbers increasing |
| 16:15.49 | lightyear | for me it looks like this |
| 16:15.49 | lightyear | http://pastebin.com/m60718350 |
| 16:16.08 | lightyear | I am doing all the time the same loop over the same amount of objects... |
| 16:16.28 | lightyear | so I would expect the time it takes to be around the same amount... |
| 16:16.40 | lightyear | but it changes very fast from half a second... up to eight... |
| 16:18.52 | lightyear | tlynn: and I blame the 'add' of the relations to leak... |
| 16:19.21 | lightyear | it seems that it links it but does not unlink between the key and the value in this case so that both stay in memory and are flushed all the time... |
| 16:20.02 | tlynn | well, I see the same behaviour here when I run your code, so that's a good start |
| 16:20.53 | *** join/#storm fcorrea (n=fcorrea@c953f94e.virtua.com.br) |
| 16:22.47 | lightyear | i'll add explicit garbage collectiong |
| 16:23.46 | lightyear | gc.collect() is not collecting anything... |
| 16:23.49 | lightyear | after each loop |
| 16:26.04 | lightyear | tlynn: small update with gc: http://pastebin.com/m3dd3207a but still the same problem |
| 16:26.23 | tlynn | agreed, nothing being collected |
| 16:28.01 | lightyear | doing some debug, I found out that on this kind of relations both relations are set as 'on_remote' |
| 16:28.34 | lightyear | but the unlink-hook is not called so that they strong reference that is created between key and value here is never distroyed |
| 16:30.01 | lightyear | in fact.. you should also be able to see the memory grow with this script... |
| 16:30.02 | *** join/#storm fcorrea_ (n=fcorrea@c953f3e5.virtua.com.br) |
| 16:30.44 | lightyear | for every loop it is around 1mb here |
| 16:31.25 | tlynn | "print len(gc.get_objects())" shows the leaking too |
| 16:31.41 | lightyear | right |
| 16:31.44 | lightyear | adds it |
| 16:32.18 | tlynn | almost exactly 20k objects per iteration |
| 16:35.10 | lightyear | but 20k... that is a lot |
| 16:35.49 | lightyear | it means a sixth of the number of objects we are connecting |
| 16:35.57 | lightyear | no... wait |
| 16:36.02 | lightyear | we only connect 400 to one ... |
| 16:36.07 | lightyear | per itereation |
| 16:37.06 | lightyear | so it is 50objects per object we connect to the one ????? |
| 16:37.12 | lightyear | dude |
| 16:37.32 | tlynn | yeah. it's not clear to me what's happening. |
| 16:42.30 | tlynn | there's nothing surprising in the generated sql that I can see |
| 16:45.13 | tlynn | unsurprisingly, there is no leak if you comment out "key.values.add(value)" |
| 16:48.01 | tlynn | if you add "store.remove(value)" immediately after that line though, it crashes in references.py |
| 16:48.17 | lightyear | huuu.... |
| 16:48.25 | lightyear | that sounds like a real bug to me |
| 16:48.29 | tlynn | yup |
| 16:49.28 | tlynn | the crash line (360) indicates that it's trying to access "remote" stuff, with matches your initial debugging |
| 16:49.34 | tlynn | s/with/which/ |
| 16:50.05 | lightyear | :)) what is that but? |
| 16:50.10 | lightyear | s/but/bot |
| 16:50.24 | lightyear | s/but/bot/ |
| 16:50.28 | lightyear | :)) |
| 16:50.32 | therve | so hum |
| 16:50.48 | therve | the leak comes from store._alive probably |
| 16:50.51 | lightyear | hi thereve |
| 16:50.57 | lightyear | -e |
| 16:50.58 | radix | but they're committing, right? |
| 16:51.03 | radix | so store._alive should be reset |
| 16:51.03 | therve | I don't know why though, since that's only weak references |
| 16:51.08 | lightyear | we are commit after every loop call |
| 16:51.18 | lightyear | no, no it is not the live thingy |
| 16:51.23 | lightyear | that is static at 100 or something |
| 16:51.44 | lightyear | the problem is that it creates strong references between the obj_info between key and value in this case |
| 16:51.56 | lightyear | but never destroys them, so that both stay in memory and are not garbage collected |
| 16:51.59 | therve | if I remove the _alive setting, there's no more leak |
| 16:52.18 | tlynn | leaves it to the experts |
| 16:52.57 | therve | but _alive should only contains weakref... that doesn't make sense |
| 16:53.49 | radix | therve: on the value |
| 16:54.07 | radix | lightyear is saying it has something to do with the obj info |
| 16:54.18 | radix | although I don't understand what he's saying with "between the obj_info between key and value" |
| 16:54.29 | therve | the obj_info is the value in the _alive dict |
| 16:54.33 | lightyear | doing a print in iter_alive shows me that it grows instiantly |
| 16:54.51 | therve | lightyear: what grows? |
| 16:54.54 | lightyear | self._alive |
| 16:54.58 | therve | right |
| 16:55.35 | lightyear | radix: in the relation (in storm/references.py) we create a strong reference between the obj_info of key and the obj_info of value |
| 16:56.13 | niemeyer | The fact that _alive grows simply means that the obj_info isn't collectable.. it's a symptom rather than a probem |
| 16:56.16 | niemeyer | problem |
| 16:56.23 | radix | niemeyer: I don't think _alive is growing anyway |
| 16:56.24 | lightyear | niemeyer: right |
| 16:56.28 | radix | according to lightyear |
| 16:56.43 | niemeyer | In any case, if there's a small test case, we should be able to fix it somewhat quickly |
| 16:56.44 | lightyear | print len(self._alive) in iter_alive ... |
| 16:56.47 | radix | lightyear: yeah, but shouldn't the Relation be deleted? |
| 16:56.58 | radix | niemeyer: http://pastebin.com/m3dd3207a |
| 16:57.09 | lightyear | radix: yes, it should be on two relations like this, it does not go into the unlink... |
| 16:59.52 | niemeyer | Yeah, I guess we don't need the strong reference in the case of ReferenceSets |
| 17:00.09 | niemeyer | This used to be more important when we didn't have the cache system |
| 17:00.43 | niemeyer | Now the benefit is outweighted by the amount of data in memory in edge cases like this |
| 17:01.00 | niemeyer | key itself is never collected before it's constantly being used |
| 17:01.20 | niemeyer | and then the obj_info isn't collected either, which means that the strong references stay in place across transactions |
| 17:01.34 | niemeyer | This makes more sense with simple References |
| 17:01.40 | niemeyer | (non-Sets) |
| 17:05.03 | therve | so, the leak disappears if I comment one hook in the link method |
| 17:05.27 | lightyear | the unlink one? |
| 17:05.34 | lightyear | therve: which one? |
| 17:05.57 | therve | remote_info.event.hook("removed", self._break_on_remote_removed |
| 17:06.35 | lightyear | all of them? |
| 17:06.44 | lightyear | because it seems to be there multiple times, no? |
| 17:06.57 | lightyear | no... the other one is on local_info |
| 17:07.11 | therve | the first one |
| 17:07.28 | therve | line 619 on trunk |
| 17:07.39 | lightyear | still leaking here.... |
| 17:07.45 | lightyear | (with 0.12) |
| 17:07.57 | therve | it probably creates a loop between remote_info and local_info |
| 17:08.14 | lightyear | i think so |
| 17:08.33 | therve | but it would be broken |
| 17:11.22 | *** join/#storm pyCube (n=jmayfiel@12.87.213.22) |
| 17:24.45 | therve | interesting |
| 17:25.03 | therve | changing EventSystem._hooks to be a WeakValueDictionary fixes the problem |
| 17:25.11 | therve | niemeyer: could that be a possible fix? |
| 17:27.02 | therve | hum doesn't look like it |
| 17:27.53 | *** join/#storm lgs (n=lgs@217.216.91.110.dyn.user.ono.com) |
| 17:28.10 | lgs | Hi, I'm trying to easy_install storm |
| 17:28.19 | lgs | but it has issues with https |
| 17:28.43 | lgs | Reading http://pypi.python.org/simple/storm/ |
| 17:28.44 | lgs | Reading https://storm.canonical.com |
| 17:28.44 | lgs | Download error: unknown url type: https -- Some packages may not be found! |
| 17:28.50 | lgs | that's easy_install output |
| 17:28.59 | therve | lgs: you have to retrieve the tarball separately |
| 17:29.13 | therve | and then you can call easy_install tarball |
| 17:29.20 | lgs | therve: oh, that's too bad because that means I can't put it on my buildout |
| 17:29.52 | therve | sorry, easy_install is bad |
| 17:31.29 | lgs | therve: the weird thing is it looks like it is working for nva.stormcontainer |
| 17:31.35 | lgs | http://stormcontainer.googlecode.com/svn/repos/nva.stormcontainer/setup.py |
| 17:31.51 | lgs | they just added 'storm' to the install_requires section |
| 17:31.53 | therve | lgs: what's your version of python? |
| 17:31.58 | lgs | 2.4 |
| 17:32.16 | therve | is that a standard install? |
| 17:32.30 | therve | maybe you're missing ssl support or something like that |
| 17:32.56 | lgs | therve: that could be, I'm using virtualenv |
| 17:33.07 | lgs | therve: with --no-site-packages |
| 17:34.11 | therve | lgs: indeed, it works for me |
| 17:34.33 | lgs | therve: I see, thanks for helping me finding the problem |
| 17:34.45 | therve | you're welcome |
| 17:35.30 | niemeyer | lightyear: What's your email? Do you want us to get back to you about the fix? |
| 17:35.45 | lightyear | niemeyer: as soon as possible, yes |
| 17:35.51 | lightyear | benjamin at fluendo.com |
| 17:37.20 | lightyear | so... need to go now... i'll be back tomorrow |
| 17:37.31 | niemeyer | lightyear: Super.. this shouldn't take long, but I can't look at this myself right now.. I'll try to have a look for tomorrow, if no one else wins the race |
| 17:37.40 | niemeyer | lightyear: Thanks for the report! |
| 17:37.52 | lightyear | thanks for the help on fixing it :) |
| 17:39.25 | pyCube | so threading + storm (not sqlite) requires that objects be accessed from only one thread at a time, right? |
| 17:41.07 | pyCube | playing with storm in a qt4 app.. wondering about how threading might work here |
| 17:43.15 | therve | pyCube: storm is not thread-safe, if that helps you |
| 17:45.39 | pyCube | um.. heh.. |
| 17:45.41 | pyCube | thanks |
| 17:48.37 | *** join/#storm andrea-bs (n=andrea@ubuntu/member/beeseek.developer.andrea-bs) |
| 17:49.16 | therve | pyCube: the fact that you have a qt4 app doesn't imply that you have threads, right? |
| 17:49.59 | pyCube | no, but there are a few places where I'd like the UI to not lock when its running a hefty query |
| 17:50.58 | therve | alright |
| 17:51.09 | therve | so yeah having one dedicated thread may be a good idea |
| 17:52.09 | pyCube | what I dont understand is say you have a thread for doing queries.. when it returns those storm objs to the other thread.. thats ok? |
| 17:53.00 | therve | ahah |
| 17:53.03 | therve | good question |
| 17:53.18 | therve | I have no idea |
| 17:55.35 | radix | um, easy_install should work with https |
| 17:55.41 | radix | I think it works if you have the right dependency installed, maybe |
| 17:55.48 | radix | I'm pretty sure I've easy_installed stuff from https before |
| 17:56.20 | therve | radix: right, it worked for me |
| 17:56.29 | radix | pyCube: the restrictions that storm puts on you for threading is that one store and all objects associated with that store should only ever be accessed from one thread |
| 17:58.22 | pyCube | so waiting (blocking) for a query to return is just the way it goes? |
| 17:59.01 | pyCube | unless you turn the results into some not-storm obj.. |
| 17:59.09 | radix | I'm not sure exactly what you mean by that |
| 18:00.34 | pyCube | well, if i want the results of a query i have to do it in the same thread as the gui, in this case |
| 18:02.15 | radix | pyCube: run the query in the other thread, send basic data back to the GUI thread |
| 18:02.24 | pyCube | right.. |
| 18:02.26 | jkakar | Wouldn't that requirement basically make twistorm useless...? |
| 18:02.48 | pyCube | but its just so nice to have storm obj type results.. heh |
| 18:02.50 | radix | jkakar: this is what twistorm tries to do |
| 18:02.59 | jkakar | Or, if not useless, at least dangerous. |
| 18:03.30 | therve | jkakar: I'm not following you |
| 18:03.49 | jkakar | radix: Well, sure. It does nice things to run queries in a thread, but you can deal with the resulting objects in the main thread, right? |
| 18:03.53 | jkakar | therve: ^ |
| 18:03.59 | pyCube | i did some stuff with twisted and storm and did jsut that.. pushed results into standard type dicts befreo returning.. works but its kind of a pita |
| 18:04.08 | radix | jkakar: yes, but the resulting objects are wrapped so that the operations they do go off to the other thread |
| 18:04.29 | jkakar | radix: Ah, okay. That makes more sense. Thanks. |
| 18:04.37 | therve | at least, that's what it tries to do |
| 18:04.48 | radix | :) |
| 18:04.57 | radix | therve: by the way, how does it know which thread to dispatch to? |
| 18:05.21 | therve | radix: it stores a reference somewhere I think |
| 18:05.25 | radix | ah right ok |
| 18:05.46 | therve | but the ability to get objects from Storm that can't access the db anymore would be nice |
| 18:23.27 | fcorrea_ | Hey there, is there any restriction on posgres versions? I mean, I've installed storm trunk yday and not it's broken due to my pg version |
| 18:23.40 | fcorrea_ | <PROTECTED> |
| 18:23.40 | fcorrea_ | ValueError: invalid literal for int(): 3beta4 |
| 18:24.17 | fcorrea_ | Yeah, bledding edge code here :). I mean, macports installs this |
| 18:25.38 | fcorrea_ | Well, I am going to patch it so it parses 3beta4 as.... plain 3 |
| 18:36.36 | niemeyer | fcorrea: If that's the standard way that postgres provides interim versions, we should make Storm to understand them |
| 18:36.43 | niemeyer | s/to und/und |
| 18:42.13 | kov | niemeyer: yo! think you can take a look at the oracle branch again, now that I merged my code with the old one? =) |
| 18:46.06 | fcorrea | niemeyer, I have the patch already. Just checking if postgres will always repeat the pattern |
| 18:47.35 | niemeyer | kov: I can, and I still have that in my todo list as an outstanding task |
| 18:48.17 | niemeyer | kov: I apologize for not getting to it yet.. my holidays were internet-less, which means everything I was planning was postponed unfortunately |
| 18:49.20 | kov | niemeyer: awesome, it's all good, not in a hurry =) |
| 18:49.40 | kov | niemeyer: came to Brasil for holidays? =D |
| 18:50.34 | niemeyer | kov: Nah.. was already here.. :-) |
| 18:51.01 | niemeyer | kov: I went down to the south to see family and old friends |
| 18:52.36 | kov | niemeyer: =) |
| 19:02.26 | fcorrea | niemeyer, I can't find any documentation regarding pg server version string. But I will submit the patch anyway so it can at least be there as documentation |
| 19:04.27 | niemeyer | fcorrea: Sweet, thanks |
| 19:10.35 | fcorrea | niemeyer, np. Just submitted |
| 19:20.07 | *** part/#storm lgs (n=lgs@217.216.91.110.dyn.user.ono.com) |
| 21:56.13 | *** join/#storm reacocard (n=reacocar@rccy-06-1010.dsl.iowatelecom.net) |
| 23:06.09 | *** join/#storm fcorrea (n=fcorrea@c953f3e5.virtua.com.br) |