Job queues are quite common in the Ruby environment (for example https://sidekiq.org) and Python (for example https://docs.celeryq.dev). There are no such large projects in the JVM world. Let’s look at why.
One of the most typical tasks is sending mail.
In the JVM, it is not a problem to make an asynchronous function inside the main procedure itself. In Ruby/Python, this is already a problem due to single-threading, so the task is allocated to a separate repository and separate instances of the application - handlers execute them.
The second feature is that the JVM will have several attempts at once for a limited time and an error in the logs. These logs are being sorted out, analyzed and there is a support team that will fix them. In the scripting world, there is usually less reliability of neighboring systems (i.e., there are more errors themselves) and not so many people to deal with each case of temporary failure.
Well, and the third thing: if similar problems are expected in the JVM, then more often a separate microservice is allocated and there is a queue somewhere inside. If an error has occurred, the messages are sent to a separate error queue. There is a script that allows you to add messages from the error queue to the main queue (after correcting the cause of the errors).
That is, approximately the same tasks are solved, but due to technical and organizational differences in different ways.