Added minTtl => 1 to AbstractZendServer options

[kynx]

As requested in #54

[marc-mabe]

I hacked it together to make the tests run but there is one failure :(

...............................F............................SS.SS 65 / 72 ( 90%)
..SSS.S

Time: 26.64 seconds, Memory: 3.25Mb

There was 1 failure:

1) ZendTest\Cache\Storage\Adapter\ZendServerShmTest::testSetAndGetExpiredItem
Failed asserting that 'value' is null.

/usr/local/zend/share/dist/zend-cache/test/Storage/Adapter/CommonAdapterTest.php:584
/usr/local/zend/share/dist/zend-cache/vendor/phpunit/phpunit/phpunit:47
/usr/local/zend/share/dist/test-zend-cache.php:8

FAILURES!
Tests: 72, Assertions: 392, Failures: 1, Skipped: 8.

install zend server and run the tests

• install zend server on a plain CentOS 7.1 VM using the provided installer
• clone zend-cache at /usr/local/zend/share/dist/zend-cache
• create test proxy script at /usr/local/zend/share/dist/test-zend-cache.php:

<?php

chdir(__DIR__ . '/zend-cache');
$_SERVER['argv'] = ['vendor/bin/phpunit', 'test/Storage/Adapter/ZendServerShmTest.php'];
//$_SERVER['argv'] = ['vendor/bin/phpunit', 'test/Storage/Adapter/ZendServerDiskTest.php'];
//$_SERVER['argv'] = ['vendor/bin/phpunit', 'test/Storage/Adapter/AbstractZendServerTest.php'];
$_SERVER['argc'] = count($_SERVER['argv']);
include 'vendor/bin/phpunit';

• link from document root: ln -s /usr/local/zend/share/dist/test-zend-cache.php /var/www/html/test-zend-cache.php
• download composer & /usr/local/zend/bin/php-cli ../composer.phar update
• call wget -q -O "$@" - http://localhost/test-zend-cache.php

PS: wow that was shitty. The good thing is that I found another bug that I fixed in #76

@weierophinney Could we have a way of automatically running the Zend Server tests? I think it's worst for Zend having both products not tested against.

[marc-mabe]

@kynx PS: before I merged your this PR into my local #76

[marc-mabe]

Ok this particular test failure is a bug in Zend Data Cache:

zend_disk_cache_store('zf::key', 'test', 1);
sleep(1);
var_dump(zend_disk_cache_fetch('zf::key'));
var_dump(zend_disk_cache_fetch('zf::key'));

zend_shm_cache_store('zf::key', 'test', 1);
sleep(1);
var_dump(zend_shm_cache_fetch('zf::key'));
var_dump(zend_shm_cache_fetch('zf::key'));

bool(false)
string(4) "test"
bool(false)
string(4) "test"

[ghost]

Hello Marc Bennewitz,
Thank you for contacting Zend Global Support.

This is a performance related "feature" - I write in quotes since it is not clear that its a feature and not a bottleneck / false info.

With caching, you sometimes cache something for few seconds and within this period, the object is refreshed and you expect new data. With user sessions, its easy to make sure the data is genuine and current. with global caches, what you actually like to achieve is performance, otherwise you won't be caching. So consequent requests bursting into a busy server needs to get latest cached version, however it needs to be generated, generation takes more time than a single request, and scripts cannot fail with false and many versions to be generated due to the need for live object.
Also, some caches live for literally days - those can "tolerate" getting stale for a few requests until a fresh version is generated, which requires a "tester" behind a browser just to refresh the page couple of times until a new version comes up (or some smarter request which forces live object fetch, bypassing the cache).

Zend Data Cache has a feature called "lock on expire", I believe we added a toggle directive for it in recent Zend Server versions, enabled by default.

What it basically does, is every 60 seconds once the object has been expired, it returns false, while consequent requests returns the "stale" object. this way, the receiving script which gets false generates a new copy and sets a new version for the cached object.
If the receiving script fails to generate a fresh version within a minute, another "false" is returned (there is a possible redundancy issue here... multiple versions generated in a perfect race condition).

So basically, as I understand the issue, ZF should either accept the behavior and create a fresh object when getting false, or implement a "smart" mechanism to mark a stale object and fetch live data (with single point of new version generation).
Let me know if this helps.

[marc-mabe]

Here is a link to share: https://support.zend.com/hc/en-us/articles/203995253-Expired-data-cache-can-be-read-by-subsequent-scripts-for-a-time

How we gonna deal with it:
My idea would be to add a capability for it Capability::lockOnExpire() : int which means if the value is 0 this particular feature is not supported or disabled. If >= 0 than this feature is available and defines the time in seconds how long the item will still be available after it has been expired.
-> As it requires a new capability (no BC break) it can be done in a minor release.

For the PSR-6 wrapper #54 it would mean that this capability also needs to be checked as in PSR-6 it's not allowed to retrieve expired items (as I understand).

@kynx @Maks3w If you agree I create ań issue for this new capability and this PR needs to wait.

[kynx]

Yup, sounds good to me. Though I'm getting worried about the number of adapters I'm excluding from #54 :| This isn't an entirely crazy feature.

[marc-mabe]

wait for #79 #80

[marc-mabe]

Closed by 06f3ae8 into develop. It's not merged into master because it requires #79 / #80 which is a new feature