git-annex p2phttp should be able to serve multiple git repositories, eg all the ones in a directory.
- Add a --directory option.
- When a request is received for a uuid that is not one it already knows about, it can rescan the directories to find new repositories that have been added.
- Removing a repository that it is serving should be ok, git-annex doesn't mkdir recursively down to the git repository level. So any running threads that are serving the removed repository will not recreate it, and will fail out.
- Removing a repository and then re-creating it with a different UUID though would be problimatic and probably the documentation would need to say to not do that, restart git-annex p2phttp after deletion in that case.
I asked matrss if this would be useful for forgejo-aneksajo and he said "Serving more than one repository per p2phttp instance would probably be very useful, although I think I can work with the limitation [of only 1]."
I have some early work toward implementing this in the
p2phttp-multibranch.This is now implemented, use p2phttp --directory to serve all repositories in that directory.
There is one known problem, which I'm leaving this todo open for. When a repository is moved out of the directory, the server should stop serving it. And it does, eg both git-annex get and git-annex drop will fail, since the server is not able to access the directory any longer. But, a second git-annex drop actually hangs at the "locking origin" stage. (When run with -J2.. with more jobs it takes more than 2)
It seems that the server is leaking annex workers in this case. Probably it fails to recover from a crash.
Luckily, it only affects serving the uuid of the removed repository, other repositories in the directory will continue to be served without problems when this happens.
Seems the bug is specific to LOCKCONTENT. When doing other operations, like CHECKPRESENT after the repo is deleted, the server returns FAILURE and continues being able to serve more requests for that repo.
Ah, the problem is that serveLockContent is running a block of actions in a single inAnnexWorker call, which first sends on the LOCKCONTENT, then blocks waiting for the unlock to arrive. Which never happens, so it remains blocked there forever, consuming a worker thread.
Fixed that, finally.