Кажется у меня возникла серъезная проблемма .
win32. XP SP1.
Имеется - задачка, многопоточная, осуществляющая коннкты к FTP серверам посредством FTP клиента из
commons-net-1.2.2. (слегка переделанного мною, но не в части коннектов).
Коннект к серверу в потоке осуществляется как:

Код

lftp=new FTPClient();      lftp=lftp;      PIPFTPSGetList.Gconf.llog.LogLogThr(getName(),"Start DoConnect, url:"+ftps.URL,4);      lftp.connect(ftps.URL);      PIPFTPSGetList.Gconf.llog.LogLogThr(getName(),"Connected OK before login, url:"+ftps.URL,4);

как явствует из кода и из доков - lftp.connect(ftps.URL) вызывает на прямую метод SocketClient.connect().
Так вот в этом месте (именно - lftp.connect(ftps.URL); ) задача после нескольких сотен переконнектов в произвольный момент времени встает.
Т.е. тхреад замирает на этом самом коннекте и соотв. остается на всегда ...
ни эксепшена, ни вообще выхода из метода нет. Тхреад повисает.
Что-то не так ...
Проверять довольно сложно, т.к. это происходит примерно раз в сутки с 1-2 тхреадами из нескольких сотен успешно стартованных и завершенных ...
Что можно предпринять, а?
Спасибо!

Установи setSoTimeout и лови SocketTimeoutException Хотя кто его знает.

Цитата(Domestic @ 11.1.2005, 16:14)

Установи setSoTimeout и лови SocketTimeoutException Хотя кто его знает.

setSoTimeout

Set the timeout in milliseconds of a _currently open connection_. Only call this method after a connection has been opened by connect()

Эксепшены ловлю естественно все вообще - по catch(Exception e) ...

попробую вот еще что:
void setDefaultTimeout(int timeout)
Set the default timeout in milliseconds to use when opening a socket.
вроде пишут - when opening a socket ...



вообщем бяка такая, что прям и не знаю - еще один поток завидить что-ли что-б смотрел за коннектящися что-ли?

хм. поймал себя на мысли - а я и не знаю как такой застрявший поток убить из другого потока-то!

Это сообщение отредактировал(а) Sleepy_PIP - 11.1.2005, 16:32

Цитата(Sleepy_PIP @ 11.1.2005, 07:24)

хм. поймал себя на мысли - а я и не знаю как такой застрявший поток убить из другого потока-то!

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

Цитата(Domestic @ 11.1.2005, 20:06)

Цитата(Sleepy_PIP @ 11.1.2005, 07:24) хм. поймал себя на мысли - а я и не знаю как такой застрявший поток убить из другого потока-то! Даже если знать ссылку на зависший поток, просто так не убьешь - стоп и дестрой упразднены. В принципе, зная ссылку, можно либо вызвать метод, который красиво закончит тред (например, закроет сокет, который заблокировал тред). Чтоб ссылку узнать - тут не знаю, можно например мониторинг делать какой тред сколько времени занят.

уууу. блин. инет дома - просто никакой!
Значится так. Проблемма локализована именно на SoketClient.connect(...)
С потоками и ООП не первый день возимся, даже когда их не было - т.е. все ссылки на все нужные потоки имеются. более того - совсем не трудно добавить проверку по активности по времени.
НО! - поток завис в своем методе! этот метод завязан на ОС.
Вопрос - другие методы потока разве будут работать?
Спасибо!

Само собой, сам поток делать ничего не сможет, а вот его методы вызывать можно - из другого потока. Так что если у потока есть поле clientSocket, то можно добавить метод

Код

public void close() {       try{      clientSocket.close(); } catch (Exception e) {//....      } }

Ну а дальше не знаю, вроде бы если пытаться закрыть работающий сокет

Цитата

Any thread currently blocked in an I/O operation upon this socket will throw a SocketException.

но выключит ли это тред - вот в чем вопрос.

А если через Timer?
Установить флажок, запустить однократно Timer, после соединения флажок сбросить. При срабатывании таймера проверить флажок, если все еще установлен - завершить процесс цивильно.

BTW, что делает

Код

lftp=lftp;

?

Цитата(igon @ 11.1.2005, 14:08)

А если через Timer? Установить флажок, запустить однократно Timer, после соединения флажок сбросить. При срабатывании таймера проверить флажок, если все еще установлен - завершить процесс цивильно.

Ну это детали, вроде у Sleepy_PIP мониторинг был готов, правда про время выполнения не заню, было ли.

Кардинально иной вариант - пользовать java.nio, там все асинхронно и можно использовать неблокирующий ИО, каналы можно интерраптить.

Цитата(Domestic @ 11.1.2005, 23:14)

Цитата(igon @ 11.1.2005, 14:08) А если через Timer? Установить флажок, запустить однократно Timer, после соединения флажок сбросить. При срабатывании таймера проверить флажок, если все еще установлен - завершить процесс цивильно. Ну это детали, вроде у Sleepy_PIP мониторинг был готов, правда про время выполнения не заню, было ли. Кардинально иной вариант - пользовать java.nio, там все асинхронно и можно использовать неблокирующий ИО, каналы можно интерраптить.

мониторинг и правда есть.
НО!
проблемма то в том, что зависание наблюдается на ClientSocet.connect(), т.е. сокета еще нет (точнее он создан, но не подключен), и сказать в другом методе disconnect() наверное нельзя - ну это я еще буду пробовать конечно.
Но вообще - в принципе - если поток подвис в run() на каком-то безконечном цикле к примеру типа for(;true;) {} - как такой поток убить со стороны (из другого потока), а?
Если-б такой метод был-бы - я решил-б все проблеммы запросто.

"Кардинально иной вариант - пользовать java.nio, там " - не могу. я уже заложился на common-net, и FTP клиент оттуда ...

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

Спасибо!

Цитата(Sleepy_PIP @ 12.1.2005, 00:06)

что зависание наблюдается на ClientSocet.connect()

Так ты попробовал setDefaultTimeout? Судя по
http://java.sun.com/j2se/1.4.2/docs/guide/...eprecation.html
остановить тред извне нельзя, хотя можно на нем попробовать interrupt(), но для сокетов врядли сработает.

Цитата(Domestic @ 12.1.2005, 09:46)

Цитата(Sleepy_PIP @ 12.1.2005, 00:06) что зависание наблюдается на ClientSocet.connect() Так ты попробовал setDefaultTimeout? Судя по http://java.sun.com/j2se/1.4.2/docs/guide/...eprecation.html остановить тред извне нельзя, хотя можно на нем попробовать interrupt(), но для сокетов врядли сработает.

да, таймаут я попробовал. для нормальной ситуации он действительно работает (т.е. если .connect() не виснет, то подчиняется указанному таймауту). Однако зависание все равно имеет место.
.interrupt() я использую (для других целей) - он всего-лишь устанавливает флаг для потока, который сам поток может проверить как .interrupted() ... но если поток подвис до издания return в run() - тут уже проверяй, не проверяй interrupted() - не поможет. надо именно продолжить run(), или как-то убить весь поток ... в Win32 API это есть конечно, но я не могу это использовать, т.к. задача станет не переносимой ...
нда. что-то у меня никаких идей .
НО! - сама jvm убивает-же свои (и пользовательские) потоки при завершении задачи - значит это где-то есть ...

С другой стороны - так ли обязательно "убивать" зависший?
Просто запустить новый с параметрами зависшего. Если зависает 1-2 в сутки - может, и пусть? Когда-нить они же должны "отвиснуть" или "помереть"!

Цитата(igon @ 12.1.2005, 21:30)

С другой стороны - так ли обязательно "убивать" зависший? Просто запустить новый с параметрами зависшего. Если зависает 1-2 в сутки - может, и пусть? Когда-нить они же должны "отвиснуть" или "помереть"!

в том-то и дело что не отвисают ... а задачка 24х7 ... т.е. по идее - не должна требовать вмешательства вообще. А вот не получается ... тхреады растут, память то-ж ... медленно, но верно .

Уточни пожалуйста, что это за зверь такой - SocketClient? В моем JDK 1.4.2 такой класс отсутствует. Посмотреть бы на его "кишочки" - может, возможно сделать наследника с добавлением timeout в connect()?

Цитата(igon @ 13.1.2005, 18:22)

Уточни пожалуйста, что это за зверь такой - SocketClient? В моем JDK 1.4.2 такой класс отсутствует. Посмотреть бы на его "кишочки" - может, возможно сделать наследника с добавлением timeout в connect()?

это оболочка для работы с сокетами найтивными в common-net ... ничего там особенного нет ... ф. 17 кил - я боюсь его тут публиковать из-за толщины ...