Skip to content

Keep sequence of pipelined requests on response/request blocking #963

@krizhanovsky

Description

@krizhanovsky

The issue is inspired by comment #960 (review) and #962 . It seems some existing test(s) must be enhanced to catch and check the cases for keeping request/response sequence:

  1. a request blocked due to a parser error
  2. a request blocked by Frang
  3. response length is determined by connection closing and doesn't correspond Content-Length value for the response
  4. response is blocked due to a parser error

All the cases must be tested with checking sequence of pipelined requests and received responses. Moreover, all the tests must be checked in 2 modes:

  1. configured error responses - error/unlucky requests must receive error responses
  2. configured blocking - client connections must be terminated on error/unlucky requests while all previous requests should receive responses.

The very last requirement can be broken under high concurrency and previous requests also can be unanswered (i.e. the case will be seen as a previous request was blocked), so it has sense to not to use stress testing here.

UPD. Also please add tests for non-idempotent requests, in particular test server_retry_nonidempotent and nonidempotent configuration options:

  1. a client sends a request just after non-idempotent request, then both the request must be normally pipelined.
  2. if several requests in a server queue must be rescheduled due to the server failure, then a non-idempotent request must not be resent and an error response corresponding to the request must be sent to the client

Also fix the disabled tests for the issue.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions