RoadRunner v2025.1 ideas discussion

[rustatian]

Discussions for the ideas from: #1959

[Kaspiman]

Let's add a few ultimate features to kill FrankenPHP

[rustatian]

FrankenPHP raised a good idea in the PHP community. I respect the guys behind that project. I don't agree with the concepts of merging Go and C via CGO and forcing to use Caddy (and this is totally ok), but competition is a great thing. We can learn something from them, while they can learn our approaches and apply them for the good PHP future. So, no need to kill anyone 😃

[Kaspiman]

I expected something like: Agree.

[rustatian]

@Kaspiman #1959 (comment)

1. Need to think about that. Generally, I agree that from lower to higher value might be a better representation of the priority.
2. Yes, agree.
3. Also agree, but to support both commands while deprecating reset. For 1 year, showing a deprecation method.
4. Agree.
5. Already exists.

[Kaspiman]

5. Look at my Grafana with rr_jobs* metrics - there is no queue size gauge.
   

HTTP-pluging metrics looks like this:

[rustatian]

Yeah, it exists, but not exposed. Generally, we should maintain the same mechanism for queue reporting across all plugins. The workers pool already supports the QueueSize method.

[Kaspiman]

i remembered some old task about requeue tag Add requeue tag to failed task metric of Jobs plugin

[Kaspiman]

How about upgrade RR logo? It doesn't look very memorable or special right now

[rustatian]

Thanks for the proposal, but logo is fine, no need to update it.

[Kaspiman]

Hello again! I found out that BoltDB (KV driver) has been out of development for about six years now (latest commit).

Should we find a new alternative for this? For example Badger

[rustatian]

Hey @Kaspiman 👋
I'm not using this driver.

[Kaspiman]

Oh, i see. RR use fork bbolt, not original repo.

[Kaspiman]

Hello. There is an idea to change the mechanism of delayed messages for AMQP-driver.

Now we declare dead-letter queue for every delayed task. The result is a large number of queues with different names.

We have more than 100 queues on the project, many of them with pending tasks. A large number of queues affects the cardinality of metrics and can lead to disruption of metrics rendering. Also we try to send messages to queues through a storage mediator/accumulator. This mediator helps us not to lose tasks in case of network connectivity failure.

What if we stopped creating new temporary queues, leaving only one per queue? For example delayed_queue_name. Let's change dlx-behavior per queue to dlx per message.

When creating a pipeline, you can immediately create a delayed queue. What do you think?

[rustatian]

Hey @Kaspiman 👋
The case is, IIRC, that every message for the dlx queue has to be unique, because x-dead-letter-exchange and x-dead-letter-routing-key are Queue properties, not messages. While TTL's yes, might be set per-message, it is used to automatically resend the message to the routing-key and exchange specified in the dead-letter-queue.

I thought about that in the past, and it might be valid to use only 1 dead-letter-queue bound to the pipeline's exchange and queue. And when we have a delayed message or dead-lettered message, we can use message properties to retry, yeah.

[Kaspiman]

Of course we need to create delayed queue for every pipeline separatelly). You'll have to create twice as many queues, but it's worth it. Recently I tried to implement such a mechanism by adding temporary/virtual RR-pipelines, but it didn’t work out.

[Kaspiman]

Is this change possible in a minor version? Of course, changing the names of queues looks like a compatibility breakdown. However, those queues are temporary and are automatically deleted over time. Introducing new prefixed queues shouldn't break current projects too much.

[rustatian]

This won't break existing projects because dlx mechanism automatically sends the data to the configured exchange and routing key. Even if we update this mechanism to use only 1 DLX queue created at runtime, other dlx queues, previously created by the old RR, will anyway send their pending messages. But this is not a bugfix change, and so, will wait for at least 2024.3 (fall).

[Kaspiman]

Hello! Let's change AMQP default options to improve durability:

• queue durable false -> true
• exchange durable false -> true

Also let's change similar params in roadrunner-php/jobs package:

• queue durable false -> true
• exchange durable false -> true

[rustatian]

Hey, I'm not sure that we should touch configurable parameters for no significant reason.

[Kaspiman]

The reason is very good.

Classic queues will survive restarts and will not lose messages. Modern quorum queues have this mode by default, and it’s great. It makes sense to promote classic queues to be durable. It is difficult to imagine a situation where non-durable queues are needed.

• https://www.rabbitmq.com/docs/queues#durability
• https://www.rabbitmq.com/blog/2023/03/02/quorum-queues-migration#non-durable-queues

Non-durable queues
Non-durable queues will be deleted on a node/cluster boot. Having extra durability guarantees that mirroring provides is a bit pointless.

Non-durable queues concept is also going away in the future releases: the only option for ephemeral queues will be exclusive queues. This affects only durability of queue definitions, messages can still be marked transient.

For such queues a decision have to be made one way or another: is this queue content important enough to get availability guarantees of quorum queues, or it's better to downgrade it to a classic (but durable) queue.

[rustatian]

I understand the reasoning, but not everyone needs this.
The default value for bool is false, everybody knows that and expects, that the bool value for the configuration would be false by default.

[Kaspiman]

Hello! Let's take a look at pool.allocate_timeout. There are two different operations with one timeout:

1. allocate workers at RR start
2. allocate request/job at free worker (essentially a timeout for a request/job to be in a queue)

Maybe we should separate timeout by operations?

There is another idea: to collect the internal queue settings in a separate section:

pool:
    internal_queue:
        max_size: 100
        timeout: 10s

[rustatian]

Hey @Kaspiman 👋
Thanks for the proposal.
There is no need for general users to know about internal implementation details. Allocate timeout is already a known option and no need to change it.

[Kaspiman]

I was trying to figure out this parameter right now and it turns out I need to change it. These two operations need to be set to different timeouts. Creating a worker and taking a request from the queue are completely different operations, why do they have the same config? Also, the word "allocate" does not accurately describe the taking of a request from a queue to a worker.

[rustatian]

Thanks for worrying about that. Sorry, but this option won't be changed.
Reasoning:
That is straightforward to change everything in the configuration to correspond to the every internal piece. The question is: Who would use that? My realistic answer to that: possibly a few devs + we have to introduce a BC to config, update version, support 2 configuration versions, etc.
'Allocate' word meaning is: distribute (resources) for a particular purpose. Looking at our use-case, we 'Allocate' (aka distribute) workers to use them to handle a request. So the word is used correctly from my POV.