504 Gateway Timeout

[Ryan J Ollos]

With 6587 spam entries, submitting Delete > 90% results in a 504 Gateway Timeout error. I review spam entries daily, and 6k entries commonly accumulate in a 24 hour period. I've seen this error for the past several consecutive days. As a workaround I delete entries on page at a time.

[Dirk Stöcker]

That's the simple fact that the webserver closes long-standing connections after some time. The main issue here is the speed of the server/database. For JOSM I can use that function to delete up to 100.000 entries without problem.

The abort does not affect function, so the error is harmless. Progress is not lost on abort.

Solution: Speedup database, call function more often or recall after the abort.

Speedup of the function itself would mainly mean loosing the possibility to do parallel access. That we had in the past and it caused much more trouble.

[Christian Boos]

By the way: the User admin panel suffers from a similar issue, that's why I disabled it some time ago.

There's a single request fetching all session info, which can be a lot here on t.e.o.

Hm, looks like it's no longer disabled… trying to get there leads to:

Traceback (most recent call last):
  File "/usr/local/virtualenv/1.1dev/lib/python2.7/site-packages/trac/web/main.py", line 594, in _dispatch_request
    dispatcher.dispatch(req)
  File "/usr/local/virtualenv/1.1dev/lib/python2.7/site-packages/trac/web/main.py", line 251, in dispatch
    resp = chosen_handler.process_request(req)
  File "/usr/local/virtualenv/1.1dev/lib/python2.7/site-packages/trac/admin/web_ui.py", line 108, in process_request
    provider.render_admin_panel(req, cat_id, panel_id, path_info)
  File "/usr/local/virtualenv/1.1dev/lib/python2.7/site-packages/tracspamfilter/adminusers.py", line 112, in render_admin_panel
    users, stats = UserInfo.getinfo(self.env, mode if mode != 'unusedmulti' else 'unused', minwiki)
  File "/usr/local/virtualenv/1.1dev/lib/python2.7/site-packages/tracspamfilter/users.py", line 212, in getinfo
    for author,field,oldvalue,newvalue,ticket in env.db_query("SELECT author,field,oldvalue,newvalue,ticket FROM ticket_change"):
  File "/usr/local/virtualenv/1.1dev/lib/python2.7/site-packages/trac/db/api.py", line 122, in execute
    return db.execute(query, params)
  File "/usr/local/virtualenv/1.1dev/lib/python2.7/site-packages/trac/db/util.py", line 129, in execute
    rows = cursor.fetchall() if dql else None
MemoryError

(and so it's not a query on session but on the whole ticket_change table, not really better ;-) )

[Ryan J Ollos]

Replying to cboos:

Hm, looks like it's no longer disabled… trying to get there leads to:

I think that happened because I enabled all Components after the upgrade so that we'd get a few additional spam-fighting services. Just now I disabled it again. I never navigate to that page on the Edgewall sites, but ran into the same issue when helping the jQuery team with their Trac site. I think the issue was improved by purging anonymous sessions. There was a similar issue with ​AccountManagerPlugin before paginating the table on the users page.

I plan to look into the issue I reported in this ticket, but it's less of a priority now since the number of entries I see each day is down to less than a hundred again. The spike to thousands seems to have been temporary, immediately following the server move.