I'm sure some timeout value is needed, but this is a problem. I lost about an hour's worth of work because of it.

One way to mitigate timeout problems would be to create a "Save Draft" function, much like the one Discogs has. This would be especially helpful for entering complicated releases (e.g., length, multi-disc, VA, classical-music releases).

A "save draft" function would be nice to have in any event.

I second the suggestion for a "save draft" feature. I have lost over an hour's work entering a Release of an opera recording because I couldn't get the track list entered in time. There is a workaround – write up the track list in advance in another file, then start the Add Release wizard and quickly copy/past completed track titles from the other file – but it would be better if we could save drafts.

While save draft would be useful; there are many complexities with getting that to work which will already break the release editor. e.g. cached row IDs or MBIDs which may be gone/merged/whatever by the time you press submit - there is currently no workflow to support that kind of thing.

I personally think that's a sledgehammer approach to this specific problem. The better approach IMO, is to see if it can be redesigned to make sure all required state for submission is client-side while you navigate the form; not relying on the server-side session state. I've no idea whether technically feasible though; presumably there was a reason that it's currently dependent on some server-side state.

The plans for a new release editor are entirely client side (as far as state goes)

CallerNo6 reported a release editor crash on IRC today. Going through the logs around the time of this error I found this, which may be the cause of that particular crash:

2011-11-28 17:31:50.495995500 [error] Caught exception in engine "Couldn't save expires:c1c611ace1febf8bc148e4a72d67ccbce510332b / 1322508709 in memcached storage"
2011-11-28 17:31:50.513682500 [error] Caught exception in engine "Couldn't save expires:b3274601e3fc8de687794dc7c0f03322f4ebe3e7 / 1322508709 in memcached storage"
2011-11-28 17:31:50.761557500 [error] Caught exception in engine "Couldn't save session:30e3e872ea250e130e2620eea5ec83bdcd4f2f71 / HASH(0xdcdb630) in memcached storage"
2011-11-28 17:31:50.761593500 [error] Caught exception in engine "Couldn't save session:2924089e0507a6836e863c43839d73ce7375724e / HASH(0xdbfd580) in memcached storage"
2011-11-28 17:31:50.761756500 [error] Caught exception in engine "Couldn't save session:d33ba73b4192c0166a6145be27474e6014d4fe8f / HASH(0xd328970) in memcached storage"
2011-11-28 17:31:50.761758500 [error] Caught exception in engine "Couldn't save session:5bc87aa22d968e3ab8e078fe61d77b138a268f9e / HASH(0xcec90b8) in memcached storage"
2011-11-28 17:31:50.762572500 [error] Caught exception in engine "Couldn't save session:54eb36089347638cbff71f09659df211ab250de5 / HASH(0xcc89d70) in memcached storage"
2011-11-28 17:31:50.762819500 [error] Caught exception in engine "Couldn't save session:b3a55f5ab00d0ff7b8f7e0cc71a49a998f190677 / HASH(0xe6e7758) in memcached storage"
2011-11-28 17:31:52.037254500 [error] Caught exception in engine "Couldn't save session:d2315f15e9ce12e94b12b3918ad9164e568523c2 / HASH(0xe23cf00) in memcached storage"
2011-11-28 17:31:52.345097500 [error] Caught exception in engine "Couldn't save expires:30ca03bee2e1d51c1c4470b78691f309d9dceb4e / 1322508711 in memcached storage"
2011-11-28 17:31:52.463086500 [error] Caught exception in engine "Couldn't save expires:9f4fbccec06dae856597f011bff680dc551d906b / 1322508711 in memcached storage"

As this issue has been delayed, I am moving it back to be rescheduled.

I'm seeing similar problems with the 502's and ISE's reported today. I'm attaching logs for two incidents.

Out of the 316 cache misses for wizard session keys in the oddlogs for the last 9 hours or so, only 24 are mentioned in the oddlogs for the past few days as being created. So, it appears we have a large number of wizard session keys just springing into existence without a trace.

When the connection to memcached is lost for whatever reason, the release editor will crash. I'm not sure if any attempt is made to reconnect, but obviously that is being done correctly or at all.

irc log with a bit more detail: http://chatlogs.musicbrainz.org/musicbrainz-devel/2012/2012-02/2012-02-01.html#T20-43-41-404006

One crash has been fixed in commit 63db8e3685f077094581fea88c6553c5ec7159e8. beta has been updated with these changes.

If these problems still occur on beta.musicbrainz.org now or musicbrainz.org after the next release, please re-open this ticket.

We had some trouble deploying this fix to musicbrainz.org.

I need to look into Catalyst::Plugin::Session::Store::Memcached::Fast to fix our use of memcached for sessions.

If you finally have once-and-for-all squashed it, it will be effort worth spent!

There's another patch at http://codereview.musicbrainz.org/r/2068/, but I'm not convinced it will solve the edge cases.