ticket,summary,type,release,owner,status,created,modified,_description,_reporter 7442,[Patch] RuntimeError: No Content-Length header set,defect,0.12,Markus Pelkonen,new,2010-07-31T19:31:27+02:00,2011-06-24T09:41:56+02:00,"I used the !BurnDown macro, but instead of showing an SVG graph, it only shows a frame telling me that this !RuntimeError occured. ---- = Auto-generated ticket = ==== How to Reproduce ==== While doing a GET operation on `/tractimevisualizer`, Trac issued an internal error. ''(please provide additional details here)'' Request parameters: {{{ {'targetcomponent': u'BoBa'} }}} User agent: `Mozilla/5.0 (X11; U; Linux i686; de; rv:1.9.2.8) Gecko/20100723 Ubuntu/10.04 (lucid) Firefox/3.6.8` ==== System Information ==== || '''`Trac`''' || `0.12` || || '''`Babel`''' || `0.9.5` || || '''`Genshi`''' || `0.6` || || '''`mod_python`''' || `3.3.1` || || '''`Pygments`''' || `1.2.2` || || '''`pysqlite`''' || `2.4.1` || || '''`Python`''' || `2.6.5 (r265:79063, Apr 16 2010, 13:28:26) ` [[br]] `[GCC 4.4.3]` || || '''`pytz`''' || `2010b` || || '''`setuptools`''' || `0.6` || || '''`SQLite`''' || `3.6.22` || || '''`Subversion`''' || `1.6.6 (r40053)` || || '''`jQuery`''' || `1.4.2` || ==== Enabled Plugins ==== || '''`LightGreenTheme`''' || `0.1` || || '''`timingandestimationplugin`''' || `0.9.4` || || '''`TracThemeEngine`''' || `2.0.1` || || '''`TracTimeVisualizerPlugin`''' || `0.6` || ==== Python Traceback ==== {{{ Traceback (most recent call last): File ""/usr/local/lib/python2.6/dist-packages/Trac-0.12-py2.6.egg/trac/web/main.py"", line 513, in _dispatch_request dispatcher.dispatch(req) File ""/usr/local/lib/python2.6/dist-packages/Trac-0.12-py2.6.egg/trac/web/main.py"", line 235, in dispatch resp = chosen_handler.process_request(req) File ""/usr/local/lib/python2.6/dist-packages/TracTimeVisualizerPlugin-0.6-py2.6.egg/tractimevisualizerplugin/pluginwrapper.py"", line 31, in process_request return impl.process_request(self, req) File ""/usr/local/lib/python2.6/dist-packages/TracTimeVisualizerPlugin-0.6-py2.6.egg/tractimevisualizerplugin/impl.py"", line 426, in process_request req.write(svg) File ""/usr/local/lib/python2.6/dist-packages/Trac-0.12-py2.6.egg/trac/web/api.py"", line 528, in write raise RuntimeError(""No Content-Length header set"") RuntimeError: No Content-Length header set }}}",jonas.lieb@… 8020,0.12 compatibility,enhancement,0.12,Markus Pelkonen,new,2010-11-11T14:33:17+01:00,2010-11-15T08:07:38+01:00,"The plugin TimeVisualizerPlugin should be compatible with latest 0.12 release without code changes. See also: #7442 ",Mikko Rantalainen 6802,Performance improvement: draw less lines to svg,enhancement,0.11,Markus Pelkonen,new,2010-03-13T14:57:21+01:00,2010-03-13T14:57:21+01:00,"Current implementation draws all the ticket changes, no matter how small the change is. E.g. If one draws burndown of a project which has 5k tickets and 100k ticket changes, it will easily end to svg with thousands of lines which are not noticeable by end user. It is huge hit to server, may end to big data amounth to be sent over network and also slows down browser. Drawing could be improbed to take only ""visible changes"" or abstract drawing somehow. One option could be to draw trend with average values, e.g. 20 bars representing the graph.",anonymous 6795,Implementation doesn't scale to huge production environments,defect,0.11,Markus Pelkonen,new,2010-03-11T16:08:22+01:00,2010-03-12T11:57:20+01:00," > I've installed it in my Trac test environment, with a production > database, but it seems unreasonable slow and I just wanted to make > sure I'm not using it wrong. It always seem to loop through the > entire ticket_change table although I specify an time interval. > Does it lookup all entries in ticket_change and then filter out > what's not of interest? I knew this would pop up to my face at some point :) Unfortunately my own projects using this addon didn't ever grow enough big (Biggest had only ~ 600 tickets). IIRC, implementation crawls the whole history and builds ""version history"" on the fly. With a lot of tickets and ticket changes, it definitely will slow down. And if graph is interested only small portion of changes, this crawling should be avoided. At some point I had idea to store snapshots of ticket data. Graph rendering would then take closest snapshot and build ticket history only from that point. E.g. if there was snaopshot from every 1 week, then rendering 2 week graph from the middle of middle of 4 year project should hit ticket changes from 3 week period. This would require own table (for snapshot data) and more thinking exceptional cases (e.g. which fields to store to snapshot, how to handle cases when new fields are introduced in the middle of project, etc). However, deciding how often to store snapshots would come interesting. Should it be static period or could it be just something like ""every N ticket change"", which could be configurable value (and default to 1000 or something)? However, i should check if implementation unnecessarily processes data beyond begin time. E.g. if two last weeks are in interest in the huge datase, it still should render quite quickly. -- Mape",anonymous 3054,Namespace issue in impl.py for TracTimeVisualizerPlugin,defect,0.11,Markus Pelkonen,new,2008-05-20T19:15:14+02:00,2008-05-20T19:15:46+02:00,"Using Trac 0.11b2, Apache 2.2.3, Apache-mod-python 3.1.3, Python 2.4.2, SuSE 10.1, !TracTimeVisualizerPlugin 0.6. We've slowly gained inertia using Trac, and came across your plugin as a useful addition. Installed from an egg, but the visualization generation wouldn't work - it would return a single file with two XML documents, the first being the SVG image, but second an error. The following apache error log clued us in: {{{ [Mon May 19 15:32:45 2008] [error] [client 75.142.123.92] PythonHandler trac.web.modpython_frontend: File ""/usr/local/lib/python2.4/site-packages/TracTimeVisualizerPlugin-0.6-py2.4.egg/tractimevisualizerplugin/impl.py"", line 427, in process_request\n raise trac.web.RequestDone [Mon May 19 15:32:45 2008] [error] [client 75.142.123.92] PythonHandler trac.web.modpython_frontend: AttributeError: 'module' object has no attribute 'web' }}} We're not terribly familiar with Python, but from what I understand the your code ( {{{ raise trac.web.RequestDone }}} ) ''should'' work - it's resolving, or should be, the correct class. For whatever reason, it can't resolve. To '''fix''' this we added {{{from trac.web import RequestDone}}} to the import statements at the top of the file, which then allowed {{{return RequestDone}}} to work on our machine. The issue could be specific to our setup, I don't know offhand. Thanks for your effort on this plugin.",jhamell@… 2291,Improve command line usage,enhancement,0.10,Markus Pelkonen,new,2007-12-11T19:41:50+01:00,2008-04-10T02:55:42+02:00,Current command line usage uses hard coded values. Consider taking Trac environment as first argument and pass options from command line to render function.,Markus Pelkonen 2753,Make graph interactive,enhancement,0.10,Markus Pelkonen,new,2008-03-17T20:36:38+01:00,2008-03-17T20:36:38+01:00,"Take ideas from http://www.panopticode.org/gallery/index.html When one clicks the graph, a new tab/browser could be opened with the ticket that affected change in graph. Unfortunately it is quite common to update ticket statuses at end of day, thus all changes are in one and same place in the graph. More advanced approach would be to open query view, where all 'nearby' tickets would be listed. 'Nearby' time delta should be configurable. By default it could be 1% of the graph width.",Markus Pelkonen 1971,Multi milestone chart,enhancement,0.10,Markus Pelkonen,new,2007-08-24T11:24:15+02:00,2008-03-16T13:42:10+01:00,"Tanks for a good plugin (even as startup). I try to make complete development environment around Trac. It will run as a multi project and feature reach staff and it is good in its front page to see project's activities and some work history (see: http://ethercom.sogodi.com:9999/projects - connection could be slow). I plan to invoke chart generated by timevisualizerplugin from tram plugin's web front-end. So it is good idea to generate chart with all milestones for given project (with some kind of legend of course). If it is interesting for you I can collaborate to make your plugin better.",Christo Radev 2321,Smart (re)sync hook,enhancement,0.10,Markus Pelkonen,new,2007-12-18T22:18:42+01:00,2007-12-18T22:18:42+01:00,"I was thinking if post commits are needed at all. Trac admin can be used to resync changesets. I could consider writing patch/plugin, which would hook that process, clear ticket old ticket entries for each synced revision and rewrite log for ticket. This would handle also situation where one changes svn commit message afterwards... Well, this has quite little to do with timevisualizerplugin - until hook would parse estimated / total hours...",Markus Pelkonen 2320,trac db obfuscator,enhancement,0.10,Markus Pelkonen,new,2007-12-18T22:12:27+01:00,2007-12-18T22:12:27+01:00,"When mentoring/teaching, it would be nice to refer to 'real' production environments. Unfortunately projects may have tight disclosure agreements and this practically kills the whole idea. If there was a script rendering 'human readable' texts to 'lorem ipsum', then there could be option to demonstrate concept, e.g. statistical data (burndown graph), milestone (sprint) usage, ... Script should be configurable so that one could define which fields to obfuscate. Attachments should be probably deleted, because filenames could reveal secrets... When one reports defect, it would be also nice to have the actual db for debugging purposes... For example my large project burndown leaks a bit, but I can't post it here as reference...",Markus Pelkonen 1977,filtering with milestone and component may give wrong results,defect,0.10,Markus Pelkonen,new,2007-08-26T13:50:29+02:00,2007-11-26T22:19:49+01:00,"Trac & 3rd components may change milestone name or component name without writing that to `ticket_change`. This in turn messes the graph if filtering is used for milestone or component. For details, see my post [http://trac.edgewall.org/ticket/5658#comment:7 Trac#5658]. This is unpleasant news to scrum people using my plugin. A workaround is * not to retarget tickets when closing milestone but moving each ticket manually from ticket page * not to use webadmin to milestones * not to change component names (ever) Please feel free to document any other similar cases. Unfortunately there is no good fix for this problem. The original idea of using ticket_change has to be probably abandoned. Other possible approach could include (not tested): * writing set of listeners (ticket, milestone and component) and ensuring that history is properly written * using traditional burndown plugin approach: taking snapshots of estimates and totalhours at certain times (however, only polling would be 100% reliable due there are no listeners for all kind of events which would end up with unreliable graph) ",Markus Pelkonen