Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

[Cache] memcache connect should not add duplicate entries on sequential calls#27318

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Merged
nicolas-grekas merged 1 commit intosymfony:3.4frompalex-fpt:BZR-27299
Jun 4, 2018

Conversation

@palex-fpt
Copy link

@palex-fptpalex-fpt commentedMay 20, 2018
edited by nicolas-grekas
Loading

QA
Branch?3.4 (be careful when merging)
Bug fix?yes
New feature?no
BC breaks?no
Deprecations?no
Tests pass?no
Fixed tickets#27299
LicenseMIT

MemcachedCache::createConnection adds server to list of servers on every call. But resets this list only when it is not empty and does not match configured list.
This leads to follow: after first call list contains correct entry. After second it has server entry twice. After third it clears list and set it with correct value.

With combination of libmemcached bug (segfault on adding server after reset nonempty list) it makes impossible to use MemcachedCache::createConnection to create persistent connections.

@nicolas-grekasnicolas-grekas changed the titlebug #27299 [Cache] memcache connect should not add duplicate entries …[Cache] memcache connect should not add duplicate entries on sequential callsMay 20, 2018
@nicolas-grekasnicolas-grekas added this to the3.4 milestoneMay 21, 2018
@nicolas-grekas
Copy link
Member

@palex-fpt why did you close ?

@palex-fpt
Copy link
Author

oops. I did not notice it was added to 3.4 milestone. I thought it should be based on 3.4 branch and resubmit it.

@palex-fptpalex-fpt reopened thisMay 29, 2018
@chalasr
Copy link
Member

@palex-fpt no need for a new PR, we can switch the target branch while merging, but you can also do it on your sidehttps://blog.github.com/2016-08-15-change-the-base-branch-of-a-pull-request/ (and rebase).

@palex-fptpalex-fpt changed the base branch from3.3 to3.4May 29, 2018 12:28
@palex-fptpalex-fpt changed the base branch from3.4 to3.3May 29, 2018 12:54
@nicolas-grekasnicolas-grekas changed the base branch from3.3 to3.4June 4, 2018 20:06
@nicolas-grekas
Copy link
Member

Thank you@palex-fpt.

@nicolas-grekasnicolas-grekas merged commitaf06990 intosymfony:3.4Jun 4, 2018
nicolas-grekas added a commit that referenced this pull requestJun 4, 2018
…on sequential calls (Aleksey Prilipko)This PR was submitted for the 3.3 branch but it was merged into the 3.4 branch instead (closes#27318).Discussion----------[Cache] memcache connect should not add duplicate entries on sequential calls| Q             | A| ------------- | ---| Branch?       | 3.4 (be careful when merging)| Bug fix?      | yes| New feature?  | no| BC breaks?    | no| Deprecations? | no| Tests pass?   | no| Fixed tickets |#27299| License       | MITMemcachedCache::createConnection adds server to list of servers on every call. But resets this list only when it is not empty and does not match configured list.This leads to follow: after first call list contains correct entry. After second it has server entry twice. After third it clears list and set it with correct value.With combination of libmemcached bug (segfault on adding server after reset nonempty list) it makes impossible to use MemcachedCache::createConnection to create persistent connections.Commits-------af06990 bug#27299 [Cache] memcache connect should not add duplicate entries on sequential calls
@palex-fptpalex-fpt deleted the BZR-27299 branchJune 6, 2018 11:32
This was referencedJun 25, 2018
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Projects

None yet

Milestone

3.4

Development

Successfully merging this pull request may close these issues.

4 participants

@palex-fpt@nicolas-grekas@chalasr@carsonbot

[8]ページ先頭

©2009-2025 Movatter.jp