Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Базы";
Текущий архив: 2004.02.25;
Скачать: [xml.tar.bz2];

Вниз

как отслеживать мёртвые коннекты?   Найти похожие ветки 

 
Dedushka_Mazai   (2004-01-30 13:59) [0]

есть сервер приложений и клиенты. если клиент по какой-либо причине некорректно завершается (например, нажатием <Reset>), на сервере остаётся мёртвый коннект. как можно эти коннекты вычислять и убивать со стороны сервера?


 
Michail Dalakov   (2004-01-30 15:46) [1]

Delphi не позволяет чисто убивать мёртвый коннект со стороны сервера. Частично остается мусор после RDM.free.


 
Michail Dalakov   (2004-01-30 15:56) [2]

TComClassManager модуль ComObj


 
Dedushka_Mazai   (2004-01-30 16:48) [3]

>Delphi не позволяет чисто убивать мёртвый коннект со стороны сервера. Частично остается мусор после RDM.free.
в смысле? если можно, поподробнее, что там за мусор остаётся?

Вопрос, кстати, был в другом: как, собственно, отследить момент, когда коннект помирает и сделать RDM.Free?


 
Michail Dalakov   (2004-01-30 17:41) [4]

Вариант, например, такой.
Клиент конектится. Если модель сервера ciMultiInstance, tmApartment (или ciInternal, tmApartment) то при конекте - в отдельном потоке создается RDM который обслуживент данное соединение. На сервере работает таймер который должен уничтожить соединение если клиент бесследно исчез. Клиент же с какой-то периодичностью должен посылает на сервер сообщение что он еще жив (ну может также посылать и параметр, который будет сообщать серверу сколько он хочет жить).
Мусор остается из за того что после Free TComClassManager никак не узнает об этом, остается поток в котором RDM создавался


 
Dedushka_Mazai   (2004-01-30 17:54) [5]

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

а есть какое-либо оптимальное значение таймаута, по которому клиента можно отстреливать? (оно понятно, что всё это будет тестироваться на практике, но тем не менее, интересно узнать мнение человека, который уже с этим сталкивался).

>Мусор остается из за того что после Free TComClassManager никак
>не узнает об этом, остается поток в котором RDM создавался
но сама дельфа-то корректно освобождает память и убивает потоки?
стало быть должна быть альтернатива RDM.Free.
(чует моё сердце, придётся в исходниках поковыряться)


 
Michail Dalakov   (2004-01-30 18:28) [6]

Microsoft в .NET по Default = 10 минут
я устанавливал и поменьше, сервер ждал в 2 раза больше чем просил клиент после чего если клиент не отзывался, то происходило отключение. Рекомендую оставить 10 минут иначе трудно будет работать в Design и Debag из-за отключения сервером

>но сама дельфа-то корректно освобождает память и убивает потоки?
>стало быть должна быть альтернатива RDM.Free.

Да, но она делает это через TComClassManager, и если мне не изменяет память то через приватные методы.


 
Dedushka_Mazai   (2004-01-30 18:39) [7]

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


 
Michail Dalakov   (2004-01-30 18:53) [8]

Не совсем понял, что за буфер? Где он находится, и как используется.
Каждый клиент обслуживается своей инстанцией COM-объекта, созданной в отдельном потоке, и никакого влияния на другие клиенты не оказывает.
Вообще акт отключения клиента сервером связан с освобождением ресурсов последнего и не больше


 
Dedushka_Mazai   (2004-01-30 19:11) [9]

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


 
Michail Dalakov   (2004-01-30 19:40) [10]

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



Страницы: 1 вся ветка

Форум: "Базы";
Текущий архив: 2004.02.25;
Скачать: [xml.tar.bz2];

Наверх




Память: 0.47 MB
Время: 0.033 c
8-80039
WondeRu
2003-10-20 09:04
2004.02.25
DirectShow Filters


1-79866
staryx
2004-02-06 11:59
2004.02.25
Меню а-ля


3-79623
Jioniro
2004-01-25 15:48
2004.02.25
DbiUseIdleTime во время


3-79667
Dedushka_Mazai
2004-01-30 13:59
2004.02.25
как отслеживать мёртвые коннекты?


1-79822
Hooch
2004-02-11 07:52
2004.02.25
VirtualStringTree 4.0.17, проблема с отображением текста





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский