I want to trigger at the exact same time through message receipt, some processes into different Actors. Considering my Actors possible heavily stacked mailBoxes, what would be the best method to implement this?
I'm assuming you want the actors to read the messages at the same time. This, of course is not possible (while an actor is processing a message he cannot be disturbed).
But you can make sure that your trigger message is the next message they will take from the mailbox. This can be achieved by using a priority mailbox, for example this one: http://doc.akka.io/api/akka/snapshot/index.html#akka.dispatch.UnboundedStablePriorityMailbox
The messages in the mailbox will be sorted by priority. If you give your trigger messages the highest priority, they will be processed first.
Related
Is it possible in Akka Actors to install some kind of 'hook' that allows you to run a self-defined piece of code every time a new message arrives in an actor? Note, this is not the moment when the actor starts handling the message with receive but the moment when the message arrives in the actor and is put into its mailbox. Also note that I want to change the default behavior, not just the behavior for one individual actor. Ideally I would change this behavior at just one spot throughout my code and it would affect all actors automatically, or by only requiring 1-2 lines of code in each file/actor (such as an import statement).
For example, using this hook it should be possible to log a message every time it arrives or to calculate and print the fibonacci of the size of the mailbox before/after insertion.
If you control the spawning of the actor (or are willing to use this mailbox as the default for actors which don't specifically set a mailbox), you can use a custom mailbox. See the docs for details.
I'm looking for a method to broadcast a message using queue in freeRTOS and i come up with different ideas but each one has a different problem.
what i have:
the item type for the queue is a struct with an attribute to indicate if the message is a broadcast or for a specific task.
a broadcast task that will write a message to the queue.
a queue manager task that will peek on the queue if any new message was received and if the message has a destination then it will resume that specific task or resume all tasks if it's an broadcast.
and for the Receiver task i come up with those ideas:
if i used the receive function xQueueReceive only the first task in task-queue will read the message and remove it from queue and with this, the other tasks will not be able to read that broadcast message. in the other hand, it's the perfect why for directed message (message for a specific task).
if i use the peedk function xQueuePeek the message will never be removed from queue unless i use xQueueReceive which is kinda redundant (peek and receive in the same task, meeh, ugly coding) and i can't use any other delete function because it will remove the whole queue. but that will solve the message for a specific task, and to solve the broadcast message i need to set a priority for each receive task and only the task with the lowest priority will use xQueueReceive to remove that message from queue and all receive tasks will suspend themselves after peeking or reading so they don't read again the message (i'm not sure what to do about the queue manager task because i can't suspend it and it will keep notified about a new message in queue until the last task receive it), but the whole system will need to wait for that low priority task to run to remove that message and any new message received in that time, it will not be read in the real time.
i'm still thinking about other methods like using new queue or a queue for each receive task but i'm not sure yet which method is the best one. and i don't know if there any other why to broadcast a message even without using the queue technique.
i need to tell you that this program is not for a specific project. i'm just trying to use the Queue technique in different ways. and i already found other post about broadcasting a message but it was for a specific problem where they solve it without using the queue technique. i just want to send "this is a broadcast message" to the queue and all receiver be able to read it once (just one time).
thank you.
Event groups are the only broadcast mechanism in FreeRTOS. You could use an event group to unblock all tasks that should read from a queue using the queue peek function, then xEventGroupSync() to know when all tasks had read the data so the data should them be removed.
I am trying to implement job queue with MSMQ to save up some time on me implementing it in SQL. After reading around I realized MSMQ might not offer what I am after. Could you please advice me if my plan is realistic using MSMQ or recommend an alternative ?
I have number of processes picking up jobs from a queue (I might need to scale out in the future), once job is picked up processing follows, during this time job is locked to other processes by status, if needed job is chucked back (status changes again) to the queue for further processing, but physically the job still sits in the queue until completed.
MSMQ doesn't let me to keep the message in the queue while working on it, eg I can peek or read. Read takes message out of queue and peek doesn't allow changing the message (status).
Thank you
Using MSMQ as a datastore is probably bad as it's not designed for storage at all. Unless the queues are transactional the messages may not even get written to disk.
Certainly updating queue items in-situ is not supported for the reasons you state.
If you don't want a full blown relational DB you could use an in-memory cache of some kind, like memcached, or a cheap object db like raven.
Take a look at RabbitMQ, or many of the other messages queues. Most offer this functionality out of the box.
For example. RabbitMQ calls what you are describing, Work Queues. Multiple consumers can pull from the same queue and not pull the same item. Furthermore, if you use acknowledgements and the processing fails, the item is not removed from the queue.
.net examples:
https://www.rabbitmq.com/tutorials/tutorial-two-dotnet.html
EDIT: After using MSMQ myself, it would probably work very well for what you are doing, as far as I can tell. The key is to use transactions and multiple queues. For example, each status should have it's own queue. It's fairly safe to "move" messages from one queue to another since it occurs within a transaction. This moving of messages is essentially your change of status.
We also use the Message Extension byte array for storing message metadata, like status. This way we don't have to alter the actual message when moving it to another queue.
MSMQ and queues in general, require a different set of patterns than what most programmers are use to. Keep that in mind.
Perhaps, if you can give more information on why you need to peek for messages that are currently in process, there would be a way to handle that scenario with MSMQ. You could always add a database for additional tracking.
I have a Microsoft Message Queue that gets populated with messages. If there is a problem with the processing of the message, I would like to retry the message, I do not want to retry the message immidiatley.
Is there a way to add a delay to the message in the MSMQ to avoid it being available for a certain amount of time??
The other alternative is to have another queue (A retry queue) and read that queue every 15 minutes, But i would rather not do this.
What you are looking for is "Poison Message Handling" ( even if its not the message fault, but an temporary environment problem ).
There are lots of articles on that. Here are some:
Poison Message Handling in MSMQ 3.0
Poison Message Handling in MSMQ 4.0
Surviving poison messages in MSMQ
In short: you have to move them to a retry queue.
So I've seen some code recently that handles this in the exception logic, the code has a built in retry step that attempts after a delay. It fails, waits for a specific amount of time, then tries again.
Essentially it recursively tries a set number of times (lengthening the delay each time). Fairly neat, no reason to have another queue. There is alot of generics and delegates used to execute the methods. Don't know if something like this could be done or not. I would suspect you would still want to handle the case of the message not being able to be delivered with another queue though.
I'm thinking of creating a generic message queue to handle various inter-process messages. (WCF is not an option at this point.) So, rather than have 10-15 different queues for specific messages I'd have 1 queue that is a 'catch-all'.
Obviously sending messages to this queue is a not a problem. Each recipient would listen to the queue for new messages then 'peek' them, but I'm looking for a clean/efficient way to do this. By clean I mean a method that does not require each and every recipient to read the body of each and every message.
Use System.Messaging.Message.AppSpecific (Integer) to specify a recipient.