jvm issue after rmi call

Feedback
sk1234
2012-11-20
2013-04-25
  • sk1234

    sk1234 - 2012-11-20

    Hi, firstly I'd like to say I love using jpype so far.  It's extremely easy to figure out and integrates well with python but I have come across a roadblock:

    I'm using win 7 (64bit) with python 2.7 (64bit), I've tried with both jdk1.6.0_34 and jdk1.7.0_05.  I'm calling the main method from a jar file.  The jar file is really from an external 3rd party provider but I looked into the code and it's calling an RMI server using a thread.  The main method simply starts a thread that attempts to connect to the server and then returns control to the caller. 

    I don't think this would be an issue as java jvms will exit only once all non-daemon threads are complete.  All works well, the RMI service gets called from the client jar file, I get std output on the screen and everything completes fine. 

    The problems starts right after this call.  Right after the call completes to this service, nothing else happens on the python side.  I have print statements afterwards, sleep() methods, etc.  None of those get executed.  Of course, if I take out the call to this java method then everything returns normal.  I can't figure out what is going on here, any ideas? 

    It basically looks like this:

    jpype.startJVM(jvmlib,"-Djava.class.path=some.jar","-Djava.security.policy=java.policy","-Djava.rmi.server.codebase=someurl")
    A = jpype.JClass("loader.RmiLoader")
    A.main(stringargs)
    # nothing happens after this point

     
  • Steve Menard

    Steve Menard - 2012-11-21

    Sorry to start with the "obvious" questions, but are you sure the call to main isn't a blocking call ?

     
  • sk1234

    sk1234 - 2012-11-21

    Not sure, it makes a rmi call from the client jar and the client classfile only gets control back when the portion on the server completes, so it could be blocking on the server rmi function.  The client jar spawns a thread from main and calls a function which spawns another thread which calls the server.  There isn't any blocking on the client side, no synchronized calls, etc.

    I know the call completes successfully because it generates some local txt files and everything is fine on the server as well saying it was success.  I've tried to reload the module right after the call thinking it was some jvm issue.  I tried to do a system.exit on the java side from jpype as well.  Python -v doesn't give much info either.

     
  • Steve Menard

    Steve Menard - 2012-11-21

    HUmm … interesting. I haven't worked on JPype in quite a while, but I don't remeber seeing an issue like what you are describing.

    I know that not exactly the point .. but would it be very difficult to create a Java equivalent to your program, and see if it exhibits the same behavior ?

     
  • sk1234

    sk1234 - 2012-11-21

    Not sure what you mean, do you mean not using jpype and use strictly java to call the rmi server?  We have that, no issues with it in purely java or calling from a unix shell script.  The jpype program doesn't do anything except create a class and make a call to main().

    Is there anyway to get more debugging info on jpype as it makes the call and terminates the call?

     
  • Steve Menard

    Steve Menard - 2012-11-21

    Yes. If you can compile JPyupe yourself, you can setup some call tracing that could help. I don;t have the JPype sources handy, so I'll have to get back to you on exactly how to do it.

    There is one thing that comes to mind, though I doubt that it would be an issue in your case. You mentioned in your first email that Java would not exit until all non-deamon threads have completed. This is very true .. when java.exe is on control.

    I would not rely on this being true when Python is in control. Even if Python makes the same "contract" with it's own threads.
    The Python VM has no way to know which JVM-created threads are deamon threads or and which are regular ones.

    AS I said, I doubt this has anything to do with your current problem, but it is something to keep in mind.

     
  • sk1234

    sk1234 - 2012-11-21

    Well I thought about that, thats why I added sleep and print statements right after the call just to see if control is passed back to python prematurely.  That doesn't seem to be the case as those statements never get executed.  The server function also prints to stdout with status updates and I can see that python is still waiting for it to finish and it completes.

    The only thing I can think of is that in an rmi call the jvm makes a call to the server's jvm to execute the code so it is somehow corrupting the local jvm and confusing jpype when it comes back.

     
  • sk1234

    sk1234 - 2012-11-26

    Any luck with the tracing info?  I can compile on my side but need to know how to add the debugging.

     
  • Steve Menard

    Steve Menard - 2012-11-26

    Sorry for the delay.

    In the file jpype.h, uncomment the line
    //#define JPYPE_TRACING_INTERNAL

    And recompile. THis will generate a lot of traces, in particular everytime a call to Jpype is done

     

Log in to post a comment.