When should I ask check_response to delete request IDs?

[rlipscombe]

In the documentation for gen_statem:check_response/3, it says:

Note that deleting an association is not for free and that a collection containing already handled requests can still be used by subsequent calls to check_response/3, …

Sounds ominous; I’ll pass false for the Delete parameter.

I assume, however, that this means my request_id_collection() will get quite large over time.

The documentation goes on to say:

However, without deleting handled associations, …

OK, so how do I delete handled associations? Are there any guidelines for when to do this?

[rickard]

@rlipscombe

OK, so how do I delete handled associations?

Pass true as Delete argument.

@rlipscombe

Are there any guidelines for when to do this?

When you find it unacceptable to keep the whole collection as is until all requests have been handled. When all requests have been handled the whole collection can be dropped.

I would not delete in the collection if I have a limited amount of requests, that are all expected to complete relatively soon.

[rlipscombe]

@rickard

Pass true as Delete argument.

Does this delete all handled associations, not just the one that I just got notified about? The documentation doesn’t say that:

If Delete equals true, the association with Label will have been deleted from ReqIdCollection in the resulting NewReqIdCollection.

This implies that at most one association will be deleted – the one associated with Label.

@rickard

When you find it unacceptable to keep the whole collection as is until all requests have been handled.

So if I’m doing a lot of concurrent requests, I guess?

@rickard

I would not delete in the collection if I have a limited amount of requests, that are all expected to complete relatively soon.

And I’d keep track of those with a counter (not a counters) or something? Because the obvious (to me, at least) way to keep track of outstanding requests is to, well, delete them from the request_id_collection()…

I guess that if I’m only expecting a single in-flight request, I should just be explicit about it…?

I think I’m missing something here, but I can’t find a good worked example of how to use this functionality. I’d write one myself, but I need to better understand it first.

[rickard]

@rlipscombe

This implies that at most one association will be deleted – the one associated with Label.

Yes.

@rlipscombe

So if I’m doing a lot of concurrent requests, I guess?

Yes, or if you don’t have a known upper limit on the amount of requests, or if the responses are expected to take a very long time to be received.

@rlipscombe

And I’d keep track of those with a counter (not a counters) or something?

Yes, keeping track of the number of outstanding requests with a counter is typically what you’d want to do.

@rlipscombe

I guess that if I’m only expecting a single in-flight request, I should just be explicit about it…?

If you know that it is always at most one outstanding request, you don’t need to use a collection. Then you can use the request id as is with the functions that take a request id instead of a request id collection.

@rlipscombe

I think I’m missing something here, but I can’t find a good worked example of how to use this functionality. I’d write one myself, but I need to better understand it first.

An example when you might want to not delete request ids in a collection: You send 10 requests (and only 10 requests and those are expected to be responded to quickly), put the corresponding identifiers in a collection, and then wait for the responses to those requests. Using a counter you know when you’ve got all responses and can drop the collection.

An example when you want to delete request ids in a collection: You send 10 requests, put the corresponding identifiers in a collection, and then wait for the responses to those requests, but you might have to send more requests (and you don’t know how many) before all responses have been received.