Java的"tnameserv"需要3分钟以上的时间才能“就绪"，为什么呢? [英] Java's 'tnameserv' takes 3+ minutes to be "Ready", why?

问题描述

我正在尝试帮助我想使用某个应用程序的开发人员解决在Linux上使用Corba Server的问题.我将问题缩小为tnameserv，调用后花了3分钟以上的时间准备就绪.

I'm trying to help a dev of an app I'd like to use trouble shoot a problem utilizing Corba Server on Linux. I narrowed down the problem to tnameserv taking over 3 minutes to become ready after invocation.

tnameserv在这3分钟内到底想做什么?无论如何，我可以加快速度吗?该应用失败，因为它尝试进行5次连接尝试，两次重试之间间隔1秒；显然，这不能给tnameserv足够的时间准备就绪.我在Slackware 13.0上使用Java 6u17

What exactly is tnameserv trying to do in those 3 minutes and is there anyway I can speed it up? The app failed because it tried to do 5 connection attempts with 1-second between retries; which apparently doesn't give tnameserv nearly enough time to become ready. I am using Java 6u17 on Slackware 13.0

以防万一. tnameserv的实际调用如下:

In case it matters. The actual invocation of tnameserv is the following:

tnameserv -ORBInitialPort 23423

在外壳中运行该命令后，它似乎一直挂着直到3分钟左右，直到我最终看到它显示为就绪".

Upon running that command in a shell, it appears to hang until around the 3minute mark when I finally see it display "Ready".

我做了一个strace -f tnameserv -ORBInitialPort 23423，我看到了对gettimeofday()，clock_gettime()和futex()的大量调用，后者总是返回'-1 ETIMEDOUT(连接超时).我感觉这与我的问题有关，但我不知道如何或为什么.

I did an strace -f tnameserv -ORBInitialPort 23423 and I am seeing an eff ton of calls to gettimeofday(), clock_gettime() and futex() of which the latter is always returning '-1 ETIMEDOUT (Connection timed out). I have a feeling this is related to my problem, but I have no idea how or why.

这只是我从strace中看到的一小部分.有人可以复制和/或理解吗?

Here is a but a small fraction of what I am seeing from strace. Can somebody replicate and/or make sense of this?

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

推荐答案

原来的问题是防火墙问题. Wireshark没有显示任何有用的信息，因为防火墙正在丢弃某个数据包.尽管我多次查看防火墙日志以确保情况并非如此，但事实证明，我并没有找到正确的位置.我忽略了这个'tnameserv'知道IPv6的事实(因为它绑定到::: 23423)，而我的防火墙脚本的粗略浏览显示我正在将与IPv6相关的数据包记录到与IPv4数据包不同的位置.这不是疏忽，而是必须这样做，因为ip6tables当前不支持-j ULOG目标.

Turns out the problem was a firewall issue. Wireshark didn't show anything useful because the firewall was dropping a certain packet. Although I looked at my firewall logs quite a few times to make sure this wasn't the case, turns out I wasn't looking in the right place. I overlooked the fact that this 'tnameserv' was IPv6 aware (as it was binding to :::23423) and a cursory glance of my firewall script showed that I was logging IPv6 related packets to a different location than my IPv4 packets. This was not an oversight but had to be done because ip6tables does not currently support the -j ULOG target.

长话短说，允许IPv6环回解决了该问题，"tnameserv"几乎立即返回就绪".

Long story short, allowing loopback for IPv6 fixed the issue and 'tnameserv' returns "Ready" almost instantly.

这篇关于Java的"tnameserv"需要3分钟以上的时间才能“就绪"，为什么呢?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！