Should say - this is maus-app started in the usual way, like

python src/maus-web/manage.py runserver localhost:9000

Probably difficult to debug at distance, but just so you are aware of the issue...

That may have been because the web client left the website before thumbnails were generated.

Out of curiosity, I created 100 fake .eps files just to see what would happen and those errors would generate if I left the webpage. Do you get it in normal running (keeping in mind this is a prototype)?

And as Chris Rogers says, we're only running the demo server until we setup something more 'professional'/'secure'

I left it running over lunch and haven't been back down to the control room since like an hour ago. I just phoned Yordan - he was on the other onrec machine, so the only activity probably was me logging in by ssh from my office (just before making the log file).

I should say, just before scp'ing out the log file - that has been taking data over lunch.

OK, I've occasionally seen that one too, usually when getting impatient and hitting refresh too many times. It's a Django-web browser "quirk" (partly a side-effect of using their "development server" instead of a proper web server. It occurs when the browser breaks the connection while the server is still sending data.

There's a (closed) Django ticket about it at, https://code.djangoproject.com/ticket/4444, with the pertinent comment being:
---
The reason for this patch is not to 'fix' the broken pipe issue. As it's not really an issue. But there seems to be a lack of clear consensus on how serious this is.

According to many sources the 'Broken Pipe' is a normal browser quirk. For example, the browser reads from the socket and then decides that the image it's been reading pparently didn't change. The browser now this (forcefully) closes the connection ecause it does not need more data. The other end of this socket (the python runserver) now raises a socket exception telling the program that the client 'Broke the socket pipe'.

If this is really only a non-issue, aka browsers do this often and it's not serious, then i suggested that we at least change this to a slightly less scary looking error. The idea here is to turn an exception (which is programming lingo) into an user error.
---

I don't think that's it - I started the maus-app running, went away for lunch. Meanwhile, they used a kvm switch to look at another PC - so they weren't even working on the machine where this was running. Maybe it's caused by auto-refresh setting in the browser/web page? Probably not critical, may be something weird about the way we're running in the control room, thought you'd want to know about it...

Likely a race condition when reading to convert to thumbnail and the file is overwritten on the next iteration.

Just to clarify: during normal running, people should only be looking at the webpage. This is for helping debug problems and not going down false paths. Right?

My feeling is that if it's visible in the control room, people will want to know whats going on... maybe just means we need to pipe stderr to a file (could be done overloading sys.stderr or whatever).

But this is a temporary webserver. Ideally we'll get our own monitor that will just cycle these plots. There will probably be a more interactive machine too but I doubt if it'll be the same machine that actually runs the webserver. Getting rid of the stack trace is good if it takes less than an hour or so... think of the MongoDB stuff: you can find the logs if you want, but if it threw a warning you wouldn't know as a user.

Fair enough...

It's an issue with Django and they won't fix it. The bug https://code.djangoproject.com/ticket/4444 was reported years ago and is "closed:wontfix". Subsequent reports have just been marked as duplicates of that. They blame it on browser's closing connections prematurely (fair enough) but requests for a more helpful error message seemed to be ignored.

I tried adding try/except blocks to our Django code but the except blocks aren't entered when the exception occurs. In a dedicated web server it would be buried in the log file.

I tried redirecting sys.stderr to a file (editing src/maus-web/manage.py). The console output becomes:

Validating models...

0 errors found
Django version 1.3.1, using settings 'maus-web.settings'
Development server is running at http://maus.epcc.ed.ac.uk:9000/
Quit the server with CONTROL-C.
----------------------------------------
Exception happened during processing of request from ('129.215.62.218', 55179)
----------------------------------------
----------------------------------------
Exception happened during processing of request from ('129.215.62.218', 55184)
----------------------------------------

The control room monitor team should only be concerned if:

• There is no web page.
• There are missing images.
• The refresh time stamp hasn't changed for a while.

So, a simple solution would be for them to minimise the console window after starting it.

Good stuff

Stack trace does not arise in Apache 2.2 usage.