-
Notifications
You must be signed in to change notification settings - Fork 24
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
Receiving trash from persistent connect when there was timeout before #113
Comments
Hello @deadbabe . Thank you for your bug report. I can reproduce this bug with What had happened:
I can't catch this bug under gdb:
This issues needs further investigation. As a workaround you can provide alternative |
tarantool-3.ini configuration fails and it seems the reason is gh-133 ('Receiving trash from persistent connect when there was timeout before'). Disabled both tarantool-2.ini and tarantool-3.ini configurations, where persistent connections are used, until the problem will be resolved. Related to #113.
tarantool-3.ini configuration fails and it seems the reason is gh-133 ('Receiving trash from persistent connect when there was timeout before'). Disabled both tarantool-2.ini and tarantool-3.ini configurations, where persistent connections are used, until the problem will be resolved. Related to #113.
tarantool-3.ini configuration fails and it seems the reason is gh-133 ('Receiving trash from persistent connect when there was timeout before'). Disabled both tarantool-2.ini and tarantool-3.ini configurations, where persistent connections are used, until the problem will be resolved. Related to #113.
tarantool-3.ini configuration fails and it seems the reason is gh-133 ('Receiving trash from persistent connect when there was timeout before'). Disabled both tarantool-2.ini and tarantool-3.ini configurations, where persistent connections are used, until the problem will be resolved. Related to #113.
Note (for myself): suffix/suffix_len are not stored in diff --git a/src/tarantool.c b/src/tarantool.c
index 91a9ac2..59d9e2d 100644
--- a/src/tarantool.c
+++ b/src/tarantool.c
@@ -1077,7 +1077,7 @@ PHP_METHOD(Tarantool, __construct) {
long port = 0;
zend_bool is_persistent = false, plist_new_entry = true;
- const char *suffix = NULL;
+ char *suffix = NULL;
size_t suffix_len = 0;
zend_string *plist_id = NULL;
@@ -1148,6 +1148,8 @@ PHP_METHOD(Tarantool, __construct) {
/* CHECK obj->schema */
obj->tps = tarantool_tp_new(obj->value, is_persistent);
/* CHECK obj->tps */
+ obj->suffix = suffix;
+ obj->suffix_len = suffix_len;
}
if (is_persistent && plist_new_entry) { This, however, does not fixes the problem on |
NB: When the |
tarantool-3.ini configuration fails and it seems the reason is gh-113 ('Receiving trash from persistent connect when there was timeout before'). Disabled both tarantool-2.ini and tarantool-3.ini configurations, where persistent connections are used, until the problem will be resolved. Related to #113.
tarantool-3.ini configuration fails and it seems the reason is gh-113 ('Receiving trash from persistent connect when there was timeout before'). Disabled both tarantool-2.ini and tarantool-3.ini configurations, where persistent connections are used, until the problem will be resolved. Related to #113.
See also tarantool-php/client@ee6bc94 |
When getting read timeout on persistent connect, socket is still alive and well and able to receive data.
This leads to getting trash from such connect on next request, or even receiving fully valid response, just not for the latest request, but for previous one.
This 06845559 kinda helps, but for complete safety it's might be better to reconnect on every uncertainty with connection - #112
Another workaround would be to mark timeout'd connects with a "dirty" flag and read out its buffer completely later, before next request or on php request shutdown.
The text was updated successfully, but these errors were encountered: