Закрыть апплет

Давно бьюсь с проблемой.
У нас клиент - апплет. Когда юзер закрывает браузер, то апплет должен послать сообщение на сервер о своей смерти. Но не всегда успевает. Конечно, на сервере есть процесс, который отслеживает всех клиентов, и если клиент некоторое время не подает признаков жизни, то такого клиента сервер считает отсоединившимся.
Но хотелось бы, чтобы апплет всегда успевал явно сообщить о своем закрытии.
Понятно, что для этого предусмотрены методы stop и destroy. Но тут еще, как я понял, влияет в каком окне бегает апплет. Если кроме окна с апплетом открыты другие окна браузера, то есть шанс, что дестрой сработает, потому что виртуальная машина не рушится. Если апплет открыт в единственном окне, то при его закрытии умирает и виртуальная машина и ей не до апплета (ставил в дестрой wait, которое снимается после посылки сообщения на сервер, но и это не помогает).
Вот такая у меня гипотеза. Или все-таки это ошибки программирования?

0

http://java.sun.com/docs/books/tutorial/applet/overview/lifeCycle.html
Здесь пишут об известных проблемах при загрузке апплетов. Про выгрузку ничего не сказано. Я сам, работая с апплетами, тоже не наблюдал такой проблемы. Правда отправлять мне ничего никуда не приходилось. Более конкретно ничего сказать не могу, к сожалению.

0

Попробуйте поэкспериментировать с методами stop() И destroy()(если не ошибаюсь)

автор прости великодушно не прочитал толком твой пост

По идее дестрой должен срабатывать в любом случае если ты его перепишещ

О! Идея возникла при самоуничтожении аппдета первым вызывается stop() и только потом destroy() а что если сообщать серверу в stop а не в destroy?

Я это как раз и пробовал. Посылаю комаду о закрытии из стопа() (и из дестроя пробовал) и ставлю ожидание wait. После того, как команда отправлена, делаю notify. Если кроме окна, где открыт апплет, открыты другие окна, то в java консоли я вижу, как выполнение функции стоп останавливается и после посылки команды возобновляется благодаря notify. Все работает, как в учебниках . Но если было открыто только одно окно браузера, то с его закрытием и консоль закрывается, и посмотреть ничего нельзя (на сервер команда не приходит). Из чего я сделал предположение, что JVM умирает и хоронит все под собой. Возможно, это зависит еще и от версии браузера и виндоуз.
Есть еще идея (пока только идея) перенять технологию порносайтов (когда закрываешь одно окно, то выскакивает другое), т.е. чтобы при закрытии не апплет послал сигнал, а сам браузер сообщил на сервер о кончине.

0

У меня встречный вопрос: зачем? Зачем необходимо знать о том, что браузер закрылся? Ни разу не возникало ситуации, чтобы нельзя было это разрулить. Я не спорю, очень удобно знать, когда юзер закрыл сессию. Но это обходится ) Мне на самом деле интересно.

0

Согласен, это наверняка обходится.
У нас на сервере есть процесс который отключает юзеров не подающих признаков жизни некоторое время. Сервер не позволяет юзеру одновременно два апплета под одним именем открывать. Если юзер минимизировал окно апплета и потерял его, потом по новой коннектится, ему будет отказано. Или он случайно закрыл (но закрыл неудачно) и тут же опять в систему лезет, а сервер его не пускает, так как старая сессия еще живая. Пройдет некоторое время, когда сервер его опять пустит, и клиенту это надо обьяснять, а лучше такие ситуации исключить.
Наверное, тут можно и сценарий взаимодействия сервера с клиентом как-то оптимизировать и тут наверняка есть обкатанные решения. Буду благодарен за информацию.

0

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

0

А ты не пробовал просмотреть всё то же самое но не из под консоли браузера а из под ДОСа например? то есть из под appletviewer?
По идее любая программа выполняется построчно то есть выполнилась строка идем дальше попробуй просмотреть из под вьюера или в крайняк пиши пока в какой нить текстовый файл чисто для отладки...

Вопрос в следующем: раз нужно узнавать о смерти апплета, значит, тот апплет висит у пользователя достаточно долго. Раз висит долго, значит, вероятно, обменивается данными с сервером. Раз обменивается данными, значит, наверное, открывает какую-то коннекцию. Если она делается через socket, то почему бы не отслеживать 'живость' апплата по этой коннекции? Или там у вас HTTP-тунеллирование?

0

На самом деле проблема важная. Даже в случае обычного сетевого подключения к базе данных (например Oracle) иногда сеансы могут висеть очень долго пожирая ресурсы.
Если вырубать клиента по таймауту, то можно случайно отключить клиента, который как буриданов осел долго не может принять решение и морщит лобик сидя за компьютером в бездействии. При работе в HTTP когда связь практически односторонняя это и вовсе - проблема : как отследить - жив клиент или уже мертв. Если это Интернет, ну и черт с ним. Если это Интранет может привести к коллизии потери важной информации.

0

3 mselez:
> [...] Сервер не позволяет юзеру одновременно два апплета под одним именем открывать.
Понятно, что сервер не сам собой позволяет только с одним экземпляром апплета юзеру работать, а разработчики хотят сделать так, чтобы приложение (под приложением я понимаю совокупность всех его компонент: и апплеты, и сервлеты, и логика, и БД) не позволяло открывать одному пользователю два экземпляра с пересекающимися временами жизни. Вопрос: почему? Почему вы хотите запретить открывать два апплета? Я уверяю, что ответ на этот вопрос может многое прояснить, и ОЧЕНЬ вероятно, что можно будет выбрать альтернативное решение, которое БУДЕТ УДОВЛЕТВОРЯТЬ решаемой задаче.

2 mbasil:
> [...] Даже в случае обычного сетевого подключения к базе данных (например Oracle) иногда сеансы могут висеть очень долго пожирая ресурсы.
Согласен, что держать соединение с БД, и не производить никаких операций с ней -- очень дорого. И не надо так делать. Выполнил запрос -- закрыл соединение. Да, открывать и закрывать соединения дорого. Пулируем. Известно, что примерно только 10% пользователей из всех, в данный момент работающих с приложением, в данный же момент выполняют запросы к БД. Если одновременно подключено к приложению 100 юзеров, то только десятерым из них необходмо соединение. Значит мщности пула в 10 соединений достаточно. Причем интелектуальный пул, который сам адаптируется к нагрузке -- задача простая и решенная во множестве вариантов. И этим надо пользоваться )

0

To Danissimo
Напрасно Вы объясняте, как работает пул подключений, поскольку я не настолько безграмотен. Пуд подключений к поднятому вопросу никакого отношения не имеет. Я хотел ЛИШЬ подчеркнуть, что вопрос поднятый в топике был проблемой 'И' в режиме клент-сервер, а сейчас при использовании сложных форм в Интранет - это просто АРХИактуально и решение заинтересуют всех (меня в том числе).

0

Согласен, что к поднятому вопросу пол соединений отношения не имеет. Я отвечал не на поднятый вопрос, а на пост от '27.11.2003 10:33'. Может быть я не понял, о чем речь -- обясняться по этому поводу больше нет смысла. Проехали...

Но. Вы все пытаетесь решить задачу, как заставить апплет сообщать о том, что он выгружен. Я же пытаюсь выяснить у вопрошающего, зачем ему надо, чтобы апплет так поступал. А веб-приложение и клиент-сервер -- разные оперы. И если кто-то в веб-приложении использует архитектуру клиент-серверного приложения, тогда-то и возникают проблемы с открытыми соединениями (если говорить про соединения ).

Я не отрицаю, что, да, действительно для решения исходной задачи нужно решить задачу с единтсвенностью апплета. Но для этого я хочу услышать эту исходную задачу.

0

Извините, несмотря на то, что 'проехали' попытаюсь нахально влезть еще раз, поскольку не все так просто.
У нас все чаще возникают противоположные требования к клиенту : он должен для работы иметь сложный 'АРМ' и 'долгоиграющий' сеанс и при этом должен еще работать через HTTP и в браузере. Ему нельзя ничего инсталировать, но при этом он должен иметь инструмент высокой сложности. Форма сложная, значит - аплет.
'Долгоигрпющий' сеанс, воленс-ноленс, организуем на сервере приложений, в ответ на короткие HTTP запросы получаем на короткое время подключение из пула. Этот самый сеанс на сервере приложений кэширует часть иформации между базой и собственно клиентом. Что делать с сеансом если клиент долго не проявляется. Вырубить с потерей информации? А обратной связи 'сервер приложений -> клиент' практически нет. Отсюда и проблема.

0

Извините, напомню, что клиент внутренний и информация важная. Внешнего клиента можно зачастую заставить повторно проделать операцию а здесь информацию терять просто нельзя, но и 'транзакция' по-видимому не завершена.

0

Все правильно. Давайте скажем все то же самое, но другими словами.

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

Я правильно понял и перефразировал задачу?

Решение.
Так как нельзя понять, оборвался канал связи или нет, то вводим время ожидания реакции от актера. Как только время истекло, делаем вывод, что канал оборвался. Это с одной стороны.

С другой стороны. Данные в хранилище переходят из одного устойчивого состояния в другое по вполне определенным на этапе проектирования системы событиям. Переход будем считать мгновенным и атомарным. Такой переход будем называть транзакцией.

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

Если приняты все данные, достаточные для выполнения транзакции, выполняем ее. Что делать, если приняты не все данные, и канал связи оборвался? Помним, что актер не может воспроизвести ранее переданные данные.

Можно их сохранить во временном хранилище. После того, как канал связи восстанавливается, и пирложение проидентифицировало пользователя, оно восстанавливает ранее принятые данные и готово продолжать их принимать. Так моно повторять бесконечно много раз. Как только наступает ситуация, влекущая за собой возбуждения события, переводящего хранилище из одного состояния в другое, возбуждаем его.

Как приложению адекватно зваимодействовать с пользователем. Он должен иметь возможность просмотреть ранее введенные, но еще не внесенные в хранилище, данные. Если при аутентификации выясняется, что ранее переданные данные не достаточны для выполнения транзакции, сообщить ему об этом, и показать их. Как только его транзакция выполнена, сообщить ему об этом. Сообщить также о том, что данные недостаточные для выполнения транзакции, хранятся не вечночть, а четко заданное РАЗУМНОЕ время.

Все. Только так и работают приложения со stateless протоколами )

0

И еще. Меня удивило утверждение: 'Форма сложная, значит - аплет.' Да кто сказал? С какой стати? Утверждение 'Форма сложная' совсем не влечет за собой вывод 'значит -- апплет'. Апплет -- всего лишь как один из вариантов. Второй -- обычные веб-формы. Ни чем не хуже. Или есть задачи, о которых ничего не сказано, но которые можно решить только апплетом? Даже графики процесса рисовать можно, не используя апплет, если допустимо их обновлять, скажем, раз в секунду.

Короче, из того, что форма сложная, совсем не следует, что апплет -- единственное решение. Для такого решения должны быть более веские аргументы.

0