Thanks to visit codestin.com
Credit goes to github.com

Skip to content

[Cache] Fix extensibility of TagAwareAdapter::TAGS_PREFIX #23063

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

Closed
wants to merge 1 commit into from

Conversation

wucdbm
Copy link
Contributor

@wucdbm wucdbm commented Jun 5, 2017

Q A
Branch? 3.3
Bug fix? yes
New feature? no
BC breaks? no
Deprecations? no
Tests pass? yes
Fixed tickets
License MIT
Doc PR

It seems that when MemcachedAdapter is used with TagAwareAdapter, it fails to fetch items, even though I thoroughly tested fetching items with the exact same keys under the same namespace.

Edit: Just to clarify, CacheItem::isHit() always returned false. This is what I meant with the above.

Turns out the issue lies in const TAGS_PREFIX = "\0tags\0"; for unknown to me reasons. Hardcoding that to '__tags__' in my project did the trick and I've been using it for a couple of days now and it seems fine.

The reason I had to completely copy/paste this file in my local project is self:: instead of static:: usage. I am not sure whether that is a mistake or is done on purpose, but in order to have this work for me I need to be able to override that constant. Going with static:: seems like a good solution to me, then I can set whatever prefix I need for the tags.

PS: Not exactly sure what to do with tests. Any help would be appreciated.

It seems that when MemcachedAdapter is used with TagAwareAdapter, it fails to fetch items, even though I thoroughly tested fetching items with the exact same keys under the same namespace.

Turns out the issue lies in `const TAGS_PREFIX = "\0tags\0";` for unknown to me reasons. Hardcoding that to '__tags__' in my project did the trick and I've been using it for a couple of days now and it seems fine.

The reason I had to completely copy/paste this file in my local project is self:: instead of static:: usage. I am not sure whether that is a mistake or is done on purpose, but in order to have this work for me I need to be able to override that constant. Going with static:: seems like a good solution to me, then I can set whatever prefix I need for the tags.
@nicolas-grekas
Copy link
Member

You are not supposed to change the value of this const, that's why self:: is used.
The core issue is that memcached doesn't handle the NUL char in keys.
Did you enable its binary protocol? $client->setOption(\Memcached::OPT_BINARY_PROTOCOL, true);
Does that fix the root issue?

@nicolas-grekas nicolas-grekas added this to the 3.3 milestone Jun 5, 2017
@nicolas-grekas
Copy link
Member

nicolas-grekas commented Jun 5, 2017

As a side note, you should know that with its LRU mechanism, Memcached is not suited for storing tags.
Tags must have a longer persistence duration than any items that reference them.
Using Memcached, it's your responsibility to be sure that this is the case. The only way to achieve it is to be sure that your Memcached memory size will never be exhausted, thus will never trigger LRU.

Copy link
Member

@nicolas-grekas nicolas-grekas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The code uses a mix of static:: and self::!
This makes things consistent in a most bc-friendly way.
👍 then!
(but my previous comments still apply)

@nicolas-grekas nicolas-grekas changed the title [Cache] MemcachedAdapter not working with TagAwareAdapter [Cache] Fix extensibility of TagAwareAdapter::TAGS_PREFIX Jun 5, 2017
@wucdbm
Copy link
Contributor Author

wucdbm commented Jun 5, 2017

Thank you for your quick response. I'll give $client->setOption(\Memcached::OPT_BINARY_PROTOCOL, true); a try.

As for LRU, the project will run with obscenely high amount of memory on a separate Memcached instance for a critical subset of the data it caches. Besides, there's always the option to give Redis a go.

@nicolas-grekas
Copy link
Member

Thank you @wucdbm.

nicolas-grekas added a commit that referenced this pull request Jun 5, 2017
…(wucdbm)

This PR was submitted for the 3.3 branch but it was merged into the 3.2 branch instead (closes #23063).

Discussion
----------

[Cache] Fix extensibility of TagAwareAdapter::TAGS_PREFIX

| Q             | A
| ------------- | ---
| Branch?       | 3.3
| Bug fix?      | yes
| New feature?  | no
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets |
| License       | MIT
| Doc PR        |

It seems that when MemcachedAdapter is used with TagAwareAdapter, it fails to fetch items, even though I thoroughly tested fetching items with the exact same keys under the same namespace.

Edit: Just to clarify, `CacheItem::isHit()` always returned `false`. This is what I meant with the above.

Turns out the issue lies in `const TAGS_PREFIX = "\0tags\0";` for unknown to me reasons. Hardcoding that to `'__tags__'` in my project did the trick and I've been using it for a couple of days now and it seems fine.

The reason I had to completely copy/paste this file in my local project is `self::` instead of `static::` usage. I am not sure whether that is a mistake or is done on purpose, but in order to have this work for me I need to be able to override that constant. Going with static:: seems like a good solution to me, then I can set whatever prefix I need for the tags.

PS: Not exactly sure what to do with tests. Any help would be appreciated.

Commits
-------

405f64b [Cache] MemcachedAdapter not working with TagAwareAdapter
@nicolas-grekas
Copy link
Member

Merged into branch 3.2, congrats for your first PR :)

@nicolas-grekas nicolas-grekas modified the milestones: 3.2, 3.3 Jun 5, 2017
@fabpot fabpot mentioned this pull request Jun 6, 2017
@fabpot fabpot mentioned this pull request Jul 4, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants