| 00:14.43 | *** join/#storm kingdong (n=dong@modemcable160.161-59-74.mc.videotron.ca) |
| 00:14.47 | *** part/#storm kingdong (n=dong@modemcable160.161-59-74.mc.videotron.ca) |
| 00:50.11 | *** join/#storm jml (n=jml@ppp108-61.static.internode.on.net) |
| 02:34.25 | *** join/#storm WebMaven (n=webmaven@nv-65-173-67-149.dhcp.embarqhsd.net) |
| 04:22.27 | *** join/#storm jml_ (n=jml@ppp121-44-221-92.lns1.hba1.internode.on.net) |
| 04:23.11 | *** join/#storm jml_ (n=jml@ppp121-44-221-92.lns1.hba1.internode.on.net) |
| 04:35.47 | *** join/#storm dinho (n=dinho@201008187178.user.veloxzone.com.br) |
| 05:13.27 | *** join/#storm jukart (n=jukart@lsfw01.lovelysystems.com) |
| 06:01.06 | *** join/#storm wallflower (n=wallflow@c-75-71-99-53.hsd1.co.comcast.net) |
| 06:19.53 | *** join/#storm wallflower (n=wallflow@216.113.246.205) |
| 06:24.26 | *** join/#storm pyCube-ish_ (n=jen@ip70-162-117-219.ph.ph.cox.net) |
| 06:45.40 | *** join/#storm wallflower (n=wallflow@216.113.246.205) |
| 07:39.02 | *** join/#storm wallflower (n=wallflow@216.113.246.205) |
| 08:30.25 | *** join/#storm wallflower (n=wallflow@216.113.246.205) |
| 08:41.35 | *** join/#storm richardb (n=richard@client-86-31-155-195.watf.adsl.virgin.net) |
| 09:39.04 | *** join/#storm ajmitch (n=ajmitch@ubuntu/member/ajmitch) |
| 13:40.15 | *** join/#storm rafael (n=rafael@moinmoin/fan/rafael) |
| 15:21.03 | *** join/#storm aklaver (n=aklaver@74-61-141-221.bel.clearwire-dns.net) |
| 15:36.22 | *** join/#storm EnTeQuAk (n=EnTeQuAk@p57B9B497.dip0.t-ipconnect.de) |
| 16:02.18 | *** join/#storm rafael (n=rafael@moinmoin/fan/rafael) |
| 16:51.08 | *** join/#storm michelp (n=michelp@69-30-72-119.dq1sf.easystreet.com) |
| 17:23.30 | radix | jkakar: so about your store-names branch |
| 17:23.33 | jkakar | uh huh |
| 17:23.52 | radix | oh, hmm |
| 17:24.34 | radix | never mind, I think the thought I had didn't make any sense |
| 17:25.00 | radix | I do notice that there isn't really any testing for the fact that the storage is thread-local, though |
| 17:26.15 | jkakar | radix: Right. I don't think that has anything to do with this branch, though. |
| 17:26.20 | radix | It'd be awesome if we could do something like "switch_thread(2)" in the middle of a unit test |
| 17:26.26 | radix | jkakar: well, you added some more thread-local stuff |
| 17:26.43 | radix | or did you? hm |
| 17:26.49 | radix | never mind, no you didn't :) |
| 17:27.18 | radix | I guess _named_index is global, but that's fine |
| 17:28.01 | jkakar | Heh |
| 17:28.27 | niemeyer | radix: Actually, I think it's not.. |
| 17:28.32 | niemeyer | radix: Is it really global? |
| 17:28.37 | radix | niemeyer: it is an instance attribute |
| 17:28.52 | radix | and it's not on _local |
| 17:29.02 | niemeyer | radix: We can't return the same store for a given name in different threads |
| 17:29.05 | radix | that doesn't really hurt anything, AFAICT. |
| 17:29.09 | radix | niemeyer: backwards |
| 17:29.12 | radix | niemeyer: it's store -> name |
| 17:29.20 | niemeyer | radix: Oh |
| 17:29.25 | radix | the name -> store mapping is still in the thread local stuff |
| 17:29.31 | niemeyer | radix: Gotcha |
| 17:29.52 | radix | I'll add a +1 to the branch, since there's currently only technically 1 there right now |
| 17:29.58 | radix | /branch/ticket/ |
| 17:31.02 | radix | jkakar: ok, bug #131221 ready to merge :) |
| 17:31.03 | ubot3 | Malone bug 131221 in storm "Store should expose its name" [Low,In progress] https://launchpad.net/bugs/131221 |
| 17:32.47 | jkakar | radix: Cool, thanks. |
| 18:10.54 | weatherman | storm/trunk r172 committed by jkakar@kakar.ca |
| 18:10.54 | weatherman | Merged store-name [r=michelp,radix] [f=131221] |
| 18:10.59 | weatherman | The new ZStorm.get_name method returns the name of the specified |
| 18:11.03 | weatherman | Store, or None if a name isn't available. In addition, ZStorm uses |
| 18:11.07 | weatherman | weak references internally to avoid keeping objects in memory |
| 18:11.11 | weatherman | unnecessarily. |
| 19:24.34 | *** part/#storm EnTeQuAk (n=EnTeQuAk@p57B9B497.dip0.t-ipconnect.de) |
| 19:43.54 | *** join/#storm st0rm (n=lol@server20022.ourserverdns.net) |
| 19:44.07 | *** part/#storm st0rm (n=lol@server20022.ourserverdns.net) |
| 20:03.17 | *** join/#storm oubiwann (n=oubiwann@c-75-71-99-53.hsd1.co.comcast.net) |
| 22:10.35 | *** join/#storm jkakar (n=jkakar@204-174-36-45.dhcp802.dsl.ucc-net.ca) |
| 22:37.14 | *** join/#storm jml_ (n=jml@203-113-250-169-static.TAS.netspace.net.au) |
| 23:14.16 | tjs | so, I'm a little at a loss to know how to deal with loss of database connection |
| 23:16.07 | radix | the first step is probably to subscribe to bug #94986 |
| 23:16.08 | ubot3 | Malone bug 94986 in storm "Handle database disconnections gracefully" [Undecided,New] https://launchpad.net/bugs/94986 |
| 23:16.49 | tjs | radix: yeh, I posted the bug a while back, was a dup |
| 23:17.05 | tjs | radix: I'm wondering how you guys run apps with it not reconnecting |
| 23:17.56 | radix | tjs: it is very rarely a problem |
| 23:18.16 | radix | tjs: we need to do it before we can really consider ourselves non-beta, of course |
| 23:18.34 | radix | tjs: but we've been running Landscape in beta for months now with no spurious database disconnections |
| 23:18.54 | tjs | radix: my mysql connection seems to timeout each night |
| 23:19.17 | tjs | my local instance is disconnected each morning |
| 23:19.22 | tjs | not storms fault |
| 23:19.39 | radix | that's strange |
| 23:20.33 | radix | We haven't prioritized the bug yet, but it'll have to be fixed probably in the next month or so |
| 23:21.43 | tjs | seems that it makes sense to fix it at two levels, perhaps in basic storm, provide an api to handle disconnection, and in zstorm, have it do some sort of retry three times or something in the transaction |
| 23:53.21 | *** join/#storm wallflower (n=wallflow@216.113.246.205) |