Archived

This forum has been archived. Please start a new discussion on GitHub.

Java VM Crash within Ice.CommunicatorI.destroy and many threads w/ Prioxies.

jae
jae
in Help Center
I've written a simple Java test client that spawns a number of threads. Each thread performs a communicator().stringToProxy() and then a checkedCast() before communicating with a server.

I have not modified the default Ice.ThreadPool.Server value; so it appears that all the requests are serialized by the server which fulfills them one at a time.
I'm running under Gentoo Linux and Java 1.4.2 on both the client and server machines (which may be the same machine or different machines).

If the client code forks a sufficient number of threads (varies between 125 - 300), the JVM containing the client crashes in threading code.
#  SIGSEGV (0xb) at pc=0x5558a55f, pid=10508, tid=1433094336
#
# Java VM: Java HotSpot(TM) Client VM (1.4.2_10-b03 mixed mode)
# Problematic frame:
# C  [libpthread.so.0+0x955f]  pthread_kill+0xf

The stack trace shows that this happens internal to Ice:
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [libpthread.so.0+0x955f]  pthread_kill+0xf
C  [libnio.so+0x4f1b]  Java_sun_nio_ch_NativeThread_signal+0x1b
j  sun.nio.ch.NativeThread.signal(J)V+0
j  sun.nio.ch.SocketChannelImpl.implCloseSelectableChannel()V+39
j  java.nio.channels.spi.AbstractSelectableChannel.implCloseChannel()V+1
j  java.nio.channels.spi.AbstractInterruptibleChannel.close()V+23
j  IceInternal.ThreadPool.joinWithAllThreads()V+75
j  IceInternal.Instance.destroy()V+313
j  Ice.CommunicatorI.destroy()V+4
j  Ice.Application.main(Ljava/lang/String;[Ljava/lang/String;LIce/InitializationData;)I+268
j  Ice.Application.main(Ljava/lang/String;[Ljava/lang/String;Ljava/lang/String;)I+113
j  com.wink.content.GetContentTestClient.main([Ljava/lang/String;)V+14
v  ~StubRoutines::call_stub
V  [libjvm.so+0x1a8aa4]
V  [libjvm.so+0x25e605]
V  [libjvm.so+0x1a8cf6]
V  [libjvm.so+0x1b0f6c]
V  [libjvm.so+0x1bfadd]
C  [java+0x1abe]
C  [libc.so.6+0x158a5]  __libc_start_main+0xe5

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  sun.nio.ch.NativeThread.signal(J)V+0
j  sun.nio.ch.SocketChannelImpl.implCloseSelectableChannel()V+39
j  java.nio.channels.spi.AbstractSelectableChannel.implCloseChannel()V+1
j  java.nio.channels.spi.AbstractInterruptibleChannel.close()V+23
j  IceInternal.ThreadPool.joinWithAllThreads()V+75
j  IceInternal.Instance.destroy()V+313
j  Ice.CommunicatorI.destroy()V+4
j  Ice.Application.main(Ljava/lang/String;[Ljava/lang/String;LIce/InitializationData;)I+268
j  Ice.Application.main(Ljava/lang/String;[Ljava/lang/String;Ljava/lang/String;)I+113
j  com.wink.content.GetContentTestClient.main([Ljava/lang/String;)V+14
v  ~StubRoutines::call_stub

When I modify the client to create one proxy which I reuse in all the threads, then I do not observe the above problem.

Are there any known issues related to Java threading?

What is the best practice for using proxies? Create them as needed, or reuse a single proxy multiple times?

Thanks in advance.

Comments

  • marc
    marc Florida
    The crash happens in the JVM, not in Ice. Otherwise you wouldn't get a SIGSEGV, but a Java exception instead.

    Try to update your JVM. The version you are using is apparently buggy. Try 1.4.2_12, or the latest 1.5.0_09.
  • jae
    jae
    Thanks for the suggestions.

    For the time being, I am not able to migrate to Java 5. Thanks for pointing out that 1.4.2_12 is available (I am at 1.4.2_10); I now plan to update as soon as is convenient and to repeat the test case.

    I appreciate that this is a bug in the JVM; I have so far been unable to locate a relevant bug report on Sun's website. I was wondering if others have encounterd a similar problems using Ice proxies on multiple Java threads.

    Also, what are the best practices are for using multiple proxies connecting to the same server.

    Please note that I have edited the original post. I left out the word "not" in this sentence, sorry for the confusion:
    When I modify the client to create one proxy which I reuse in all the threads, then I do not observe the above problem.
  • marc
    marc Florida
    It doesn't really matter much whether you use the same proxy from multiple threads, or whether you use different proxies for each thread. Performance-wise, the latter might give you a little bit of an advantage on multi-processor machines, however, in both cases, the calls end up on the same connection, so the difference is minimal, if measurable at all.

Categories