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.

Sign up for GitHub

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

Jump to bottom

Dead loop in tfw_sg_wait_release() #959

Closed
krizhanovsky opened this issue Mar 18, 2018 · 1 comment
Closed

Dead loop in tfw_sg_wait_release() #959

krizhanovsky opened this issue Mar 18, 2018 · 1 comment
Assignees
@vankoven
Labels
bug
Milestone
0.5 alpha

Comments

@krizhanovsky
Copy link
Contributor

Test

test (mixed_requests.test_mixed.GetPostRequests) ... FAIL

causes dead loop with

[ 1926.684030] [tempesta] Warning: pending for server callbacks to complete for 5s, 1 server groups still exist
[ 1931.688017] [tempesta] Warning: pending for server callbacks to complete for 5s, 1 server groups still exist
[ 1936.692039] [tempesta] Warning: pending for server callbacks to complete for 5s, 1 server groups still exist
...

The reason for the leaving server group must be fixed. Also, it really has sense to crash instead of infinitely wait.
@krizhanovsky krizhanovsky added this to the 0.5 alpha milestone Mar 18, 2018
krizhanovsky added a commit that referenced this issue Mar 18, 2018
@krizhanovsky
1. Fix #956: remove req from fwd_list on error in tfw_http_resp_proce…
6440d7e 
…ss().

2. #959: print a warning and let the system crash if we can't remove a
   server grooup.
3. Add req->fwd_list and req->nip_list warnings to make sure that the req
   is removed from the list when we go to code where we don't have a pointer
   to the server connection.
4. Replace tfw_http_msg_free() by tfw_http_conn_msg_free() in couple of
   places to put connections on requests freeing to avoid memory leakage
   on connections reference counters.
5. Code leanups all around.
@krizhanovsky krizhanovsky mentioned this issue Mar 18, 2018
Merged
@vankoven
Copy link
Contributor

Then a response is received, corresponding request is removed from servers's forward queue. If the request is not the first one in client's seq_queue, it won't be forwarded to the client right away.
When the client disconnects, tfw_http_conn_cli_drop() is called, but requests-responses pairs are not freed. That is the reason, why server connections are not restored after closing by backend servers and not destroyed on shutdown.

@vankoven vankoven mentioned this issue Mar 20, 2018
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@vankoven vankoven

Labels
bug
Projects
None yet
Milestone
0.5 alpha
Development

No branches or pull requests
2 participants
@krizhanovsky @vankoven