• Article Type: General
• Product: Aleph
• Product Version: 17.01

Description:
On our production server, html changes show immediately in the OPAC unless related to configuration tables. With configuration table changes, the www_server has to be stopped and restarted. Otherwise, we see changes immediately.

On our test server, html changes do NOT show immediately in the OPAC. We always seem to have to stop / restart the www_server on the test machine to force changes to show in the OPAC.

We expect to have to stop / restart the www_server for table configuration changes related to OPAC display. But why do HTML changes show immediately in the production server but not in the test server? Is there a configuration file we need to adjust or something in Apache? Any clues to a possible solution would be helpful since library staff are editing html files on the test server and it's a pain to stop / restart the server every few minutes for them. If this problem has no easy solution, could we put the utility job string for doing this procedure in the job_list, and if so, what would it look like?

Resolution:
This works this way due to the processing of WWW_MAX_REQUESTS. This variable, set in $aleph_proc/www_server, tells the system how many OPAC requests to process before an automatic restart. On both your production and test servers, this is set to 2000. On production, it appears to reset an average of maybe 5-6 times per day, which would give relatively quick access to new pages, as these restarts would mostly be during the 8-5 hours. On test, however, you virtually never hit 2000 requests, so a manual restart is always necessary.

This gives you a way out of restarting the servers every few minutes. You could set the variable to its lowest value (30), then put the burden on your testers to initiate 30 OPAC transactions in order to see the changes take effect. I don't know the exact definition of a "request", but I would think that a search would surely count, and possibly even looking at a record, so 30 shouldn't take long at all to reach.

• Article last edited: 10/8/2013