#418 Detect consumer processing delay in provider

[Lukas Deichmann]

There are use cases in which it is useful for the provider to know whether a consumer has accumulated a lot of delay in processing its messages. This can happen, for example, when a consumer is queuing received messages for asynchronous processing and falling behind its own queue.

The provider has no way of telling whether a consumer is queuing messages or processing them directly, as per Basic Profile successful transmission does not carry more meaning than that.

A successful transmission does not indicate that the SOAP processing layer and the application logic has had a chance to validate the envelope or have committed to processing it.

On an application level, this could be solved or at least severely mitigated by introducing responses to reports, breaking up the one-way transmission pattern previously used. The response would contain the at-this-point current Mdib version on the consumer side, so even if the message is enqueued, the response would provide the provider with the currently processed state in the consumer.

For synchronous processing, this is trivially the just received Mdib version for the report.

A response message could look like this

<xsd:element name="MdibReportResponse">
    <xsd:complexType>
        <xsd:sequence>
            <xsd:sequence>
                <xsd:element ref="ext:Extension" minOccurs="0" />
            </xsd:sequence>
        </xsd:sequence>
        <xsd:attributeGroup ref="pm:MdibVersionGroup">
            <xsd:annotation>
                <xsd:documentation>MDIB version of the MDIB snapshot that is confirmed to be
                    processed by the BICEPS CONSUMER.</xsd:documentation>
            </xsd:annotation>
        </xsd:attributeGroup>
    </xsd:complexType>
</xsd:element>

Of course, it is possible to have use-case specific solutions to this problem in other standards, but providing a general purpose way of detecting such delays would surely be preferable.

This also needs to handle the case that for initial reports the consumer doesn't necessarily know the version, so it can respond with a "don't know yet" response, until it knows, and then it is not allowed to respond "don't know yet" anymore.

[Paul]

One thing I've been thinking about is using http's Expect: 100-continue for notifications. Then I wouldn't complete assembling and sending the message until the consumer responds with the continue message. Consumers can also respond with 429 = too many requests, with an optional retry hint. Or can we not rely on http transport features in case it turns into protobuf in the future, or for some disconnect between the consumer's service stack and processing?

I guess I'm thinking of cases where the consumer is actively informing the provider it is a bit behind and would like it to slow down a bit. This issue might be more when the consumer is too embarrassed to share?

Are the use cases for "in which it is useful for the provider to know whether a consumer has accumulated a lot of delay in processing its messages" available somewhere ?