[erlang-questions] Abusing OTP-8623 for high-priority messages

[Michael Truog]

On 04/10/2014 05:02 PM, Dmitry Demeshchuk wrote:
> Hi list,
>
> Today (yeah, just a couple years have passed since R14A) I learned about OTP-8623, which allows to do selective receive for messages that contain a known reference with O(1) complexity.
>
> Which made me think: what if we make a gen_server'ish process that:
> 1. Creates a reference that is being passed along with the pid, meaning, our start_link returns {ok, {Pid, ManageRef}} or something like that. ManageRef is actually created within the new process inside init/1 or such.
> 2. Introduce an operation named priority_call, which, basically, sends something like {ManageRef, {Pid, Ref}, Msg}.
> 3. The process itself (on its own side) does a selective receive like that:
>
> receive
>     {ManageRef, From, Msg} -> handle_call(From, Msg, State)
> after 0 ->
>     receive
>         Msg -> gen_server_like_dispatch_msg(Msg)
>     end
> end
>
> This could potentially help with sending managing messages to the processes that may have overloaded inbox with thousands of messages. Say, we see that the process gets overloaded and we send an operational message of some kind ("discard the entire inbox", for example).
>
> Thoughts?
You could get this interaction by creating an internal service with CloudI (http://cloudi.org).  That means you just use the cloudi_service behaviour for the service request receiver.  You can use the cloudi module to send from normal Erlang pids, or use the cloudi_service behaviour to send from a second internal service. Every CloudI service requests provides a unique v1 UUID to identify the service request, a priority (defaulting to 0, but between -128 (high) and 127 (low), inclusive), and the source Erlang pid, in addition to the two payloads RequestInfo and Request (where RequestInfo is generally key/value message meta-data and Request is the main data, both are any type when used with internal services). The priority of the service request impacts the queuing of the received service request, to determine the order service requests get processed by a service.  There is a queue_limit service configuration option which can be provided for any CloudI service to limit the 
number of pending service requests (i.e. unhandled) that may be stored (http://cloudi.org/api.html#2_services_add).  So, the same use-case you have described with added features that includes details for high-availability and partition tolerance.
>
> -- 
> Best regards,
> Dmitry Demeshchuk
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140410/0c118188/attachment.htm>