Team Chat Logs

April 25, 2010

2010 3
Mo Tu We Th Fr Sa Su
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30    
<< <   > >>

[00:11:25.027980]<hasienda>cboos: from a quick http://de.forestle.org/search.php?q=japan+Jun+Omae query you may safely guess that Jun is the first name, Omae has many occurances as surname. To be even more sure, I guess you need to ask the person itself. ;-)
[00:11:59.223502]<cboos>hasienda: thanks for the tip!
[00:13:25.231182]<cboos>speaking of this, I once asked who was "trac-ja@...", who contributed a lot to Trac, but never got an answer
[00:13:52.273942]<cboos>maybe I should add "Anonymous Japanese trac-ja@..." ;-)
[00:17:31.950972]<cboos>Hm, actually I should really do that, as he contributed lots of good patchs. Mailing him one last time.
[02:09:41.223329]<sivang>rre all
[02:09:43.893395]<sivang>slam: howdy
[02:09:58.559795]<sivang>slam: could you send me the links or the svn names for the plugins you mentioned on your setup?
[02:10:09.907287]<sivang>slam: searchall-plugin,superuser-plugin, openid-plugin
[02:10:16.312859]<sivang>slam: I can't seem to find them by those names
[02:11:04.855407]<slam>sivang: they are all at trac-hacks.org
[02:11:48.493377]<macmaN>otaku42: john3050 might be a spammer account on th
[02:12:22.871781]<slam>sivang: http://bitbucket.org/Dalius/authopenid-plugin/wiki/Home
[02:12:49.843713]<slam>http://trac-hacks.org/wiki/SearchAllPlugin
[02:13:25.649471]<sivang>slam: ah thanks, yes I see it is easy to find them if not using hte search box of trac
[02:13:30.353931]<sivang>slam: as they are all on the same page
[02:13:33.927364]<slam>http://trac-hacks.org/wiki/SuperUserPlugin
[02:13:55.186916]<slam>just use text search in your browser on the start page ;-)
[02:14:11.058721]<sivang>slam: exactly what I did eventually
[02:14:18.332897]<slam>you're right, trac search leads to a lot of stuff
[02:14:31.968197]<sivang>slam: in the case of your terms, like search-all
[02:14:38.875085]<sivang>slam: as a polugin name it gave nothing
[02:14:47.585510]<sivang>slam: as this is probably not ow it is listed anywhere
[02:15:17.891726]<slam>it is http://trac-hacks.org/wiki/SearchAllPlugin
[03:14:19.512077]<cboos>rblank: edit conflict on #9267
[03:14:22.591656]<cboos>;-)
[05:07:33.213222]<rts>hi all, happy weekend
[05:43:44.192728]<sivang>hasienda: it eventually worked dude, I managd to setup it up as needed
[05:43:46.912352]<sivang>hasienda: thanks!
[05:45:13.557501]<hasienda>sivang: yeah, seen your comment (two days ago?). Congrats, well done.
[05:46:50.116719]<hasienda>sivang: Since docu wouldn't mind improvement, I'd really like and eventually assist in making it better, target "non-developer" in mind ;-)
[05:47:43.250962]<sivang>hasienda: yes, we should
[05:48:27.449856]<hasienda>rts: weekend is relative, no silent, if you look at the Trac repo. These guys are working hard to get the first release candidat out (today?).
[05:49:08.192633]<rts>hasienda: great, so that is what weekends are finally made for ;)
[05:50:59.913960]<rts>hasienda: got your work done on the matter of custom time fields? great!
[05:51:44.054926]<hasienda>sivang: facing a hard business week ahead I'd suggest to gather next friday evening or so. I'll be there. :-) Meanwhile I'll look into existing (wiki) docu to recommend a suitable place to create or (would be even better) expand.
[05:54:24.919113]<hasienda>rts: considering development docu at http://trac.edgewall.org/wiki/TracTicketsCustomTimeFields and the state of my patches, I won't consider it done, but maturing. In fact, it's already useful, and this is a big step ahead, compared to 5 years of waiting and hacking around the missing native support with text fields.
[05:56:26.221836]<hasienda>rts: as you mention it, actually I count on you for the beta-testing thing, as time permit :-)
[05:56:58.386457]<rts>hasienda: beta testing, great, when did i volunteer ;) - but jokes aside, i will try to if time permits
[05:57:33.429083]<rts>hasienda: how about custom duration fields, too, i.e. 14d and similar such constructs?
[05:59:04.072442]<rts>hasienda: is you patch already in trunk or must i apply it from a patch you delivered with a ticket?
[05:59:34.697806]<hasienda>rts: bionoid is eager to test it too, promised to reserved next Saturday and buy me a juice, if we meet. But considerung Pittsburg/US <-> Dresden/Germany, there's some time left for this to happen. ;-)
[06:00:03.566739]<rts>hasienda: *big grin*
[06:00:38.468835]<hasienda>rts: you'll find a quickstart section in the wiki page. You can get all you need from my Mercurial repo.
[06:01:07.820043]<rts>hasienda: i will look into that
[06:02:03.641720]<hasienda>rts: forget about custom duration. Thinking about numeric fields with selectable units, so making days just one option. How would you like this?
[06:03:14.603332]<rts>hasienda: basically the same, i think, but what you propose seems more like it from an end-users point of view
[06:03:42.587807]<rts>s/like it/like it,/
[06:03:42.597577]<evil_twin>rts meant: hasienda: basically the same, i think, but what you propose seems more like it, from an end-users point of view
[06:03:55.209352]<rts>^^
[06:07:06.950186]<hasienda>rts: well, once you have this, you can base some nifty things on it, like selector for compatible units (mg|g|kg|t), selecting 'mg', input '120', let it calculate 0.12 kg on the fly and store that for you; automatic sum, etc.
[06:08:50.904167]<rts>hasienda: oh great, so this is actually about entering custom values with arbitrary units into fields, great and very nice to have, e.g. task for programmer #1: lines of code: 10loc, lines of comments: 100loc ;)
[06:13:11.954513]<rts>hasienda: so you will make it possible for the user to alternatively enter expressions into custom fields?
[06:19:54.598540]<sivang>hasienda: sounds right, however I ma very busy with work so I am also unsure how much time I can dedicate to no coding stuff
[06:20:27.032838]<sivang>hasienda: I also have other commitments for my spare time already :-)
[06:23:45.589616]<hasienda>sivang: me too, rl is calling right now, see you, but I'll try to find some minutes and not totally forget about it.
[06:25:14.012228]<hasienda>rts: well, that's about what I expect to provide this way. Weight was just an example, you got that. loc, s/min/h/d, ...? :-)
[06:26:19.134082]<hasienda>rts: ... for real projects certainly currency too.
[06:26:44.515385]<rts>hasienda: cool. ok, well, then have a nice sunday or what is left of it, cya
[06:27:41.950445]<hasienda>rts: don't meant to do it 'till tomorrow, did I? ;-)
[06:43:56.099848]<rgammans>can any one help me with the acct_mgr plugin - I can't get it to send emails . I;'ve not user trac notifications before
[06:44:02.625909]<rgammans>s/user/used/
[06:44:02.636634]<evil_twin>rgammans meant: can any one help me with the acct_mgr plugin - I can't get it to send emails . I;'ve not used trac notifications before
[06:44:40.810499]<macmaN>osimons: you around?
[06:55:46.624684]<hasienda>@wiki TracNotification
[06:55:46.630573]<evil_twin>http://trac.edgewall.org/wiki/TracNotification
[06:56:49.997076]<hasienda>rgammans: ^^ look there, don't know, if the maintainer is arround. But you'll get help here anyway, if you're patient... :-)
[06:57:10.645822]<rgammans>yeah - I think I've got the settings right - but no email is coming out. I don't think smtplib is being called - in fact I don't *think* the notification code is being called at all.
[06:57:58.226380]<rgammans>I'm trying to insert self.log.debug("foo") in a critical points but not seeing them in the trac.log -
[07:02:44.952888]<macmaN>im pretty sure you should do self.env.log.debug
[07:04:13.508296]<rgammans>I'll try to change it then - see if it makes a difference - I just copied self.log from what I saw elsewhere - but no I look it seems to be a mix of the two.
[08:01:10.472625]<rts>acct_mgr.web_ui.RegistrationModule = disabled
[08:01:29.145027]<rts>rgammans: did you enable that plugin?
[08:01:59.456899]<rgammans>yup.
[08:02:31.200661]<rts>rgammans: now, i will look into the plugin now and report when i have found a clue on how to solve your problem
[08:02:58.328707]<rgammans>The acct_mgr.notifications.AccountChangeListener is not it AccountManager.chnage_listeners when notify() is run
[08:03:13.430628]<rgammans>if that helps any
[08:03:47.585136]<rts>pardon me, but i do not understand, is the listener not being called upon change?
[08:03:47.908690]<rgammans>ah. is the config line case sensitive?
[08:04:08.529640]<rts>i think so
[08:04:35.317743]<rts>also there is acct_mgr.web_ui.EmailVerificationModule = enabled
[08:05:34.286634]<rgammans>email verifcation is disabled becasue I didn't want to enable it until I was sure email was working..
[08:06:21.940680]<rts>hm, if you don't enable it, then it won't happen
[08:06:37.565047]<rgammans>I put a debug line in acct_mgr.api where it calls the change_listeners, the only listener registered then was rhe account manager itself.
[08:06:49.456039]<rgammans>rts - not even forgetton password emails?
[08:06:56.893217]<rts>but otherwise, there are a few options in the change listener:
[08:07:02.114465]<rts>_notify_actions = ListOption(
[08:07:02.319263]<rts>32 'account-manager', 'notify_actions', [],
[08:07:02.332504]<rts>33 doc="""Comma separated list of actions to notify of.
[08:07:02.346671]<rts>34 Available actions 'new', 'change', 'delete'.""")
[08:07:20.904876]<rts>so perhaps your configuration rules out notifications on new, change or delete?
[08:08:01.537292]<rgammans>how would i check?
[08:08:54.074618]<rts>hm, basically does your trac-ini have a section called [account-manager], and if so, is there a key called "notify_actions" having a list of values, namely "new, change, delete"
[08:10:07.315349]<rgammans>I have no notify_actions key in that section. adding now.
[08:10:14.732556]<rts>give it a try
[08:12:19.825054]<rts>is the email verification notification message being sent, though?
[08:12:28.818324]<rgammans>no change.
[08:12:33.075964]<rgammans>rts. no
[08:13:09.486222]<rts>hm, then there should be something wrong with your overall system configuration, or perhaps in the trac.ini where it configures your mailing system
[08:13:54.371189]<rgammans>rts: why is ChangeListner listing in change_listener at line 252 of api.py ?
[08:14:22.674065]<rgammans>pah. AccountManagerChangeListener in self.change_listeners - i meant
[08:15:10.586009]<rgammans>I added this line " self.env.log.debug("notifing %s" % self.change_listeners)" and get this -"DEBUG: notifing [<acct_mgr.api.AccountManager object at 0xb730332c>]"
[08:15:14.444702]<rts>hm, perhaps the account manager itself is extensible so that other plugins can listen on events from the plugin?
[08:16:19.283468]<rts>btw. which authentication scheme are you using, LDAP or simply a database based authentication or else?
[08:16:25.003504]<rgammans>htdigest
[08:16:44.282166]<rgammans>auth and account creation seems to work
[08:16:51.928741]<rts>smtp_enabled = BoolOption('notification', 'smtp_enabled', 'false',
[08:16:52.011263]<rts> """Enable email notification.""")
[08:17:10.410027]<rts>did you enable that in your trac.ini under [notification] ?
[08:17:27.529327]<rgammans>double (quadruple) checking...
[08:17:42.014466]<rgammans>smtp_enabled = true : yes
[08:18:14.782969]<rts>have you enable debug level logging support for your trac installation?
[08:18:27.326967]<rts>that way much more information will be present in the logs
[08:18:29.542598]<rgammans>yes. hence the data above.
[08:18:45.778961]<rts>okay
[08:19:50.899771]<rgammans>To my unknowlegable eye it looks like acct_mgr/notifications.py hasn't been imported.
[08:20:09.222250]<rts>to be more precice, account creation and authentication does work, so when do you not get the email notification?
[08:20:12.716896]<rts>from where?
[08:21:13.180214]<rgammans>sorry . don't understand. I'm currently testing 'Forgot your password'.
[08:21:41.679490]<rts>acc_mgr/notifications is component based, so that is actually defined in the egg's meta data (here: entry points/trac.plugins)
[08:21:54.613577]<rts>so these components will be loaded by trac upon system start
[08:23:23.949714]<rts>okay, i will give it a shot, and see where i can find the associated behaviour to "Forgot your password"
[08:23:52.037914]<rgammans>'kay
[08:24:48.360696]<rts>hm password reset comes close to it, does it not? - if so, there is no constraint whatsoever, and that email should go out
[08:25:06.318234]<rgammans>Yes - I think it internall called password_reset
[08:27:03.484392]<rts>perhaps, i was just argumenting on the basis of acct_mgr.notification.AccountChangeListener#user_password_reset
[08:27:12.161978]<rgammans>I put a debug line in PasswordResetNotification.notify() - and I am not seeing that in the logs either
[08:28:18.271289]<rts>and yes, you are right, the api.py does not include notifications.py, but then again, maybe this is automatically being resolved by the component loader, i dunno
[08:29:33.122549]<rts>okay, i pass, perhaps someone with more intimate knowledge into the system can give you more advice, sry
[08:29:40.672192]<rgammans>it more that the self.change_listeners only have a AcountManager instance an no class from notifications - it looks like the notificaitons is suppose to hook in via the Listeners ExtenstionPoint
[08:31:02.199299]<rts>yeah, so the component system of trac is meant to work
[08:31:20.873829]<rgammans>Hmm
[08:31:22.335211]<rts>see trac.core.ExtensionPoint and trac.core.Component.implements for more information on that
[08:31:35.494260]<rgammans>yeah.
[08:32:23.902646]<rts>shice, i burned my moustache lighting up the cigarette ;)
[08:33:32.982185]<rts>it smells like hell, argh
[08:35:55.439126]<rgammans>hmm - It does seem to be loading the notifications modules see http://paste.pocoo.org/show/205989/
[08:41:13.773408]<rts>rgammans: in api.AccountManager#_notify all AccountChange listeners will be notified, as per web_ui.AccountModule#process_request
[08:41:27.397364]<rts>rgammans:perhaps you should check there?
[08:42:54.851086]<rts>rgammans: and, according to web_ui.AccountModule#match_request, the request uri must exactly match "/reset_password"
[08:43:03.773551]<rgammans>In api.AccountManager#_notify - I logged self.change_listeners. It did;t have any notify classes.
[08:43:54.986915]<rts>rgammans: that is because the sole change listener, that is AccountChangeListener will instantiate these for you
[08:44:20.564193]<rgammans>AccountChangeListener isn't listed either
[08:44:29.661347]<rgammans>only AccountManager
[08:45:02.068522]<rts>rgammans: oh, um, well, AccountManager also implements the same interface and will simply log the event
[08:45:17.839915]<rgammans>rts - which is indeed what I'm seeing.
[08:45:22.351775]<rts>rgammans: see your previous message
[08:46:10.499753]<rgammans>um.
[08:46:52.431129]<rts>rgammans: however, AccountManager#_notify iterates over all existing change listeners, so that eventually the real change listener should be called also
[08:47:24.127737]<rgammans>but AccountChangeListener isn't in the list it is iterating over
[08:47:24.419672]<rts>rgammans: unless the real change listener is never installed into the system, lets check setup.py
[08:48:30.887812]<rts>rgammans: according to setup.py the notification module is listed as part of being a provider for trac.plugins, see the entry_points declaration
[08:48:40.331019]<rgammans>'yes,...
[08:49:05.808951]<rgammans>got that here
[08:50:08.500142]<rts>rgammans: perhaps the problem lies somewhere else, which version of trac are you using and which version of the acct_mgr plugin are you using?
[08:51:07.587729]<rgammans>trac 0.11-r7716 , setuptolls thinks acct_mgr is TracAccountManager-0.2.1dev_r7731
[08:52:19.308128]<rts>rgammans: 0.21 is the latest from trunk, perhaps you should reconsider and use the 0.11 branch?
[08:53:26.318479]<rgammans>Hmm. I thought I had used the 0.11 branch.
[08:54:17.232714]<rts>rgammans: dunno but maybe in _notify() there is also an exception being raise upon getattr?
[08:55:07.835168]<rts>rgammans: but then again, i am just guessing... perhaps using acct_mgr 0.11 would solve it, although it see no real difference between both right now
[08:55:23.318842]<rgammans>maybe. I got the log line wrong though earlier and trac caught the exception and displayed it quite nicely- I'm not seeing anything like that
[08:57:23.675136]<rts>rgammans: so you get your email verification mails, do you?
[08:57:24.645230]<rgammans>doing svn co http://trac-hacks.org/svn/accountmanagerplugin/0.11
[08:57:31.931314]<rgammans>rts: no
[08:57:56.947457]<rts>rgammans: have you installed a smtp mailer on the system where trac is installed?
[08:58:03.670129]<rgammans>yup. exim .
[08:58:19.606984]<rgammans>It a smtp_server = localhost
[08:58:31.074767]<rgammans>test smtplib from the python command line works too
[08:59:23.314646]<rts>rgammans: ok, then it should work with trac, too, unless exim locally prohibits relaying, or something like that, you will have to set up trac.ini/[notifications] so that it will use the correct domain and so on
[08:59:58.637745]<rgammans>rts - it doesn't even attempt to connect to exim
[09:00:34.595095]<rts>hmpf, christian do you have clue on this, i am out of wits right now
[09:01:35.358566]<rgammans>new check is the same as the old according to diff -urN --exclude .svn --exclude dist --exclude '*egg-info'
[09:03:03.700578]<rts>rgammans: please have a look at trac.notification.py and the options that can be set in the configuration file, perhaps you are missing some point there?
[09:03:43.540718]<rgammans>rts: will do but I don't thin that control flow is getting that far.
[09:04:27.619462]<rts>rgammans: you are right, if the acct_mgr plugins stops short when calling AccountManager for notification of change, then it will never reach that point
[09:06:37.004962]<rgammans>Ahah. acct_mgr.notification.py is not being called . - I put f=open("/tmp/trac-notify") at the bottom of the file and /tmp/trac-notify is not being created.
[09:07:28.680893]<rts>rgammans: perhaps replacing existing code in _notify by AccountChangeListener(self.env).[user_%s] would do the trick,and if so, it is still to be determined why the ExtensionPoint fails
[09:07:38.939371]<rgammans>oh hang on. I need to install it too. D'oh
[09:08:57.871155]<rgammans>no notifications.py is lodaed - trying your idea....
[09:09:28.166643]<rts>rgammans: örks
[09:12:50.421525]<rts>rgammans: is there any hint in your trac.log file stating that the AccountChangeListener plugin has been loaded into the system?
[09:13:41.635115]<rgammans>rts - funny you should say that, I did have this :- 2010-04-25 17:12:46,312 Trac[__init__] DEBUG: Loading acct_mgr.notification from /home/roger/bin/trac11/lib/python2.4/site-packages/TracAccountManager-0.2.1dev_r7731-py2.4.egg
[09:14:12.670594]<rgammans>but trying your change I'm provoking this maessage- 2010-04-25 17:12:46,293 Trac[__init__] ERROR: Skipping "acct_mgr.admin = acct_mgr.admin": (can't import "cannot import name IAccountChangeListener")
[09:15:07.184558]<rts>rgammans: well, maybe you need to from acct_mgr.notification import AccountChangeListener?
[09:15:37.007079]<rgammans>possibly ...
[09:17:16.581211]<rts>rgammans: and AccountChangeListener(self.env).[user_%s] was only a place holder, so you eventually will have to replace [user_%s] with the method that you would like to call *just to make sure, duck*
[09:17:50.196414]<rgammans>I used something based on the getattr(.._) call inside the loop
[09:18:17.481825]<rts>rgammans: yeah, guessed that already, just for the public ;)
[09:18:52.980030]<rgammans>but I can't get the new module to load... Hm
[09:19:10.820235]<rts>rgammans: restart apache?
[09:20:09.452445]<rgammans>no, or rather yes i'm doing that as I go alongtoo
[09:21:17.082678]<rts>rgammans: hell, remote irc debugging is quite difficult *g
[09:22:48.524665]<rts>rgammans: if you have restarted apache, does the module work as expected or is it still not executing?
[09:22:58.859064]<rgammans>Still debugging, hang on...
[09:23:16.942304]<rts>rgammans: plenty of time here...
[09:24:32.254033]<rgammans>Still not executing - it the import line - but I was importing '*' I'm going to chnage it to AccountChnageListener
[09:24:49.348322]<rts>rgammans: btw. on the website it states that current trunk is for trac 0.12 , dunno if that would help
[09:26:17.453555]<rgammans>no still can't make the import line do any good.
[09:27:38.022578]<rgammans>Hmm
[09:28:37.704582]<rts>rgammans: never mind, it should work right out of the box,
[09:28:50.369321]<rts>rgammans: i just installed it and see what i can find out
[09:29:16.895261]<rgammans>cool
[09:32:05.826688]<rgammans>It odd though 'from acct_mgr.notification import AccountChangeListener' get 'no handler matched request to '/reset_password' - and just commenting it out works - until you fill the form in then in compains about 'global name AccountChangeListener not defined' - that last not being surprising
[09:38:58.046493]<rgammans>ahh that import line causes a cicular import - it sems to work at the bottom of api.py though
[09:42:26.034226]<rgammans>work - in the sense that I get a different error "'PasswordResetNotification' object has no attribute 'log'"
[09:42:36.263071]<rgammans>butI could have done that.
[09:44:11.431870]<rgammans>or maybe not.
[09:49:15.013671]<rts>rgammans: do you have similar entries in your log file?
[09:49:18.671999]<rts>2010-04-25 18:46:59,257 Trac[web_ui] WARNING: AccountModule is disabled because the password store does not support writing.
[09:49:18.768903]<rts>2010-04-25 18:46:59,257 Trac[web_ui] WARNING: RegistrationModule is disabled because the password store does not support writing.
[09:49:27.781959]<rgammans>um yes.
[09:49:44.902775]<rgammans>But it /does/ write to the password sotre
[09:51:00.356118]<rgammans>Ok. No I've debugged it and fixed my logging additions our extra line in api.py does make it send the emails
[09:51:44.318033]<rts>and do you have something like:
[09:52:03.037246]<rts>2010-04-25 18:49:03,747 Trac[web_ui] DEBUG: /reset_password
[09:52:03.050644]<rts>2010-04-25 18:49:03,747 Trac[web_ui] WARNING: AccountModule is disabled because the password store does not support writing.
[09:52:57.546530]<rts>rgammans: where the debug message on reset_password was introduced by me in web_ui.AccountModule#match_request
[09:54:29.597179]<rgammans>Do you want me to add a match debug then?
[09:54:34.215911]<rts>rgammans: so if it is now writing out the emails, great, but why would the extension system of trac not return all available extensions to the extension point?
[09:54:52.517288]<rgammans>rts - That the $60,000 question
[09:54:55.342782]<rts>rgammans: if it is now working, fine, it is just with my local configuration
[09:59:27.460130]<rgammans>hmm now mysql has hung...
[10:00:41.379775]<rts>rgammans: good luck with that, i will now dig in to something else ;)
[10:04:02.832967]<cboos>osimons: it looks like we don't do a commit after each upgrade_environment
[10:04:09.499842]<cboos>we actually explicitly say we don't
[10:04:20.606629]<cboos>I wonder if that's not bogus
[10:04:41.542817]<cboos>each upgrade environment should probably be atomic anyway
[10:06:58.586807]<macmaN>i dont think osimons is around
[10:07:01.153557]<macmaN>is he?
[10:07:23.477565]<cboos>no idea, saw him in the list of participants
[10:07:43.728006]<macmaN>looked for him tad earlier
[10:08:00.873177]<cboos>it's a question he's interested in; Bitten had at least one issue related to that
[10:22:40.447101]<macmaN>i also got something to show him
[10:22:46.270032]<rts>cboos: have you read my comment on with_transaction the other day? it does not always commit although in the documentation it states that is for single transactions only
[10:23:21.127060]<cboos>rts: the mail from carsten klein on trac-dev?
[10:23:33.785482]<rts>cboos: yes, that is me
[10:24:22.946314]<cboos>well, I've read it only superficially, sorry
[10:24:51.510159]<cboos>let me find it again
[10:26:17.459882]<cboos>for the Container Managed Transaction, you need to realize that what we want are short lived transaction (as short lived as possible), see #3446
[10:26:33.794172]<cboos>so having a transaction running during the whole duration of a request is out
[10:26:47.903185]<rts>^^sure, never mind, was just a suggestion
[10:27:59.268498]<rts>cboos: hint, it was also about postgresql connections remaining in idle in transaction
[10:28:11.298547]<cboos>now for the other one, it looks like you're suggesting a systematic commit or rollback, which defeats the purpose of nesting with_transaction calls (only the outer ones does a commit - the inner ones can still do a rollback after an error)
[10:28:30.910001]<cboos>s/outer ones/outer one/
[10:28:30.919946]<evil_twin>cboos meant: now for the other one, it looks like you're suggesting a systematic commit or rollback, which defeats the purpose of nesting with_transaction calls (only the outer one does a commit - the inner ones can still do a rollback after an error)
[10:29:20.687026]<cboos>anyway, #8443 was there /before/ the whole with_transaction business ;-)
[10:29:25.122251]<rts>cboos: *lol evil_twin is really evil*
[10:29:48.171310]<cboos>well, it's a faeture
[10:29:53.368808]<cboos>s/faeture/feature
[10:29:53.411906]<evil_twin>cboos meant: well, it's a feature
[10:29:56.963380]<cboos>;-)
[10:30:14.648372]<cboos>@dance
[10:30:25.859373]<rts>cboos: apart from that maybe some of the code will call with_transaction with a correctly set up db connection and some won't. in the previous case, the transaction will never be committed.
[10:30:47.589294]<cboos>no ... let me explain
[10:31:36.432175]<rts>cboos: ha evil twin did not get this, it is s/previous/former/ *g
[10:32:56.773226]<cboos>if some (external) code happens to trigger code now using a with_transaction, and the connection is not correctly set up as you say, then this means the code is not with_transaction aware and it will do the commit by itself (i.e. it is legacy code, it uses the pre-0.12 conventions)
[10:33:27.715126]<rts>cboos: however, for my part, i will have to special case with_transaction every time i use it. check whether db is not None and then will have to commit myself
[10:33:38.661844]<rts>cboos: incl. also handling of rollback
[10:34:05.029775]<cboos>no
[10:34:20.915832]<cboos>that's not how the pre-0.12 conventions worked
[10:34:43.059839]<rts>cboos: then i would phave to provide with_transaction with db = None so that it will properly commit and rollback
[10:34:57.671805]<rts>s/phave/have/
[10:34:57.681183]<evil_twin>rts meant: cboos: then i would have to provide with_transaction with db = None so that it will properly commit and rollback
[10:35:39.882087]<rts>just like in windows xp+ : insert something and it tells you that it found something, while you are currently installing it *g
[10:35:45.793995]<cboos>I don't know exactly your situation, but without with_transaction, the convention was: "if you're given a db then, you're part of a more global transaction, please don't commit yourself"
[10:36:18.796237]<rts>cboos: so there is a global transaction for the life time of the request?
[10:36:33.554201]<cboos>no ... global in the sense, someone called you
[10:36:45.618549]<rts>cboos: understood
[10:37:17.148793]<rts>cboos: just like passing a transaction context around, and, in the initial caller, do the commit, then?
[10:37:41.439832]<cboos>yes, e.g. you're writing a burz_insert(db=None), so you insert the burz, and commit only if db==None (someone might insert 10000 burz at a time and hunfsx as well, and want to do that in a single transaction)
[10:38:25.584002]<cboos>so he will call your burz_insert(db) 10000 times, then db.commit(), you shouldn't commit yourself in burz_insert
[10:39:04.292126]<rts>okay, then the documentation on with_transaction should be more explicit, right now it states that it is used with single transactions only, which, in my understanding is @with_transaction and never care about commit
[10:40:24.742916]<rts>*and* perhaps that would be the issue with pgsql connections still being in state idle in transaction, no?
[10:41:29.457120]<cboos>maybe (as I don't know the real cause of #8443, could be anything) ... but I doubt so
[10:41:54.248515]<cboos>#8443 is more related to some bad behavior under load
[10:42:34.346412]<cboos>at some point, there might be just too many threads, and no real work gets done only new threads are created and very quickly go to wait for a db connection
[10:42:37.015016]<cboos>something like that
[10:42:55.625890]<cboos>and the process is at 100% constantly switching threads
[10:43:27.636622]<cboos>we have some interesting/scary/weird strace logs on ftp.edgewall.org/tmp
[10:44:13.850987]<rts>i reckon that even with the proposed patch it would not work correctly, however, we had similar problems with an opensource software over at tarent.de (veraweb).
[10:45:13.772101]<rts>here, after reconsiling everything to apache-commons-pools and dbcp thereof, enumerous errors showed up, incl. also many transactions left in idle transaction state
[10:45:59.259343]<rts>the resolution was here to always commit, meaning to refactor everything so that there would always be a proper try commit() catch rollback() handler
[10:46:23.035915]<cboos>I see,
[10:46:46.717772]<rts>container managed transactions would take care of this, however, it would break with currently installed common best practices
[10:47:02.405160]<cboos>but what if it's simply the thread in the middle of a transaction which never manages to get back some cpu (starvation)?
[10:47:12.422649]<cboos>your solution wouldn't help
[10:47:47.733158]<rts>hm, maybe, but i would not think so, unless that thread was locked/suspended up somehow, as you have mentioned in your comments on that ticket
[10:49:02.412482]<rts>but then again, what would make that thread starve, or lock up, so that it will never succeed? - in trac i do not see any locking mechanism that would introduce such dead locks, correct me if i am wrong
[10:49:18.221522]<cboos>yes, with the usual expectations, things should just work; threads wanting to get a db connection get to sleep, then the other threads are completing, releasing the lock, some new thread gets the connection,etc.
[10:49:27.182968]<cboos>which is the case *most of the time*
[10:49:38.525087]<cboos>but sometimes, not so.
[10:50:12.567512]<cboos>and in those situations, it seems there is always a high load and > 100 threads, new threads being created all the time
[10:50:55.733353]<rts>but if a thread got hold of a connection and initiated the transaction, then it should also commit the transaction, which is currently not the case, or are there any premature connection being closed errors on the line?
[10:51:33.467748]<cboos>unless it never gets the CPU back,
[10:51:41.054023]<cboos>maybe this is just a problem with the way the fcgi is too eager to accept new connections and create new threads, regardless of the current load
[10:52:21.319821]<rts>we also had this problem with long running transactions, which basically meant optimizing using hand crafted sql, but i do not see where in trac this would be the case, since bulk updates or generally, bulk operations are rather sparse
[10:53:21.473195]<rts>we actually use a custom orm here :)
[10:54:17.019372]<cboos>regarding with_transaction's documentation
[10:54:26.546847]<rts>okay, so that fcgi is too eager would mean that some threads are not getting the cpu time that they would need in order to commence the transaction, but that seems rather odd, since linux is duefully capable of handling +10000 thread or more (just guessing)
[10:54:46.834890]<cboos>ok, there's "simple use-once transactions" which is maybe misleading, but just a few lines down, you have this:
[10:54:52.963985]<cboos>"Nested transactions are supported, and a COMMIT will only be issued when
[10:54:58.465317]<cboos>the outermost transaction block in a thread exits."
[10:55:14.674491]<rts>okay, never read that far, hey, i am a developer *g
[10:56:14.320742]<cboos>rts: regarding your summary above for #8443, yes, that's what I think is the most likely explanation (at this point)
[10:56:35.274222]<rts>cboos: oh i must reread this, having forgotten my point
[10:56:35.968117]<cboos>but if Linux is capable of handling lots of threads, maybe not Python ...
[10:57:44.196195]<cboos>anyway, if you're a Linux guru (or if one is hanging around, I have a *really* weird strace to show ;-)
[10:58:50.654099]<rts>oh, i will look into this, but i am not a guru ;)
[10:59:24.965514]<cboos>ah! here's the *real* one I was talking about ;-)
[10:59:37.525322]<rts>cboos: basically my point was about handing out too many connections to a single thread, but that was with our implementation of the db layer
[11:00:41.205952]<rts>cboos: lol
[11:01:35.760662]<rts>cboos: it the strace available in tmp?
[11:01:40.374108]<cboos>http://ftp.edgewall.org/tmp/weird-strace-4388.log
[11:02:10.748533]<cboos>you have 4388 which is the main thread (trac.fcgi in ps -ef)
[11:02:24.771849]<cboos>it's basically doing accept and clone
[11:03:19.186397]<cboos>... and the cloned threads basically do only set_robust_list (normal, that's the first thing every new thread does), then shutdown (?), then close, then exit ...
[11:03:25.839410]<cboos>nothing else
[11:03:28.317895]<cboos>repeat
[11:04:06.449367]<cboos>with *lots* of threads - voila, kind of live lock, no wonder the threads with pending transaction don't progress in this situation
[11:04:22.710749]<rts>counting on the number, perhaps this would have been an attack?
[11:05:33.430951]<cboos>rts: please catch retracile's attention on this and re-explain ;-) during that time I'll have lunch ... (hi eli)
[11:05:42.794503]<rts>;)
[11:05:46.258923]<retracile>cboos: heh... I'm about to head to lunch myself
[11:06:04.204889]<_cboos>and eating prevents you to *think*?
[11:06:04.372765]<retracile>Grabbed a copy of the strace; I'll try to look at it later today.
[11:06:16.683946]<_cboos>he he, thanks! ;-)
[11:06:22.318630]<retracile>_cboos: nah, but it _is_ a prerequisite ;)
[11:07:13.371482]<rts>_cboos: lunch that late in the day?
[11:08:41.735145]<rts>retracile_: personally i would presume that either the server stalled, prematurely closing any connections, or that an "attack" was taking place, opening many connections at once
[11:08:59.190352]<rts>retracile_: what do you gather from the strace?
[11:09:56.096954]<rts>retracile_: especially more so with the time stamps associated with each allocated futex
[11:14:52.317836]<rts>_cboos: but judging by the timestamps each futex was allocated, i would rather think that it was a local test case, since we are talking microseconds here
[11:42:40.757547]<rts>regarding http://trac.edgewall.org/ticket/8443#comment:34 perhaps installing a general on_exit handler would do the trick, for the currently processed request that is
[11:43:43.386542]<rts>so that all transactions get committed, or, as proposed in the ticket, to rollback, since the request was cancelled
[12:19:43.673133]<rts>there was some trac clone out there, which one was it again?
[12:20:22.018462]<rts>was it redmine or are there still others that i have missed?
[12:21:47.879759]<osimons>_cboos: back now. as for upgrades, in bitten we now commit for each upgrade number and update the version also for each. that makes us only deal with erros in one upgrade at a time.
[12:23:12.694963]<osimons>for db only we may have got around it, but seeing upgrades also touch config (trac.ini) and the bitten log files, there really isn't a rollback possibility once we leave the upgrade routine
[12:25:15.020369]<rts>osimons: like in http://paste.lisp.org/+23VC - that is work i have done for the suite of plugins that i am currently developing, part of which code was directly taken from trac. namely that which would dynamically include the upgrade module
[12:25:57.532219]<rts>osimons: however, mine would not affect the configuration file
[12:34:51.557312]<osimons>rts: in bitten, one example is the upgrade when we moved to putting build logs in individual files instead of records in the db. the database containing may contain 1000s of builds, each with a number of steps. each step produces a log. moving this to files is a big operation, and non-trivial. cleanup involves rolling back things created on disk outside config and outside db
[12:35:27.806208]<rts>osimons: oh well, dear, i see, that is sort of a problem
[12:35:30.345921]<osimons>- and if anything fails in later upgrades in trac or whereever (run as part of a larger upgrade), there is no way to detect the end result and rollback anything
[12:36:14.844260]<rts>osimons: perhaps postponing dropping the tables until that everything got migrated to the file based logging facility would do the trick?
[12:36:33.252092]<osimons>rts: how?
[12:37:08.017779]<osimons>once execution leaves our upgrade routine, there is no turning back and no way to know if the end commit succeeds or not
[12:37:46.772620]<osimons>so our upgrade may work, but then some trac upgrade 23 fixing multirepos support fails, and rolls back our log table drop.
[12:39:19.468990]<rts>osimons: hm, db = valid_db_cnx ... @with_transaction do whatever is needed to update the db, then migrated everything to file based storage, and then, on except: remove file based storage, rollback
[12:39:42.992526]<rts>in @with_transaction, also commit
[12:40:15.972861]<rts>osimons: now i see, your upgrade is dependent of a trac upgrade?
[12:41:17.083563]<rts>perhaps the upgrade path for trac should be slightly revamped, making it sort of an application controlled transaction, would that do the trick?
[12:41:23.679764]<osimons>rts: not dependent, but is is an upgrade just like any other upgrades
[12:42:16.812942]<osimons>rts: the typical scenario is often some revamped packaging sytem that now contains all new release of trac + various plugins. so an upgrade may be 10 actual upgrade routines run in one go
[12:43:09.425172]<rts>otoh if for example ISetupParticipant, which is called by AFAIK Environment on both creation and upgrade, would require the participants to join a global transaction, which is actually a distributed one
[12:43:52.860557]<rts>with parts of it going into the database and parts of it also going into for example the configuration file, then we would have two clearly defined use cases, for which one could easily define a transaction manager for
[12:44:59.013974]<rts>so the global setup participant, which is environment, would then control the overall transaction, incl. also any commits and rollbacks (sigh back to container managed transactions 'gain *g)
[12:45:01.648005]<osimons>rts: in my mind this is all really simple, and each upgrade routine should just be responsible for committing or excepting its own work.
[12:45:19.117949]<osimons>the global transaction joining all upgrade routines makes no sense to me
[12:45:35.206535]<rts>yeah that is the assumption i have made in my upgrade routine
[12:46:03.493517]<rts>especially more so since it requires previous upgrades to be installed prior to that the most recent upgrade is being installed
[12:46:20.308136]<rts>they are all defined differentially, sort of
[12:46:33.962144]<osimons>rts: meaning also that once execution leaves the plugin upgrade, it is guaranteed to be committed. no surprise rollbacks for exception later in the chain
[12:47:22.938609]<rts>osimons: yes, that the requirement
[12:47:48.503746]<rts>s/that/that was/
[12:47:48.513253]<evil_twin>rts meant: osimons: yes, that was the requirement
[12:48:08.161577]<rts>may i say that evil twin just sucks ;)?
[12:48:52.910710]<rts>s/i/o/
[12:48:52.919883]<evil_twin>rts meant: may o say that evil twin just sucks ;)?
[12:49:31.301909]<rts>but it is funny, anyhow, see how it will cope with this
[12:49:38.614767]<rts>s/i/a/g
[12:49:38.623773]<evil_twin>rts meant: but at as funny, anyhow, see how at wall cope wath thas
[12:50:53.744370]<rts>s/wath thas/wrath t'has/
[12:51:01.267210]<rts>ha, got ya
[12:51:53.340980]<rts>sry. for diverting...
[12:56:12.092381]<macmaN>osimons: ciao
[12:56:29.325082]<rts>osimons: consideren 10+ upgrades in one go, each upgrade, like you stated, must be self sufficient in that it will either commit or rollback, no inter dependencies between plugins allowed here, except individual plugin upgrade routines checking for availability of for example a given system variable stating which version of that plugin was installed?!
[12:56:47.473257]<rts>s/consideren/considering/
[12:56:47.484200]<evil_twin>rts meant: osimons: considering 10+ upgrades in one go, each upgrade, like you stated, must be self sufficient in that it will either commit or rollback, no inter dependencies between plugins allowed here, except individual plugin upgrade routines checking for availability of for example a given system variable stating which version of that plugin was installed?!
[13:02:07.840700]<osimons>rts: i think it would be a simple patch to trac. instead of the global transaction, it just loops the participants calling upgrade passing db, and on return it commits whatever the participant has done. inside each participant, it is free to do as it likes (like bitten does committing and updating version between each upgrade routine)
[13:03:22.258744]<rts>osimons: afaik it uses @with_transaction, correct me if i am wrong, and doing that with a properly set up connection, it will never automatically commit nor rollback
[13:04:34.757766]<osimons>rts: i haven't moved to proper 0.12 development yet, so haven't actually looked at or written such code... i'm talking pseudo-code and not implementation details :-)
[13:05:20.215586]<rts>osimons: so perhaps you are right, commit should go into the outermost calling routine, however, in case of plugins defining their own upgrade path, which may be so defined that it is differential, then these plugins, also, need to do commits on their own, don't you think?
[13:06:25.918212]<rts>osimons: just in the routine i previously posted on pastebin. it would not work with the container, aka trac Environment, taking over sole responsibility for the transaction
[13:06:48.638309]<rts>s/just in/just like in/
[13:06:48.648645]<evil_twin>rts meant: osimons: just like in the routine i previously posted on pastebin. it would not work with the container, aka trac Environment, taking over sole responsibility for the transaction
[13:08:41.128825]<osimons>rts: yes, but if they don't the setup manager in env will commit each one in turn - like for bitten there would be no uncommitted changes seeing it commits all its own work, but it would make it compatible with existing upgrades that don't explicitly commit.
[13:09:55.341243]<rts>osimons: i do not actually see the point where bitten, being a plugin in itself, would require other plugins to commit first on environment upgrade? perhaps i am missing something?
[13:11:25.641617]<osimons>rts: huh? all i've said is that bitten ignores the common practice of not commit when you are passed the db (or in a transaction) - that means in theory bitten may commit work done by other plugins too
[13:11:43.595671]<rts>osimons: never have tried out bitten, but i will in the future, for now it is all guessing and provisioning of best practices from a noob ;)
[13:12:18.297603]<rts>osimons: oh that is your case, maybe then plugin authors should be reminded to commit their work on upgrade?
[13:12:22.366558]<osimons>rts: http://bitten.edgewall.org/browser/trunk/bitten/upgrades.py
[13:13:33.734880]<osimons>rts: yes, sort of. but as trac code currently is, that is against the best pracice. i've decided to ignore that though, but i won't enourage others to do so... better then that we fix the rules laid out by trac env create/upgrade.
[13:14:35.750526]<osimons>rts: the main part: http://bitten.edgewall.org/browser/trunk/bitten/main.py?rev=#L32
[13:14:44.987837]<rts>osimons: ok, well, yes, a different approach with that look up table, but equal to what is defined in trac, except that trac makes it a bit more versatile, dynamically instantiating upgrades from the upgrades/ package
[13:16:41.836787]<rts>osimons: and, employing the scheme i proposed in the pastebin i posted, you would be happy to go with simply defining yet another db<N>.py in your upgrades folder, just like in trac, but more flexible, once you have found the bugs that i didn't ;)
[13:16:42.432258]<osimons>rts: same thing, yes. one file vs many files is just personal preference
[13:17:26.953663]<rts>hm for the above link i get only a blank blackened screen ;) is that on purpose?
[13:17:56.809053]<rts>ah in firefox it works, seems like konqueror has some problems here
[13:18:56.449030]<osimons>http://trac-hacks.org/browser/fullblogplugin/0.11/tracfullblog/db.py is another of my plugins. there db.py contains schema + upgrades keeping all contained. the one upgrade per file is overkill imho (for all regular plugins)
[13:19:17.889708]<osimons>however, personal preference
[13:19:41.845801]<rts>osimons: well that is the difference between yours and mine, you will always, just like in track, a recent version of the schema, whereas i will only keep the difference, so that i am required to upgrade from schema 1 to N during one environment create or
[13:19:53.700184]<rts>during an upgrade vom N-M to N
[13:22:35.632645]<rts>s/vom/from/
[13:22:35.641881]<evil_twin>rts meant: during an upgrade from N-M to N
[13:24:02.789943]<osimons>rts: read your paste now, and see what you mean. right. either is fine by me, really. a clean schema is usually less error prone and faster, but yours should work too - although a bit harder to read what the actual current schema looks like
[13:24:57.911255]<osimons>however, once time passes, there is no telling what errors a 5 year old upgrade script may cause in a new install...
[13:25:03.907405]<rts>osimons: of course, that is not bad, considering it once again, since you always have the full fledged schema at hand, whereas i will not, so i will reconsider my approach somehow
[13:26:01.848082]<osimons>rts: don't get me wrong though, in the evolution of software i think evolving from a version 1 makes sense
[13:26:46.956682]<rts>osimons: btw does bitten support plugins? i means such as test coverage or documentation coverage or even code style?
[13:27:28.690076]<osimons>rts: sure. tests, coverage and lint is supported for major platforms
[13:27:56.021240]<rts>great, i will definitely give it a shot in the next weeks
[13:27:56.105335]<osimons>rts: and further, bitten even provides unittest for upgrades... http://trac-hacks.org/browser/fullblogplugin/0.11/tracfullblog/db.py
[13:28:30.076747]<osimons>like your paste, we create the initial schema in tests, and then we upgrade each one in turn to make sure they always work...
[13:28:49.785354]<osimons>how cool is that :-)
[13:29:14.806475]<rts>osimons: cool
[13:29:44.586552]<rts>osimons: except, erm, i did not test ;)
[13:30:10.240741]<rts>osimons: just took the axe out and flung it against the machine...
[13:31:29.376520]<osimons>rts: oh dear...
[13:32:23.115253]<rts>osimons: i am rather new to python, therefore i need to take my steps in turn, testing is due for a plugin of mine right now, but that requires an additional step of learning, so ...
[13:34:47.152213]<macmaN>osimons: check msg?
[13:34:58.289741]<osimons>rts: lots of nice things done, but takes time to get the overview and work with the learning. keep it up :-)
[13:35:05.616496]<rts>okay, hope you point is still unresolved, so you can discuss it with christian, i for myself am now off, hopefully getting some sleep here (too many flights the night since the european union opened up again)
[13:35:14.662629]<rts>thx, you too, cya