Сеансовые куки ASP.net потеряны или удалены

Вы захотите взглянуть на своего поставщика состояния сеанса, чтобы узнать, будет ли он работать на двух серверах / экземплярах приложения .net. Если они установлены, например, на inProc, то вы наверняка столкнетесь с этой проблемой, поскольку каждый сеанс будет привязан к потоку, в котором он был создан. Вместо этого вы хотите абстрагировать это либо до asp.net state service, к которому имеют доступ обе машины, или, что еще лучше, вам следует использовать решение для распределенного кэширования, такое как проект Microsoft Velocity, который будет распределять сеансы между двумя машинами в случае отказа одной из них.

Есть и другие способы справиться с этим: использовать закрепленные сеансы в балансировщике нагрузки (не рекомендуется) или перейти к сеансу без файлов cookie, который будет работать, но может вызвать некоторые головные боли в вашем коде.

В нашем бизнесе у нас есть первичный и вторичный сервер с распределенным кешем позади него, так что, если одна машина выйдет из строя, другая может взять на себя управление. Тот же принцип применяется к балансировке нагрузки, и как только вы начнете иметь более одной машины или даже более одного экземпляра в пуле приложений, вам придется для этого кодировать.

Если вы используете Velocity для сеанса, убедитесь, что кеш, который вы выбираете для хранения сеансов, не может быть удален.

Я думаю, что Middletone прав, за исключением того, что он не объясняет, почему проблема не может быть воспроизведена с помощью Firefox. Балансировщик нагрузки - подозреваемый номер один; Было бы хорошо проверить, есть ли у него алиби, отключив все серверы приложений, кроме одного (если это возможно, и в то время, когда он может справиться с нагрузкой), и посмотреть, существует ли проблема. Если да, то это не балансировщик нагрузки, и вы можете поискать в другом месте. Если нет, то это балансировщик нагрузки.

Кстати: закрепленные сеансы - это плохо, потому что сеансы, которые в нем находятся, не защищены избыточностью. Кроме того, балансировщик нагрузки не может распределять данные на наименее загруженный сервер в определенный момент времени, он может принять решение только в начале сеанса, а затем сохранить пользователя на месте.

Если окажется, что у вас проблема с балансировщиком нагрузки, первое, что я сделаю, это включу привязку сеанса, а затем, возможно, поищу другое решение с успокаивающим фоном рабочей производственной среды.

Yanking "внешние ссылки" из вспышки может быть так же просто, как, например:

curl -s http://hostname/path/to/file.swf | strings | grep http

Конечно, это не удастся, если автор предпринял какую-либо попытку скрыть URL.

YMMV много. Удачи!

Java позволяет использовать экземпляр Class для вызова статических методов, но не следует путать это разрешение, как если бы метод вызывался для экземпляра, используемого для его вызова.

instance.method ();

совпадает с

Class.method ();

Shoot, я, должно быть, потерял свой cookie и способность отвечать и редактировать...

Я исследовал средство балансировки нагрузки как проблему немного, изменив свой файл хостов, чтобы указать непосредственно на IP-адреса каждого из веб-серверов, и это не имело никакого эффекта. Я думаю, ИТ-персонал клиента собирается отказаться от просьбы отключить балансировку нагрузки.

У нас работает отдельный сервер состояний, и он тот же, что использовался в течение нескольких лет на других сайтах, размещенных на тех же серверах. Не обязательно без проблем, но без таких проблем.

Как пластырь, я сейчас тестирую другие механизмы стойкости...