O 'tnameserv' do Java leva mais de 3 minutos para ser "Pronto", por quê?

Question

Estou tentando ajudar um desenvolvedor de um aplicativo que gostaria de usar para solucionar um problema utilizando o Corba Server no Linux. Limitei o problema para tnameserv demorando mais de 3 minutos para ficar pronto após a invocação.

O que exatamente o tnameserv está tentando fazer nesses 3 minutos e existe alguma maneira que eu possa acelerar? O aplicativo falhou porque tentou fazer 5 tentativas de conexão com 1 segundo entre novas tentativas; que aparentemente não dá tempo suficiente para ficar pronto. Eu estou usando o Java 6u17 no Slackware 13.0

Caso isso seja importante. A invocação real de tnameserv é a seguinte:

tnameserv -ORBInitialPort 23423

Ao executar esse comando em um shell, ele parece travar até a marca de 3 minutos quando eu finalmente o vejo exibir "Pronto".

UPDATE

Eu fiz um strace -f tnameserv -ORBInitialPort 23423 e estou vendo um grande número de chamadas para gettimeofday (), clock_gettime () e futex () das quais o último está sempre retornando '-1 ETIMEDOUT (Connection timed out). Tenho a sensação de que isso está relacionado ao meu problema, mas não tenho ideia de como ou por quê.

Aqui está uma pequena fração do que estou vendo da strace. Alguém pode replicar e / ou entender isso?

[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)

    

Answer 1

Acontece que o problema era um problema de firewall. O Wireshark não mostrou nada de útil porque o firewall estava descartando um determinado pacote. Embora eu tenha olhado meus logs de firewall algumas vezes para ter certeza de que este não era o caso, acontece que eu não estava procurando no lugar certo. Eu esqueci o fato de que este 'tnameserv' era IPv6 ciente (como era obrigatório para ::: 23423) e um olhar superficial do meu script de firewall mostrou que eu estava registrando pacotes relacionados ao IPv6 para um local diferente dos meus pacotes IPv4. Isso não foi um descuido, mas teve que ser feito porque o ip6tables não suporta atualmente o alvo -j ULOG.

Longa história curta, permitindo que o loopback para o IPv6 corrigisse o problema e o 'tnameserv' retornasse "Pronto" quase instantaneamente.

    

Answer 2

Não consigo corrigir seu problema diretamente, mas a experiência me diz que, com frequência, atrasos inexplicáveis de três a cinco minutos são o resultado da espera por tempos limite de DNS.

Sua configuração exige alguma coisa pelo nome do host?