search

ajslater / codex

Codex is a web based comic archive browser and reader
GNU General Public License v3.0
208 stars 8 forks source link

Odd log entries #419

Open abillauer opened 3 months ago

abillauer commented 3 months ago

Everything is working fine. I just saw this log entry and not sure if this reason for concern.

codex v1.6.15

codex  | /usr/local/lib/python3.12/site-packages/django/http/response.py:517: Warning: StreamingHttpResponse must consume synchronous iterators in order to serve them asynchronously. Use an asynchronous iterator instead.
codex  |   warnings.warn(
codex  | 2024-07-24 07:58:06 UTC WARNING update user activity database is locked

I also see this sometimes when reading:

codex | 2024-07-24 08:00:33 UTC WARNING Invalid arc {'group': 's', 'pks': (1,)} submitted to reader for comic 192588.

Everything is working well. Just wanted to call this out in case it is an issue for some other part of the system.

ajslater commented 3 months ago

  1. The StreamingHttpResponse warning is the Django framework warning that I'm streaming files from disk as one big chunk which could be prone to blocking the webserver until the the response is done instead of having an asynchronous way of sending chunks down the HTTP pipe as they're made available by the operating system. Functionally, this would only be a performance problem for a) very large comic pages from very high res scans and b) downloading entire comics. However, I actually do chunk these out (in what I think are performance oriented chunk sizes) and yield control back to the webserver so it doesn't block. But I haven't managed to make Django get rid of the warning yet and that has irritated me for quite some time.

  2. The database is prone to occasionally locking during moments of interactive use because the database I've chosen for this project, sqlite3, was chosen for it's ability to be embedded and so people don't have to set up a separate database to use codex rather than it's ability to handle multithreaded writing well. Most of the high volume database transactions like importing comics are actually done single threaded, but setting bookmarks, setting user settings and it seems most frequently updating the user's last activity timestamp when they log in are prone to running into a locked database. The two remedies for this behavior would be a) switching to a high performance external database like postgresql or b) fixing codex so that all writing is always done in one thread. Option (b) is the most practical, but I haven't done it because functionally these little whoopsies don't seem to cause much actual degradation of the codex user experience.

  3. The reader is complaining that it's trying to look up Series pk 1 for comic 192588 to populate the reading order dropdown in the reader, but they don't seem to match. Pk 1 seems like a suspicious number, it would literally the first series ever imported by your codex library, so I wonder if that's a bug in my code, I'll look into it.