Обновление файлов на сервере и разница в часовых поясах

Если раньше возможно удаленная работа была в диковинку, то сегодня это является нормой и такой работой совершенно никого не удивишь.
Часто работодатель и исполнитель находятся довольно далеко друг от друга — в разных городах или даже странах. Поэтому возникает ситуация, когда нужно обновить сервер, находящийся в другом часовом поясе.

В процессе работы мне пришлось столкнуться с интересной проблемой, возникающей при обновлении удаленного сервера. Один из моих коллег написал несколько своих компонентов с использованием технологии MS Ajax. Компоненты довольно простые, в процессе тестирования все работало замечательно. Настала пора выложить обновление на сервер. Собрали обновление, загрузили файлы, проверяем — ничего не работает. Бились полдня, заказчик обрывает телефон … Что только мы не пытались сделать, каких только изменений не вносили.  Даже подняли систему на свежеустановленной виртуальной машине. Локально работает все, удаленно — хоть ты тресни никак.  В общем спать легли уже под утро и ничего не добились. Проснулись — видим письмо от заказчика. Типа он не надеялся что с утра все заработает, а мы все таки молодцы, все починили. Странно … ничего же не работало. Чешем репу — понимание не приходит. Решаем ничего пока на сервере по возможности не трогать до прояснения обстоятельств.

И тут через некоторое время появились у нас некоторые подозрения. Порылись на эту тему в интернете и нашли таки суть проблемы. Не буду томить дальше и напишу уже в чем было дело:

А дело было в особенностях работы IIS. Если кто то не знает или забыл — на всякий случай напомню, что IIS не загружает библиотеки прямо из тех файлов, которые ему дали при публикации сайта. Вместо этого он копирует эти файлы в свою служебную папку и уже оттуда загружает в память в дополнение к тем DLL которые были загружены ранее. После того, как мы загрузили несколько версий одного и того же файла IIS перезапускается для того, чтобы выгрузить из памяти ненужные (старые) DLL.

Так вот, IIS каждый раз при изменении DLL в качестве рабочего экземпляра выбирает тот, у которого дата изменения больше чем у остальных. НО IIS не загружает файлы, дата модификации которых находится в будущем!

Возникает ситуация: я находясь, скажем, во Владивостоке подготавливаю файлы для обновления, упаковываю их в архив и переношу на сервер, расположенный в Москве.
Разворачиваю файлы на сервере и получаю ситуацию, когда файлы, залитые на сервер с точки зрения IIS еще не могли быть созданы. Он сможет работать с этими файлами только после того, как в Москве будет как минимум столько же времени как было во Владивостоке, когда файлы заливали в архив. Только по прошествии 7 часов Московский сервер загрузит файлы в память и начнет с ними работать.

Эту проблему, конечно, решить очень просто — нужно проставить всем файлам сайта на сервере дату и время модификации равную текущему времени сервера с помощью любого файлового менеджера, например FAR или Total commander.

Почему проблему не решили сразу — вводит в заблуждение тот факт, что страницы сайта при тестировании сервера отображаются свежие. Проблема касается только тех DLL, которые указаны в References.

Надеюсь что информация окажется кому то полезной.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *