I need configure default lifetime from cache Adapter, but something weird has been happening, the follows don't works!? :/
use Symfony\Component\Cache\Adapter\FilesystemAdapter;
// in seconds; applied to cache items that don't define their own lifetime
// 0 means to store the cache items indefinitely (i.e. until the files are deleted)
$cache = new FilesystemAdapter('my_namespace', 5); // <-- default lifetime 5 seconds
$latestNews = $cache->getItem('latest_news');
if (!$latestNews->isHit()) {
$news = ['title' => '...', 'createdAt' => (new \DateTime())->format('Y-m-d H:i:s')];
$cache->save($latestNews->set($news));
} else {
$news = $latestNews->get();
}
Reference http://symfony.com/doc/current/components/cache/cache_pools.html#filesystem-cache-adapter
The first time, the cached file content shows:
2147483647 <-- 2038-01-18 22:14:07 :/ ?
latest_news
a:2:{s:5:"title";s:3:"...";s:9:"createdAt";s:19:"2016-10-07 09:16:50";}
and of course this item don't expire after 5 seconds :/ (I've cleared the cache directory manually).
On the other hand, if we use $latestNews->expiresAfter(5); all works fine:
1475849350 <-- 2016-10-07 10:09:10 \o/ OK
latest_news
a:2:{s:5:"title";s:3:"...";s:9:"createdAt";s:19:"2016-10-07 10:09:05";}
Reference http://symfony.com/doc/current/components/cache/cache_items.html#cache-item-expiration
5 seconds after the item expired correctly.
I tested that with Symfony\Component\Cache\Adapter\ApcuAdapter and occurs the same problem too.
What happens with default lifetime (constructor parameter) in cache adapters ? I missing something here :/ ?
Is an old issue [Cache] Fix default lifetime being ignored that affect framework version prior to the 3.1
Upgrading the Symfony framework should fix it.
Related
Question
How can I programmatically tell to a Guzzle Client to delete / eliminate or refresh a Cache folder?
An even better, to target a specific folder X or Y?
The reason is not important, but I can put an example for better understand.
Let's say we have book api (which is mine) an with another service we call it with Guzzle Client and has a cache of 1 hour to get some book prices. The cache is at folder
framework/cache/data/GuzzleFileCache/public/books/prices
curl -X GET https://example.com/books/prices
Now, someone updates the books prices.
If my main service call books/orices will have now the old prices because 1 hour was not passed.
So I've a system that when a book price is updated I can fire an event to my main service and tell whatever I want. Unsurprisingly what I want my main service to do is to invalidate the cache at framework/cache/data/GuzzleFileCache/public/books/prices when that even if fired.
How can I do that?
Code
First of all, note to say that I'm actually using Lumen but it shouldn't be a problem as works the same as Laravel.
So let's say that I've a specific folder at framework/cache/data/GuzzleFileCache/public/blogs and I need at certain point invalidate this cache (for whatever reason).
*I know you can just delete manually the folder, and therefore probably do it programmatically, but is there a better way? *
This is my current code to create/use the cache with a Guzzle Client
$ttl = 3600;
// Create a HandlerStack
$stack = HandlerStack::create();
// Create Folder GuzzleFileCache inside the providen cache folder path
$requestCacheFolderName = 'framework/cache/data';
// Retrieve the bootstrap folder path of your Laravel Project
$cacheFolderPath = 'GuzzleFileCache/public/blogs';
// Instantiate the cache storage: a PSR-6 file system cache with
$cache_storage = new Psr6CacheStorage(
new FilesystemAdapter(
$requestCacheFolderName,
$ttl,
$cacheFolderPath
)
);
// Add Cache Method
$stack->push(
new CacheMiddleware(
new GreedyCacheStrategy(
$cache_storage,
$ttl // the TTL in seconds
)
),
'greedy-cache'
);
So one very ugly way would be to just delete that folder, here is some pseudocode
rmdir('framework/cache/data/GuzzleFileCache/public/blogs');
But I'm looking at something like
use Illuminate\Support\Facades\Http; // <--- laravel guzzle client
Http::cacheInvalidate('framework/cache/data/GuzzleFileCache/public/blogs');
Dependencies
"php": "^8.1.3",
"flipbox/lumen-generator": "^9.1",
"guzzlehttp/guzzle": "^7.4",
"kevinrob/guzzle-cache-middleware": "^4.0",
"laravel/lumen-framework": "^9.0",
"symfony/cache": "^6.1"
References
HTTP Client
Kevinrob/guzzle-cache-middleware
Well. I could not invalidate the cache by tags but at least all the cache together, which is already something. Here some code if may help someone.
use Symfony\Component\Cache\Adapter\FilesystemAdapter;
use Symfony\Component\Cache\Adapter\TagAwareAdapter;
// Instantiate the cache storage: a PSR-6 file system cache with
$cache = new TagAwareAdapter(
// Adapter for cached items
new FilesystemAdapter(
$requestCacheFolderName,
1,
$cacheFolderPath
)
);
$cache->clear();
$value = Cache::remember('test', 1, function() {
return 'Jabra2';
});
This is just a sample code. It should return 'Jabra2' in $value. But, on my production, though it's set to 1 minute, it is still return old value 'Jabra'.
Any idea why it's happening ? (I am using file cache)
The second argument is seconds, not minutes. You're setting the cache to expire after 1 second.
It used to be minutes up to 5.7, but was changed in 5.8.
The recommended way is to not use integers but a Carbon instance:
Cache::remember('test', now()->addMinute(), function() { ... });
Docs on the change: https://laravel.com/docs/5.8/upgrade#cache-ttl-in-seconds
I've just installed Memcached and i'm trying to use it to cache results of various queries done with Doctrine ORM (Doctrine 2.4.8+, Symfony 2.8+).
My app/config/config_prod.yml have this :
doctrine:
orm:
metadata_cache_driver: memcached
result_cache_driver: memcached
query_cache_driver: memcached
And i tried to useResultCache() on 2 queries like that (i just replaced the cache id here for the example) : return $query->useResultCache(true, 300, "my_cache_id")->getArrayResult();. Special queries here because they're native queries (SQL) due to their complexity, but the method is available for any query (class AbstractQuery) so i assume it should work.
Unfortunately, it doesn't. Everytime i refresh the page, if i just did a change in the database, the change is displayed. I've checked the stats of memcached and it seems there're still some cache hits but i don't really know how, cf. what i just said.
Does anyone has an idea on why the cache doesn't seem to be used here to get the supposedly cached results ? Did i misunderstand something and the TTL is ignored somehow ?
There's no error generated, memcached log is empty.
As requested by #nifr, here is the layout of my code to create the 2 native queries i put a Memcached test on :
$rsm = new ResultSetMapping;
$rsm->addEntityResult('my_entity_user', 'u');
// some $rsm->addFieldResult('u', 'column', 'field');
// some $rsm->addScalarResult('column', 'alias');
$sqlQuery = 'SELECT
...
FROM ...
INNER JOIN ... ON ...
INNER JOIN ... ON ...
// some more join
WHERE condition1
AND condition2';
// some conditions added depending on params passed to this function
$sqlQuery .= '
AND (fieldX = (subrequest1))
AND (fieldY = (subrequest2))
AND condition3
AND condition4
GROUP BY ...
ORDER BY ...
LIMIT :nbPerPage
OFFSET :offset
';
$query =
$this->_em->createNativeQuery($sqlQuery, $rsm)
// some ->setParameter('param', value)
;
return $query->useResultCache(true, 300, "my_cache_id")->getArrayResult();
So, it seems for some reason Doctrine doesn't succeed to get the ResultCacheDriver. I tried to set it before the useResultCache() but i had an exception from Memcached : Error: Call to a member function get() on null.
I've decided to do it more directly by calling Memcached(). I guess i'll do this kind of stuff in controllers and repositories, depending on my needs. After some tests it works perfectly.
Here is what i basically do :
$cacheHit = false;
$cacheId = md5("my_cache_id"); // Generate an hash for your cache id
// We check if Memcached exists, if it's not installed in dev environment for instance
if (class_exists('Memcached'))
{
$cache = new \Memcached();
$cache->addServer('localhost', 11211);
$cacheContent = $cache->get($cacheId);
// We check if the content is already cached
if ($cacheContent != false)
{
// Content cached, that's a cache hit
$content = $cacheContent;
$cacheHit = true;
}
}
// No cache hit ? We do our stuff and set the cache content for future requests
if ($cacheHit == false)
{
// Do the stuff you want to cache here and put it in a variable, $content for instance
if (class_exists('Memcached') and $cacheHit == false) $cache->set($cacheId, $content, time() + 600); // Here cache will expire in 600 seconds
}
I'll probably put this in a Service. Not sure yet what's the "best practice" for this kind of stuff.
Edit : I did a service. But it only works with native sql... So the problem stays unsolved.
Edit² : I've found a working solution about this null issue (meaning it couldn't find Memcached). The bit of code :
$memcached = new \Memcached();
$memcached->addServer('localhost', 11211);
$doctrineMemcached = new \Doctrine\Common\Cache\MemcachedCache();
$doctrineMemcached->setMemcached($memcached);
$query
->setResultCacheDriver($doctrineMemcached)
->useResultCache(true, 300);
Now, i would like to know which stuff should i put in the config_prod.yml to just use the useResultCache() function.
In our intranet application(s) we use SSO (single sign on) login while the sessions both on client and auth origin applications are stored in memcached.
The sessions are set to live for 12h before the garbage collector may consider them as for removal. Both applications are written using ZF2.
Unfortunately, the problem is, that after certain period of time (I don't have the exact value) the browser loses the session which causes the redirection to auth origin, where the session is still alive thus user is redirected back to client and the browser session is refreshed. This is not a big deal if the user has no unsaved work as these two redirects happen within 1 second and user even may not notice them.
But it really is a big deal when user has unsaved work and even an attempt to save it leads to redirects and the work is gone.
Here is the configuration of session in Bootstrap.php:
class Module
{
public function onBootstrap(MvcEvent $e)
{
// ...
$serviceManager = $e->getApplication()->getServiceManager();
$sessionManager = $serviceManager->get('session_manager_memcached');
$sessionManager->start();
Container::setDefaultManager($sessionManager);
// ...
}
public function getServiceConfig()
{
return array(
'factories' => array(
// ...
'session_manager_memcached' => function ($sm) {
$systemConfig = $sm->get('config');
$config = new SessionConfig;
$config->setOptions(array(
'phpSaveHandler' => 'memcache',
'savePath' => 'tcp://localhost:11211?timeout=1&retry_interval=15&persistent=1',
'cookie_httponly' => true,
'use_only_cookies' => true,
'cookie_lifetime' => 0,
'gc_maxlifetime' => 43200, // 12h
'remember_me_seconds' => 43200 // 12h
));
return new SessionManager($config);
},
// ...
);
}
}
The authentication service is defined as
'authService' => function ($sm) {
$authService = new \Zend\Authentication\AuthenticationService;
$authService->setStorage(new \Zend\Authentication\Storage\Session('user_login'));
return $authService;
},
the session storage uses the same memcached session manager.
Then anywhere within the application a session value needs to be retrieved or set I just use a \Zend\Session\Container like this:
$sessionContainer = new \Zend\Session\Container('ClientXYZ');
$sessionContainer['key1'] = $val1;
// or
$val2 = $sessionContainer['key2'];
The SSO is requested for the active session at any action using the token from session which contains PHPSESSID from the auth origin. It's quite complicated to describe here within this question.
Additionally an authentication service stores a user identity (with roles for ACL) also in memcached session - using the same settings. Obviously this is now the place which causes confusion. Apparently the session storage of authentication service times out prematurely causing the ACL to retrieve no user identity to check leading into SSO logout sequence (but because user didn't really log out, SSO redirects the user back as described above).
I'm not sure how much code should I (and can I) share here, maybe you'll lead me to the solution straight away or just by asking me some questions. I am quite helpless right now after many hours of debugging and trying to identify the problem.
Somewhere I have read that memcached wipes out the memory once the session cookie gets 1MB in size - may this be the case? For the user identity we save just general user information and array of roles, I'd guess this could be max. up to few kb in size...
EDIT 1: To dismiss all guesses and to save your time, here few facts (to keep an eye on):
only memcached is used
cookies serve only to transport the PHPSESSID between the browser and server and it's value is the key for memory chunk in memcached where the data is stored
client and SSO auth apps are running on one server (be it integration, staging or live environment, still just one server)
session on client app goes off randomly causing it to redirect to SSO auth app, but here the session is still alive thus user is redirected back to client app which gets new session and user stays logged in
this should dismiss discussion about memcached being wiped off or restarted
also observation on telneted memcached directly shows both data chunks (for client and auth apps) are established almost at the same time with the same ttl
I am going to implement some dies in PHP and returns in JS parts to catch the moment when the session is considered gone and further inspect the browser cookie, memcached data, etc. and will update you (unless somebody comes with explanation and solution).
public function initSession()
{
$sessionConfig = new SessionConfig();
$sessionConfig->setOptions([
'cookie_lifetime' => 7200, //2hrs
'remember_me_seconds' => 7200, //2hrs This is also set in the login controller
'use_cookies' => true,
'cache_expire' => 180, //3hrs
'cookie_path' => "/",
'cookie_secure' => Functions::isSSL(),
'cookie_httponly' => true,
'name' => 'cookie name',
]);
$sessionManager = new SessionManager($sessionConfig);
// $memCached = new StorageFactory::factory(array(
// 'adapter' => array(
// 'name' =>'memcached',
// 'lifetime' => 7200,
// 'options' => array(
// 'servers' => array(
// array(
// '127.0.0.1',11211
// ),
// ),
// 'namespace' => 'MYMEMCACHEDNAMESPACE',
// 'liboptions' => array(
// 'COMPRESSION' => true,
// 'binary_protocol' => true,
// 'no_block' => true,
// 'connect_timeout' => 100
// )
// ),
// ),
// ));
// $saveHandler = new Cache($memCached);
// $sessionManager->setSaveHandler($saveHandler);
$sessionManager->start();
return Container::setDefaultManager($sessionManager);
}
This is the function I use in order to create a cookie for X user. The cookie lives for 3 hours, no matter if there are redirects or if the user has closed the browser. It's still there. Just call this function in your onBootstrap() method from Module.php.
While logging, I use The ZF2 AuthenticationService and the Container to store and retrieve the user data.
I suggest you to install these module for easier debugging.
https://github.com/zendframework/ZendDeveloperTools
https://github.com/samsonasik/SanSessionToolbar/
Memcached & gc_maxlifetime
When using memcached as session.save_handler, garbage collection of session will not be done.
Because Memcached works with a TTL (time to live) value, garbage collection isn't needed. An entry that has not lived long enough to reach the TTL age will be considered "fresh" and will be used. After that it will be considered "stale" and will not be used any longer. Eventually Memcached will free the memory used by the entry, but this has nothing to do with session garbage collection of PHP.
In fact, the only session.gc_ setting that's actually used in this case is session.gc_maxlifetime, which will be passed as TTL to Memcached.
In short: garbage collection is not an issue in your case.
Memcached & Cronjobs
As you are using Memcached as storage for your sessions, any cronjobs provided by the OS that will manually clean session folders on disk (like Ubuntu does) will have no effect. Memcached is memory storage, not disk storage.
In short: cronjobs like this are not an issue in your case.
Issue of app, not SSO
You state that the SSO server/authority is on the same machine as the SSO client (the application itself), is using the same webserver / PHP configuration, and is using the same instance of Memcached.
This leads me to believe we have to search in how session management is done in the application, as that is the only difference between the SSO authority and client. In other words: we need to dive into Zend\Session.
Disclaimer: I've professionally worked on several Zend Framework 1 applications, but not on any Zend Framework 2 applications. So I'm flying blind here :)
Configuration
One thing I notice in your configuration is that you've set cookie_lifetime to 0. This actually means "until the browser closes". This doesn't really make sense together with remember_me_seconds set to 12 hours, because a lot of people will have closed their browser before that time.
I suggest you set cookie_lifetime to 12 hours as well.
Also note that remember_me_seconds is only used when the Remember Me functionality is actually used. In other words: if Zend\Session\SessionManager::rememberMe() is called.
Alternative implementation
Looking at the way you've implemented using Memcached as session storage, and what I can find on the subject, I'd say you've done something different than what seems to be "the preferred way".
Most resources on this subject advise to use Zend\Session\SaveHandler\Cache (doc, api) as save-handler, which gives you the ability to use Zend\Cache\Storage\Adapter\Memcached (doc, api). This gives you much more control over what's going on, because it doesn't rely on the limited memcached session-save-handler.
I suggest you try this implementation. If it won't immediately resolve your issue, there are at least a lot more resources to find on the subject. Your chances of finding a solution will be better IMHO.
This answer might not immediately address the cause of your memcache issue, but because of the unreliable nature of memcache I would suggest to make a backup of your memcached data in some persistent storage.
Memcaching your data will help you to improve performance of your application but it is not fail-safe.
Maybe you can make a fallback (persistent) storage in your AuthenticationService instance. Then first you try to get your authentication data from your memcache and if nothing is found you check if there is something available in your persistent storage.
This will at least solve all issues with unexpected memcache loss issues.
My ZF2 application logs out after a short period of inactivity - say, 60 minutes or so - and I can't understand why.
I have an 'auth' object which is a singleton that composes an instance of Zend\Session\Container. Its constructor creates the container with this following line:
$this->session = new Container('Auth');
The auth object has a login() method that stores the current user with the following line:
$this->getSession()->userId = $user->id;
The auth object also has an isLoggedIn() method that tests the status as follows:
if ($this->getSession()->userId) {
return true;
}
return false;
That's all pretty straightforward. Yet, from time to time when the bootstrap is checking to see if we are logged in, it comes back with false. Why?
Here's a printout of the config from the session manager:
'cookie_domain' => '',
'cookie_httponly' => false,
'cookie_lifetime' => 604800,
'cookie_path' => '/',
'cookie_secure' => '',
'name' => 'MyApplication',
'remember_me_seconds' => 1209600,
'save_path' => '/var/lib/php5',
'use_cookies' => true,
As you can see, the remember_me_seconds and cookie_lifetime are set to 2 weeks and 7 days respectively. Is there some other setting that I should be looking at?
I read somewhere that the default save handler, 'file', does not support concurrency. My bootstrap also opens a session container to the auth namespace with new Container('Auth'). Could this be conflicting with the Container in the auth singleton ? I doubt it, since the problem would then be likely to occur in periods of high activity (not after a period of inactivity). Also, I would expect to see an exception.
Woe is me.
EDIT: It is also worth noting that the session ID does not change when logged out, or upon logging back in.
There are many points why a session can become invalid.
check always following points:
session cookie lifetime (should become invalid only when closing the browser)
session lifetime itself
cache_expire key in zf2 (should be higher than session lifetime)
Try to add this
//NEW SECTION
'cache_expire' => 60 * 26, <-- this may help
'gc_maxlifetime' => 60 * 60 * 24, <-- or this