firstimpression

Hi, Is there any documentation how exactly the "pruning" of bucket tables work? My issues right now: 1. Sometimes bucket tables have leftovers because maintenance script did not run at a certain hour. An expected behavior would be that any subsequent run would take care of everything that is left unprocessed in the bkt tables. But in reality I have to manually run the "republish.php" script to take care of those leftovers. 2. Let's say I have 1 master server and 2 slave servers. If the maintenance runs in the order: maintenance-distributed on slave 1, maintenance on master, maintenance-distributed on slave 2 - it looks like the data pulled from slave 2 would be left in master's bucket tables forever (until I run on republish.php). The cause is that after the record in "log_maintenance_statistics" is made, the maintenance would not do anything again for the same hour. Any ideas how to solve that?

@kanuns, this is totally possible. If you set up MySQL replication you can replicate your set up whenever MySQL slaves will be able to connect to master. If you know IP addresses of your remote servers then you can run maintenance-distributed to pull statistics to master server. With this scheme you will have all the stats on the master server. To have all the rest of the stuff synchronized you will have to write a few scripts that will put graphic assets to your remote servers.

Don't do this. https://github.com/revive-adserver/revive-adserver/issues/102 Even after 6 years of this discussion I want to confirm that InnoDB is still ridiculously slow with Revive when logging impressions at high frequency. Tried a lot of InnoDB settings, in the end reverted the "bkt" tables to MyISAM. I think ON DUPLICATE KEY UPDATE in all logging scripts causes a type of lock that makes all the mentioned InnoDB advantages useless.

According to this webserver config, any request like mydomain.com/images/image.jpeg would be fetched from /opt/revive-adserver-4.0.1/www/images/image.jpeg. You have to configure your webserver accordingly if you want to serve over HTTP anything that is outside of www folder. You can use Alias or RewriteRule directives.

@BrianB, did you ever solve it?

Yes, look in /etc/php.ini and apache configs (usually in /etc/httpd/) for anything that refers to "/hermes/phpsessions". I think there is some strange ASCII symbol that someone mistyped in a config before path. Eg. session.save_path=`/hermes/phpsessions If you fix the setting don't forget to reload the webserver to apply the change.

@Accuraty, from my experience, after you run out of disk space, and after you solve the issue by freeing up some space, you have to restart MySQL. Otherwise it just continues to behave as if there is still no space available.

@duplexcleaning, this soudns like an issue with PHP session storage. Try to enable PHP error logging in php.ini (the setting called log_errors), and see if there are any error messages in webserver error log. My bet is that your session storage folder is not writable.

Are you absolutely positive that error logging is enabled, and still there are no error messages in logs? Keep in mind that you can enable: Revive's native logging Webserver logging PHP error logging Those are different logs that work on different levels of systems, enable them all and check them all. Does the error appear instantly, or after some long time?

What is the document root of your webserver?

Got it, had to run "composer update" in install directory to download dependencies Sinergi and Symfony.

I performed a normal upgrade from 3.2.2, and everything worked except upgrade of DeliveryLimitations plugin (request returned Error 500). Now when I try to manually enable the plugin, getting error 500. The PHP error log would pop the error below. PHP Fatal error: Class 'Sinergi\\BrowserDetector\\Browser' not found in /var/ox/lib/OX/Plugin/Component.php on line 64, referer: http://localhost/admin/plugin-index.php PHP Stack trace:, referer: http://localhost/admin/plugin-index.php PHP 1. {main}() /admin/plugin-index.php:0, referer: http://localhost/admin/plugin-index.php PHP 2. OX_PluginManager->enablePackage($name = 'openXDeliveryLimitations', $reparse = *uninitialized*) /var/ox/www/admin/plugin-index.php:192, referer: PHP 3. OX_Plugin_ComponentGroupManager->enableComponentGroup($name = 'Client', $extends = 'deliveryLimitations') /var/ox/lib/OX/Plugin/PluginManager.php:504, referer: http://localhost/admin/plugin-index.php 4. OX_Component->getComponents($extension = 'deliveryLimitations', $group = 'Client', $recursive = TRUE, $enabledOnly = FALSE) /var/ox/lib/OX/Plugin/ComponentGroupManager.php:641, referer: http://localhost/admin/plugin-index.php 5. OX_Component::factory($extension = 'deliveryLimitations', $group = 'Client', $component = 'BrowserVersion') /var/ox/lib/OX/Plugin/Component.php:189, referer: http://localhost/admin/plugin-index.php How to fix this? Do I have to separately install Sinergi browser detector...? Thank you

Can you give me any hint how to check if database was upgraded? Some specific field value, or type? But except the `rv_application_variable`.`oa_version`

No. That's where I got surprised, that no further action was required. I refreshed the page, and probabluy because /var/INSTALLED file is present it just acts as usual, just like a normal upgraded installation.

Does upgrade from 3.2.2 to 4.0.1 include any database changes? When I ran a test upgrade on a dev server, after copying files I entered admin GUI, and it gave me message, unfortunately, it is gone now, but it was something like "your version is 4.0.1 no upgrade is needed". Is that normal??