Hi All,
I have found the root of the problem. It appaears to be the use of
/dev/random even though I have used the
-Djava.security.egd=file:/dev/urandom command. Therefore a workaround is
to make /dev/random point to /dev/urandom which is non-blocking, but
also less secure e.g
mv /dev/random /dev/origrandom
ln -s /dev/urandom /dev/random
For the exact differences between the two (/dev/random and /dev/urandom)
and what this means for your system in general please do your own research.
I hope this workaround helps anybody experiencing similar problems.
Kind Regards,
Spyridon V. Gogouvitis
On 12/1/2010 5:37 μμ, Spyridon V. Gogouvitis wrote:
> Dear All,
>
> I'm having the following problem with Globus Toolkit:
>
> While running the examples from the GT4 Tutorial by Borja Sotomayor
> there seem to be random delays in the client that calls the Math Service.
>
> strace gives the following (at some point)
>
> .....
> 6339 17:10:53.677566 open("/tmp",
> O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 176
> 6339 17:10:53.677623 fstat64(176, {st_mode=S_IFDIR|S_ISVTX|0777,
> st_size=4096, ...}) = 0
> 6339 17:10:53.677694 getdents64(176, /* 15 entries */, 4096) = 552
> 6339 17:10:53.677949 getdents64(176, /* 0 entries */, 4096) = 0
> 6339 17:10:53.678012 close(176) = 0
> 6339 17:10:53.678294 read(175,
> "\v\303\276\5\372\33\374N\210D|\31\350\330\372\253"..., 8192) = 16
> 6339 17:10:53.678382 fstat64(175, {st_mode=S_IFCHR|0666,
> st_rdev=makedev(1, 8), ...}) = 0
> 6339 17:10:53.678446 ioctl(175, FIONREAD, [149494784]) = -1 EINVAL
> (Invalid argument)
> 6339 17:10:53.678511 _llseek(175, 0, [0], SEEK_CUR) = 0
> 6339 17:10:53.678560 _llseek(175, 0, [0], SEEK_END) = 0
> 6339 17:10:53.678619 _llseek(175, 0, [0], SEEK_SET) = 0
> 6339 17:10:53.678701 read(175, <unfinished ...>
> 6346 17:10:53.689764 <... futex resumed> ) = -1 ETIMEDOUT (Connection
> timed out)
> 6346 17:10:53.689801 futex(0x8eddb28, FUTEX_WAKE_PRIVATE, 1) = 0
> 6346 17:10:53.689856 clock_gettime(CLOCK_MONOTONIC, {10072, 935287704}) = 0
> 6346 17:10:53.689908 gettimeofday({1263309053, 689926}, NULL) = 0
> 6346 17:10:53.689956 clock_gettime(CLOCK_MONOTONIC, {10072, 935387402}) = 0
> 6346 17:10:53.690004 clock_gettime(CLOCK_MONOTONIC, {10072, 935434621}) = 0
> 6346 17:10:53.690051 gettimeofday({1263309053, 690069}, NULL) = 0
> 6346 17:10:53.690099 clock_gettime(CLOCK_REALTIME, {1263309053,
> 690118560}) = 0
> 6346 17:10:53.690148 futex(0x96ee834, FUTEX_WAIT_PRIVATE, 1, {0,
> 49950440}) = -1 ETIMEDOUT (Connection timed out)
> 6346 17:10:53.740161 futex(0x8eddb28, FUTEX_WAKE_PRIVATE, 1) = 0
> 6346 17:10:53.740212 clock_gettime(CLOCK_MONOTONIC, {10072, 985650326}) = 0
> 6346 17:10:53.740268 gettimeofday({1263309053, 740286}, NULL) = 0
> 6346 17:10:53.740316 clock_gettime(CLOCK_MONOTONIC, {10072, 985746802}) = 0
> 6346 17:10:53.740363 clock_gettime(CLOCK_MONOTONIC, {10072, 985794056}) = 0
> 6346 17:10:53.740411 gettimeofday({1263309053, 740429}, NULL) = 0
> 6346 17:10:53.740459 clock_gettime(CLOCK_REALTIME, {1263309053,
> 740477706}) = 0
> 6346 17:10:53.740507 futex(0x96ee834, FUTEX_WAIT_PRIVATE, 1, {0,
> 49951294}) = -1 ETIMEDOUT (Connection timed out)
> 6346 17:10:53.790529 futex(0x8eddb28, FUTEX_WAKE_PRIVATE, 1) = 0
> 6346 17:10:53.790582 clock_gettime(CLOCK_MONOTONIC, {10073, 36028876}) = 0
> 6346 17:10:53.790649 gettimeofday({1263309053, 790669}, NULL) = 0
> 6346 17:10:53.790700 clock_gettime(CLOCK_MONOTONIC, {10073, 36132492}) = 0
> 6346 17:10:53.790750 clock_gettime(CLOCK_MONOTONIC, {10073, 36182258}) = 0
> 6346 17:10:53.790800 gettimeofday({1263309053, 790819}, NULL) = 0
> 6346 17:10:53.790851 clock_gettime(CLOCK_REALTIME, {1263309053,
> 790871031}) = 0
> 6346 17:10:53.790902 futex(0x96ee834, FUTEX_WAIT_PRIVATE, 1, {0,
> 49947969}) = -1 ETIMEDOUT (Connection timed out)
> 6346 17:10:53.840925 futex(0x8eddb28, FUTEX_WAKE_PRIVATE, 1) = 0
> 6346 17:10:53.840985 clock_gettime(CLOCK_MONOTONIC, {10073, 86416466}) = 0
> 6346 17:10:53.841034 gettimeofday({1263309053, 841053}, NULL) = 0
> 6346 17:10:53.841083 clock_gettime(CLOCK_MONOTONIC, {10073, 86513727}) = 0
> 6346 17:10:53.841129 clock_gettime(CLOCK_MONOTONIC, {10073, 86560401}) = 0
> 6346 17:10:53.841176 gettimeofday({1263309053, 841194}, NULL) = 0
> 6346 17:10:53.841224 clock_gettime(CLOCK_REALTIME, {1263309053,
> 841243111}) = 0
> ....
>
>
> and so on until at some point is seems to "unpause" at which time
> execution continues correctly and the client finishes.
>
> I have concluded that this happens when the client tries to call
> math.add(10) for the first time but does not happen in the following
> calls to add.
>
> This does not happen every time the client is executed. Sometimes it is
> fast, but most of the time it is slow (sometimes it takes up to 2
> minutes for the client to finish).
>
> This happens with another service/client that I have developed in
> exactly the same way (the client hangs the first time it tries to call a
> method of the stub class).
>
> The client and the server are running on the same machine and I have
> also tried it with separate machines but nothing changes.
>
> It has been tested both on Fedora Core 9 and Debian 5 and both sun java
> 1.5 and 1.6.
>
> Has anyone else encountered such delays?
>
> Any help would be much appreciated!
>
> Best Regards,
> Spyridon V. Gogouvitis
