comment
authorJoey Hess <joeyh@joeyh.name>
Mon, 6 Jun 2022 16:19:28 +0000 (12:19 -0400)
committerJoey Hess <joeyh@joeyh.name>
Mon, 6 Jun 2022 16:19:28 +0000 (12:19 -0400)
doc/bugs/get_is_busy_doing_nothing/comment_20_981cc786be798a612046d207c0f85955._comment [new file with mode: 0644]

diff --git a/doc/bugs/get_is_busy_doing_nothing/comment_20_981cc786be798a612046d207c0f85955._comment b/doc/bugs/get_is_busy_doing_nothing/comment_20_981cc786be798a612046d207c0f85955._comment
new file mode 100644 (file)
index 0000000..37f0889
--- /dev/null
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 20"""
+ date="2022-06-06T16:12:53Z"
+ content="""
+It does occur to me that one "solution" might be to have flushDbQueue
+not rethrow the exception, and just re-enqueue the write. Then, if a write
+fails in the middle of a long git-annex command, it will just queue up
+sqlite changes until later. And hopefully whatever is preventing writing to
+the database at that time would later resolve itself. At shutdown, it would
+need to make sure to flush the remaining queue and not ignore a write
+failure then.
+
+That has the potential problem that, if the write keeps failing, it might
+end up buffering a large number of writes in memory, and since the queue
+would be full, it would be trying to write every time. So it would both use
+an ever-growing amount of memory, and be slowed down by the write attempts.
+
+Still, it does give it something better to do while the write is failing
+than sleeping and retrying, eg to do the rest of the work it's been asked
+to do.
+"""]]