Create single cache folder for multiple sub servers

[DarkEyeDragon]

When running multiple minecraft servers in sub dirs from the same paper jar each server will generate its own cache folder. I was wondering if it was possible to "force" servers to use their relative path when looking for/creating the cache folder. Right now it seems like a waste of space to make all servers generate the same cache folder.

I'm using Windows btw, no idea if this is intended behavior.

Expected behavior: multiple servers using the same cache folder when starting Current behavior: Each server generates its own cache folder in the base folder

[aikar]

we could make a -Dpaperclip.cachedir config option to specify where the cache is.

[zachbr]

Have to add some sort of handling so you can't overwrite yourself with different versions of a paperclip jar.

Seems just as easy to run it once, then just use the cache jar directly.

[mikroskeem]

Under unix you can do symbolic links, under Windows you can create directory junctions - open up CMD and do mklink /J target source.

For example:

• Global cache directory is in C:\paper_cache
• Target is C:\testserver

Then you can do mklink /J "C:\testserver\cache" "C:\paper_cache"

[DarkEyeDragon]

I think @zachbr 's solution would work well enough for this. This is for a public application so I'd prefer to mess with the hosts OS as little as possible :)

A -Dpaperclip.cachedir option would be 🔥 though. If anyone feels like ever adding that.

[electronicboy]

There are some concerns here,

Z has highlighted one of them, the other is that the current file naming scheme of the cached files would need to be modified so that it retains per revision vs per version to prevent issues with running servers

[DarkEyeDragon]

There are some concerns here,

Z has highlighted one of them, the other is that the current file naming scheme of the cached files would need to be modified so that it retains per revision vs per version to prevent issues with running servers

Well the idea i came up with was the following: Have one server generate only the patches. Start the other servers from the cached jar (i can just list the contents of the cache dir and take the first entry. As it should only contain one jar anyway). All servers would always be running the same version as its determined by the patching server.

[electronicboy]

All servers would always be running the same version as its determined by the patching server

That assumes that all servers will be stopped before updating the server jar, we cannot make that assumption safely

[DarkEyeDragon]

In most cases not. However my use case basically allows me to assume this. The servers would only be used to pregen chunks and once their task is done will never be run again (deleting themself after the process). If you decided to update the jar during this process while half of the servers are still running you're basically asking for trouble regardless. This is all handled by an external application.

Essentially there shouldn't be any reason to update during this entire process.

Edit: If you're actually planning on implementing this you'd indeed need to have some sort of system in place to prevent this. Was a bit too focused on myself here.

[DenWav]

It would be possible to add a filesystem locking mechanism to provide both

1. Not deleting currently in-use jars
2. Waiting for the first paperclip instance to finish patching before deciding whether to patch itself

But that does nothing to handle the almost-certainly-going-to-happen case where 2 paperclip jars containing different patches are pointing to the same cache directory.

• When would the old jar be deleted?
• Which paperclip would do that, and how would it know when was the correct time to do that if the jar was originally locked?
• What happens when the filesystem locking is implemented, but these 2 clashing paperclip jars are fighting over 1 jar slot?
• If a more complex caching system were implemented that would handle multiple versions globally (or at least allow shared versions) which paperclip manages the cache, and how are jars marked for removal after they haven't been used for x period of time?
• How do you even determine whether a jar has been recently used?

There are global cache solutions that would mimic something like what Gradle does with some sort of expiry system that wouldn't be too hard to implement theoretically, though would be a decent amount of work. I'm not necessarily convinced that the effort, complexity, or risk of bugs is worth it though.

Your original suggestion is interesting - to use a path relative to the paperclip jar rather than the server directory. This may be more reasonable, obviously it wouldn't necessarily fix the above issues, but it would fall into the realm of what I would call "sufficiently obvious" for users similar to why we don't worry about that situation when someone tries to start 2 servers in the same directory.

But I had reasoning for using the server directory, mostly due to the fact that's where users typically expect all of the files to go, so it felt most reasonable there. I still stand by that idea, so don't want to change that. But a property like -Dpaperclip.relative might be a way of enabling that option.

Paperclip did used to place the cache directory relative to the paperclip jar, but that was removed a while ago with good reasons I think. d0395f6304db49e4472dab9dbf247e994a1122b8

[DenWav]

I suddenly had the realization that none of these issues would actually matter if we just didn't cache the patched jar. The patching process is not expensive and most users never notice it even happens, it's the downloading that takes a while. The vanilla jars would still be cached but the patching could just happen every time the server starts.

As for clearing old vanilla MC jars, I don't think that would be necessary. Vanilla versions are fairly slow and don't come quickly, even if users never clean out old versions it wouldn't get too big.

[DenWav]

I think the solution to this is to just use symlinks instead. They've worked since the beginning and other than my accidentally breaking them recently (now fixed) they work fine now.