Skip to content

Commit efb4640

Browse files
committed
Fix stuck on processing GET request
memcached stuck on processing GET request when number of processed commands is exceeded of batch_count. How command processing looks like in memcached: For each incoming connection memcached starts endless loop in function memcached_loop() where it reads network data to buffer, parse commands from buffer one by one, process commands and write answers to network socket. What goes wrong: In reproducer we have a sequence of two commands with SETQ (SETQ is the same as SET command but confirmation is not required) and GET command that should return a value set by one of the previous SETQ command. Processing of both SETQ commands finished successfully and something interesting happens when GET command in the incoming buffer and batch_count is equal to it's max value equal to 20. After processing the request with the second SETQ we process the return code from con->cb.process_request() (that is actually is memcached_bin_process()). Because processing finished successfully (rc != -1) and we are not willing to close a connection we go out of these conditions and come to a 'continue' and start loop from the beginning, where we do a network read. rc = con->cb.process_request(con); ... if (rc == -1) memcached_loop_error(con); if (con->close_connection) { break; } else if (rc == 0 && ibuf_used(con->in) > 0 && batch_count < con->cfg->batch_count) { goto next; } ... continue;
1 parent f13e529 commit efb4640

File tree

1 file changed

+3
-0
lines changed

1 file changed

+3
-0
lines changed

memcached/internal/memcached.c

Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -208,6 +208,9 @@ memcached_loop(struct memcached_connection *con)
208208
memcached_flush(con);
209209
fiber_reschedule();
210210
batch_count = 0;
211+
if (ibuf_used(con->in) > 0) {
212+
goto next;
213+
}
211214
continue;
212215
}
213216
memcached_flush(con);

0 commit comments

Comments
 (0)