-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"Freshness" constraint on the receive
APIs
#288
Comments
Thanks for bringing this up, @notthetup! For context, off the top of my head I remember this particular instance where message staleness was an issue. In an older version of the SWIS UI, we used Providing a convenient API for listening for notifications that came in only after the |
Without any API change, one could easily filter based on t0 = currentTimeMillis()
msg = receive({ msg -> msg.sentAt >= t0 }) |
I think that's not the case with the example that @ettersi talked about. But this makes me think of a useful way to solve this to have a |
I was thinking along the same lines... |
We can add a message-specific flush: function flush(gw::Gateway, ::Type{T}) where {T <: Message}
while true
if isnothing(receive(gw, T))
break
end
end
end Whenever we're receiving a notification, we're already potentially stealing it from someone else, so it's probably fine to steal all of them while we're at it... |
The various Agent/Gatway
receive
APIs have a default semantic, that if a message which matches the filter is already in the receive queue, then it's returned immediately.While this is a great default in light of all the async and co-operative multi-threading-based processing that is done in Fjåge, in certain situations it may lead to requiring lots of complicated code to be able to receive a new message that matches a given filter.
For example, a common use case could be to send a
Req
to an Agent and wait for aNtf
which the Agent sends out after some internal processing. Just doing aagentid.receive(MyNtf)
may give a stale notification which might have been in the receive queue.. Doing aagent.queue.flush()
(supported in some Gateways) is 1. not a standard and 2. can cause other behaviours or parts of the Agent to lose some messages.So the question is do we need some mechanism to simply tell the
receive
API call that we are only interested in the newer message received since we invoked the API.@ettersi tagging you since you have brought this up a few times.
The text was updated successfully, but these errors were encountered: