Your comments
Very, very nice !
I was interested in using Let's Encrypt with Ubooquity but was kind of put off by the relative complexity of the procedure.
This will help a lot, thanks !
If you don't mind, I might include this tutorial in the documentation sometime.
I only had a quick glance at your logs, but, like Elouan, I think your problems are (at least partially) coming from the memory shortage.
Once a memory error has happened, all bets are off. The application can crash right after the error or much later, or even continue running like nothing happened.
This kind of error is critical, you can't expect Ubooquity to run properly as long as they happen.
To prevent them, you can increase the allocated memory using a command line option:
On my side I'll have to do some profiling to look for potential memory leak (or file handles leak), but I don't know when I'll find the time to do it.
Just for my information, how many comics were listed in the database when it crashed (I don't need exact numbers, just an idea) ? And what was the size of the database file ?
The main design goals of Ubooquity are simplicity and ease of use.
That's why Ubooquity is packaged in a single file and does not require any external dependencies (apart from the Java runtime environment) to run.
By the way, although Ubooquity acts as a web servers and uses an internal database, everything exists in a unique process.
There is no daemon, no external database instance, no external web server.
My guess is that pluging Ubooquity to your own database would not make you gain much anyway, a few megabytes of RAM perhaps. Not worth the trouble.
As for the Apache web server, as you guessed, it wouldn't bring anything at all.
It happens to everybody. :)
No, 24 comics per page is a low value indeed.
I was asking because Ubooquity has to read thumbnails files when displaying a page (as well as a few other files like themes element if you use a custom theme). But that's not important.
Ubooquity also scans your shared folders and all the files inside at startup, to detect any new, modified or removed file. It probably uses a lot of file handles at this time.
But don't focus on that.
If you want to get to the bottom of the problem, the first step is to characterize it.
The total number of file handles available on your system is shared by all applications.
Start by getting this max number and list consumption by application. There is a tutorial here.
The numbers you'll get will be a good starting point to understand what happens exactly.
NB: the web server is embedded because the goal of Ubooquity is to be self-sufficient, a single jar to copy and launch. And using an external server would not make sense does not need much in that domain. The embedded server is a single class: https://github.com/NanoHttpd/nanohttpd/blob/master/core/src/main/java/fi/iki/elonen/NanoHTTPD.java
Thanks, got it.
This file is of type "7z", not "zip". Ubooquity cannot open it.
I looked at my own 7z options; you have to specify the output format, otherwise 7zip will produce 7z files.
This is done using the "-t" switch (e.g. "-tzip" to produce zip files).
No it does not have one, but it should not require one (Ubooquity does not need to keep a lot of files open).
I'll have to do some tests to try to find a potential file handler leak.
Do you have some specific settings ? (like a very high number of comics/books per page)
Customer support service by UserEcho
Agreed, 4 GB was already an insanely high amount of RAM for what Ubooquity does.
Like I said, I have to do some profiling, but it will take time.
One last thing to check on your side: does the first occurrence of the memory error happen on the same file each time ?
I'd like to rule out a problem caused by a specific file (already happened in the past with broken PDF files).