Dispatching a Message inside a Handler?

Hey Dmitriy,

IIRC there's no something similar to Doctrine batch processing in Messenger, but probably instead of trying to dispatch like you suggested you better create a different "batch" message? Something like ProductStockBatch that will take an array of those intval($item[0]) and intval($item[2] arguments? something like:

$productStocksData = [];
foreach ($stocks as $key => $item) {
    $productStocksData[] = [intval($item[0]), intval($item[2])];
}
$message = new ProductStockBatch($productStocksData);
$messageBus->dispatch($message);

Something like this, also you may want to add some limits to that array or modify it that way that when you hit e.g. about 100 entires in that $productStocksData array - dispatch the event.

Then in the message handler you would need to deal with an array.

I hope that helps

Cheers!

Thanks for the answer. But I don’t understand how to handle messages in this way.
What if the connection is lost or some element will be processed with an error. Will the entire processing process have to start over again?

The problem is that the messages in this case are stored in an array and not as individual messages.

Hey Dmitriy,

I see. Well, if something will go wrong - the message will hit the failed queue, but to know what data were already process and what were not when you will retry again - that's a tricky thing than. Probably you could check if the specific data were processed? I mean, if you create something - you can double-check if it was already created before try to create it again. And if it was - just skip it. Or if you just update soemthing - probably not a big deal to process the update again if it's safe, if nothing will be changed because changes were already applied - ok then, easy win. Or you probably could "log" the processing somehow, create an extra log table that will hold the IDs of entries that were successfully handled before, and so you can skip processing it again base on that.

Otherwise, yeah, you would need to fire those many individual ProductStock events. Probably there's a way to extend the Messenger class and add some more custom implementation that would help with kind of "transactioning" as you mentioned in your first message, but I'm not sure how to easily achieve it, never thought about it before.

I hope that helps!

Cheers!

Hey Kris,

That's unexpected, the DelayStamp should just work (and actually, it does work for me). How do you start the worker? I'm wondering if you use any special config for it
Also, remember that the delay time it's in milliseconds

Cheers!

Hey Renato,

Yes, you're right. We don't need out users to wait for the actual photo deleted, we can say that it's deleted by kind of "scheduled" it to be deleted in the system. Then later, the messenger will handle that scheduled delete request eventually deleting the file, but it will be a background process, and we don't care how long it will last, the user will get the response almost immediately. Moreover, if something when wrong - we could retry the deleting (or any other process we scheduled).

Also, it's important to understand that with this strategy you don't care about how many simultaneous requests you get the same second because all scheduled deletions will be performed one by one by the Messenger's worker, i.e. no any pick highloads on the server. Without the Messenger, if we know that the process (like deleting a photo from the server) is resource consuming - you may down the whole website when you suddently got a high pick of users requesting file deletions.

So, Messenger clearly has some benefits handling time or resource consuming operations.

And yes, you can have a separate server that will handle all those tasks in the queue if you need, but as I said, thanks to the fact that messenger's worker will handle each queue one by one you can safely do this on the same server as well without causing server overloading. But yes, it depends on your specific case, on how time/resource consuming your operations are, and how many queues you have.

I hope it's clearer to you now.

Cheers!

FANTASTIC!!!!!!!!!!!!!!

YOUR EXPLANATION MADE EVERYTHING CLEAR! THANK YOU SO MUCH

Hey Renato,

Awesome! I am really happy to hear it :)

Cheers!