Java 'tnameserv' готовится более чем за 3 минуты, почему?

Я пытаюсь помочь разработчику приложения, которое я хотел бы использовать для устранения неполадок с использованием Corba Server в Linux. Я сузил проблему до tnameserv, после вызова которой требуется более 3 минут, чтобы подготовиться.

Что именно tnameserv пытается сделать за эти 3 минуты, и можно ли как-то ускорить это? Приложение не удалось, потому что оно пыталось выполнить 5 попыток подключения с интервалом в 1 секунду между попытками; что, по-видимому, не дает tnameserv достаточно времени, чтобы подготовиться. Я использую Java 6u17 в Slackware 13.0.

В случае, если это имеет значение. Фактический вызов tnameserv выглядит следующим образом:

tnameserv -ORBInitialPort 23423

После запуска этой команды в оболочке она зависает примерно до 3-минутной отметки, когда я наконец вижу, что она отображает Готово.

ОБНОВИТЬ

Я сделал strace -f tnameserv -ORBInitialPort 23423 и вижу кучу вызовов gettimeofday(), clock_gettime() и futex(), из которых последний всегда возвращает '-1 ETIMEDOUT (время ожидания соединения истекло). У меня есть ощущение, что это связано с моей проблемой, но я понятия не имею, как и почему.

Вот лишь малая часть того, что я вижу от strace. Может ли кто-нибудь воспроизвести и/или понять это?

[pid 30950] futex(0x8128e14, FUTEX_WAIT_PRIVATE, 1, {0, 49903084}) = -1 ETIMEDOUT (Connection timed out)
[pid 30950] futex(0x8098a28, FUTEX_WAKE_PRIVATE, 1) = 0
[pid 30950] clock_gettime(CLOCK_MONOTONIC, {329619, 995857482}) = 0
[pid 30950] gettimeofday({1260930158, 92108}, NULL) = 0
[pid 30950] clock_gettime(CLOCK_MONOTONIC, {329619, 995996617}) = 0
[pid 30950] clock_gettime(CLOCK_MONOTONIC, {329619, 996088536}) = 0
[pid 30950] gettimeofday({1260930158, 92328}, NULL) = 0
[pid 30950] clock_gettime(CLOCK_REALTIME, {1260930158, 92424295}) = 0
[pid 30950] futex(0x8128e14, FUTEX_WAIT_PRIVATE, 1, {0, 49903705}) = -1 ETIMEDOUT (Connection timed out)
[pid 30950] futex(0x8098a28, FUTEX_WAKE_PRIVATE, 1) = 0
[pid 30950] clock_gettime(CLOCK_MONOTONIC, {329620, 46761098}) = 0
[pid 30950] gettimeofday({1260930158, 143084}, NULL) = 0
[pid 30950] clock_gettime(CLOCK_MONOTONIC, {329620, 46913924}) = 0
[pid 30950] clock_gettime(CLOCK_MONOTONIC, {329620, 47006961}) = 0
[pid 30950] gettimeofday({1260930158, 143303}, NULL) = 0
[pid 30950] clock_gettime(CLOCK_REALTIME, {1260930158, 143398317}) = 0
[pid 30950] futex(0x8128e14, FUTEX_WAIT_PRIVATE, 1, {0, 49904683}) = -1 ETIMEDOUT (Connection timed out)
[pid 30950] futex(0x8098a28, FUTEX_WAKE_PRIVATE, 1) = 0
[pid 30950] clock_gettime(CLOCK_MONOTONIC, {329620, 97818379}) = 0
[pid 30950] gettimeofday({1260930158, 194127}, NULL) = 0
[pid 30950] clock_gettime(CLOCK_MONOTONIC, {329620, 97957235}) = 0
[pid 30950] clock_gettime(CLOCK_MONOTONIC, {329620, 98049154}) = 0
[pid 30950] gettimeofday({1260930158, 194346}, NULL) = 0
[pid 30950] clock_gettime(CLOCK_REALTIME, {1260930158, 194441349}) = 0
[pid 30950] futex(0x8128e14, FUTEX_WAIT_PRIVATE, 1, {0, 49904651}) = -1 ETIMEDOUT (Connection timed out)
[pid 30950] futex(0x8098a28, FUTEX_WAKE_PRIVATE, 1) = 0
[pid 30950] clock_gettime(CLOCK_MONOTONIC, {329620, 148806370}) = 0
[pid 30950] gettimeofday({1260930158, 245055}, NULL) = 0
[pid 30950] clock_gettime(CLOCK_MONOTONIC, {329620, 148947182}) = 0
[pid 30950] clock_gettime(CLOCK_MONOTONIC, {329620, 148981547}) = 0
[pid 30950] gettimeofday({1260930158, 245280}, NULL) = 0
[pid 30950] clock_gettime(CLOCK_REALTIME, {1260930158, 245374859}) = 0
[pid 30950] futex(0x8128e14, FUTEX_WAIT_PRIVATE, 1, {0, 49905141}) = -1 ETIMEDOUT (Connection timed out)

person SiegeX    schedule 16.12.2009    source источник


Ответы (3)


Я нашел это с помощью Google (кстати, сегодня день рождения Л.Л. Заменгофа). Я бы включил трассировку wireshark и посмотрел, сможете ли вы что-нибудь там увидеть. Хотя я бы ожидал увидеть что-то в страйсе, если бы была сетевая активность. Жаль, что это не с открытым исходным кодом.

person Francis Upton IV    schedule 16.12.2009

Выяснилось, что проблема была в брандмауэре. Wireshark не показал ничего полезного, потому что брандмауэр отбрасывал определенный пакет. Хотя я несколько раз просматривал журналы своего брандмауэра, чтобы убедиться, что это не так, оказалось, что я искал не в том месте. Я упустил из виду тот факт, что этот tnameserv был осведомлен о IPv6 (поскольку он был привязан к :::23423), и беглый взгляд на сценарий моего брандмауэра показал, что я записываю пакеты, связанные с IPv6, в другое место, чем мои пакеты IPv4. Это не было упущением, но должно было быть сделано, потому что ip6tables в настоящее время не поддерживает цель -j ULOG.

Короче говоря, петля для IPv6 устранила проблему, и «tnameserv» почти мгновенно возвращает «Готово».

person SiegeX    schedule 16.12.2009
comment
можете ли вы подробно рассказать о том, что вы сделали? У меня точно такая же проблема, кажется. - person Benny; 11.12.2010
comment
Здесь запрошено разъяснение stackoverflow.com/questions/4418446/ - person Benny; 11.12.2010

Проверьте свои DNS-настройки. Вы можете тайм-аут ожидания ответа несколько раз.

person Thorbjørn Ravn Andersen    schedule 16.12.2009