Skip to content
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

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

Open
krizhanovsky opened this issue Mar 19, 2018 · 0 comments
Open
Labels
Milestone

Comments

@krizhanovsky
Copy link
Contributor

krizhanovsky commented Mar 19, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants