org.jinterop.dcom.common.JIException: The associated session is being destroyed. Current call to COM server has been terminated. [0x00001051]

Help
shmichel
2014-02-11
2014-08-21
  • shmichel

    shmichel - 2014-02-11

    Hi,

    running j-interop 3.0 on a linux machine connected to windows 2008R2,
    i see in the j-Interop.log this message:

    Feb 10, 2014 2:13:13 PM JISession Release_References_TimerTask:run()
    SEVERE: Exception in internal GC
    org.jinterop.dcom.common.JIException: The associated session is being destroyed. Current call to COM server has been terminated. [0x00001051]
    at org.jinterop.dcom.core.JIComServer.call(JIComServer.java:963)
    at org.jinterop.dcom.core.JIComServer.call(JIComServer.java:945)
    at org.jinterop.dcom.core.JIComServer.addRef_ReleaseRef(JIComServer.java:1029)
    at org.jinterop.dcom.core.JISession.releaseRefs(JISession.java:982)
    at org.jinterop.dcom.core.JISession.access$9(JISession.java:969)
    at org.jinterop.dcom.core.JISession$Release_References_TimerTask.run(JISession.java:347)
    at java.util.TimerThread.mainLoop(Timer.java:512)
    at java.util.TimerThread.run(Timer.java:462)

    Whats does this message mean? and why does it happen?
    Thanks a lot for your help :)
    Shmichel

     
    • Vikram Roopchand

      Hi,

      Wow :) ... Never thought I would see this one. Can you explain the scenario
      ? What exactly is happening at the back end ? And is this reproducible with
      a small piece of code ?

      Best regards,
      Vikram
      On Feb 11, 2014 2:25 PM, "shmichel" shmichel@users.sf.net wrote:

      Hi,

      running j-interop 3.0 on a linux machine connected to windows 2008R2,
      i see in the j-Interop.log this message:

      Feb 10, 2014 2:13:13 PM JISession Release_References_TimerTask:run()
      SEVERE: Exception in internal GC
      org.jinterop.dcom.common.JIException: The associated session is being
      destroyed. Current call to COM server has been terminated. [0x00001051]
      at org.jinterop.dcom.core.JIComServer.call(JIComServer.java:963)
      at org.jinterop.dcom.core.JIComServer.call(JIComServer.java:945)
      at
      org.jinterop.dcom.core.JIComServer.addRef_ReleaseRef(JIComServer.java:1029)
      at org.jinterop.dcom.core.JISession.releaseRefs(JISession.java:982)
      at org.jinterop.dcom.core.JISession.access$9(JISession.java:969)
      at
      org.jinterop.dcom.core.JISession$Release_References_TimerTask.run(JISession.java:347)
      at java.util.TimerThread.mainLoop(Timer.java:512)
      at java.util.TimerThread.run(Timer.java:462)

      Whats does this message mean? and why does it happen?
      Thanks a lot for your help :)
      Shmichel


      org.jinterop.dcom.common.JIException: The associated session is being
      destroyed. Current call to COM server has been terminated. [0x00001051]https://sourceforge.net/p/j-interop/discussion/600730/thread/f7aacce0/?limit=50#ccba


      Sent from sourceforge.net because you indicated interest in
      https://sourceforge.net/p/j-interop/discussion/600730/

      To unsubscribe from further messages, please visit
      https://sourceforge.net/auth/subscriptions/

       
      Attachments
      • shmichel

        shmichel - 2014-02-11

        Thanks Vikram,

        our linux machine is always connected to a windows 2008 R2 machine,
        once in a while (don't know why) we see the error message in the j-interop.log file.
        Even when removing all our code (not j-interop) we still see the message.
        Our problem is that we think that this causes a socket leak since after this message we notice one more file descriptor not closed properly. Can this cause such leak?
        How can we fix such error?
        Thanks a lot,
        shmichel

         
  • ron@work

    ron@work - 2014-07-30

    Hi,

    Was a solution to this problem ever found as I have hit the same problem?

    2014-07-29 07:02:14,385 ERROR org.jinterop Exception in internal GC
    org.jinterop.dcom.common.JIException: The associated session is being destroyed. Current call to COM server has been terminated. [0x00001051]
    at org.jinterop.dcom.core.JIComServer.call(JIComServer.java:963)
    at org.jinterop.dcom.core.JIComServer.call(JIComServer.java:945)
    at org.jinterop.dcom.core.JIComServer.addRef_ReleaseRef(JIComServer.java:1029)
    at org.jinterop.dcom.core.JISession.releaseRefs(JISession.java:982)
    at org.jinterop.dcom.core.JISession.access$9(JISession.java:969)
    at org.jinterop.dcom.core.JISession$Release_References_TimerTask.run(JISession.java:347)
    at java.util.TimerThread.mainLoop(Timer.java:512)
    at java.util.TimerThread.run(Timer.java:462)

    Regards
    ron@work

     
    • Vikram Roopchand

      Hi,

      No it was never resolved. This can only happen when the client (j-interop)
      is holding no references to any COM interface on the server. The library
      clears up the server. Can happen due to long time of inactivity. Is this
      the case here ? If so, can you try calling some NOP sort of a method
      periodically.

      Best regards,
      Vikram
      On Jul 30, 2014 6:52 PM, "ron@work" ron-at-work@users.sf.net wrote:

      Hi,

      Was a solution to this problem ever found as I have hit the same problem?

      2014-07-29 07:02:14,385 ERROR org.jinterop
      http://sourceforge.net/../Timer-14 Exception in internal GC
      org.jinterop.dcom.common.JIException: The associated session is being
      destroyed. Current call to COM server has been terminated. [0x00001051]
      at org.jinterop.dcom.core.JIComServer.call(JIComServer.java:963)
      at org.jinterop.dcom.core.JIComServer.call(JIComServer.java:945)
      at
      org.jinterop.dcom.core.JIComServer.addRef_ReleaseRef(JIComServer.java:1029)
      at org.jinterop.dcom.core.JISession.releaseRefs(JISession.java:982)
      at org.jinterop.dcom.core.JISession.access$9(JISession.java:969)
      at
      org.jinterop.dcom.core.JISession$Release_References_TimerTask.run(JISession.java:347)
      at java.util.TimerThread.mainLoop(Timer.java:512)
      at java.util.TimerThread.run(Timer.java:462)

      Regards
      ron@work


      org.jinterop.dcom.common.JIException: The associated session is being
      destroyed. Current call to COM server has been terminated. [0x00001051]
      https://sourceforge.net/p/j-interop/discussion/600730/thread/f7aacce0/?limit=25#8ae1


      Sent from sourceforge.net because you indicated interest in
      https://sourceforge.net/p/j-interop/discussion/600730/

      To unsubscribe from further messages, please visit
      https://sourceforge.net/auth/subscriptions/

       
      Attachments
      • ron@work

        ron@work - 2014-07-31

        Hi Vikram,

        Thanks for the quick response.

        Here is the scenario that I am currently testing under...

        A java app sends a message through j-interop to a COM interface on the server to run a process. These messages could be sent every few seconds, or there could be a gap of several hours between the messages being sent. The process on the server should respond in a timely fashion (currently 30 seconds), otherwise the java app will timeout. I have played around with the timeout's in both the java app and in the j-interop code and both are behaving as expected. I have also forced the server process to take a long time, and then I killed the process while the java app and the j-interop code were waiting for a response, but again, everything behaved as expected.

        For each message that is sent via j-interop, a new session is created and then destroyed after the response has been received, so basically I am creating a new session for every message. Obviously this is not the most efficient way (in terms of speed) for running this library, but could this be a factor?

        Regards

        ron@work

         
        • Vikram Roopchand

          Hi Ron,

          Yes this could be one of the factors. Each new session is a new COM
          instance, eventually, if there is a leak on either side, clean up might
          take away a valid instance (its the reference count that COM looks at).

          Best regards,
          Vikram
          On Jul 31, 2014 9:46 PM, "ron@work" ron-at-work@users.sf.net wrote:

          Hi Vikram,

          Thanks for the quick response.

          Here is the scenario that I am currently testing under...

          A java app sends a message through j-interop to a COM interface on the
          server to run a process. These messages could be sent every few seconds, or
          there could be a gap of several hours between the messages being sent. The
          process on the server should respond in a timely fashion (currently 30
          seconds), otherwise the java app will timeout. I have played around with
          the timeout's in both the java app and in the j-interop code and both are
          behaving as expected. I have also forced the server process to take a long
          time, and then I killed the process while the java app and the j-interop
          code were waiting for a response, but again, everything behaved as expected.

          For each message that is sent via j-interop, a new session is created and
          then destroyed after the response has been received, so basically I am
          creating a new session for every message. Obviously this is not the most
          efficient way (in terms of speed) for running this library, but could this
          be a factor?

          Regards

          ron@work

          org.jinterop.dcom.common.JIException: The associated session is being
          destroyed. Current call to COM server has been terminated. [0x00001051]
          https://sourceforge.net/p/j-interop/discussion/600730/thread/f7aacce0/?limit=25#8ae1/1d42/c339


          Sent from sourceforge.net because you indicated interest in
          https://sourceforge.net/p/j-interop/discussion/600730/

          To unsubscribe from further messages, please visit
          https://sourceforge.net/auth/subscriptions/

           
          Attachments
          • ron@work

            ron@work - 2014-08-21

            Hi Vikram,

            OK, the same problem has reoccurred again. Here are our findings...

            NOTE: For clarity, a lot of the code has been removed.

            Below is a snippet of the code that was resulting in the following exception.

            org.jinterop Exception in internal GC
            org.jinterop.dcom.common.JIException: The associated session is being destroyed. Current call to COM server has been terminated. [0x00001051]

            The code would sometimes fail when calling a COM function that took over two minutes to complete.

            public void callFiveMinuteTask(String paramOne, String paramTwo) {
            JISession session = JISession.createSession();
            try {
            IJIComObject comObject = getComObjectInterface(session);

            JICallBuilder callBuilder = getCallBuilder(0x12345678);
            callBuilder.addInParamAsString(paramOne.toUpperCase(), JIFlags.FLAG_REPRESENTATION_STRING_BSTR);
            callBuilder.addInParamAsString(paramTwo.toUpperCase(), JIFlags.FLAG_REPRESENTATION_STRING_BSTR);
            callBuilder.addOutParamAsObject(Integer.class, JIFlags.FLAG_NULL);
            Object[] results = comObject.call(callBuilder);
            

            } finally {
            JISession.destroySession(session);
            }
            }

            private IJIComObject getComObjectInterface(JISession session) {
            JIComServer comServer = new JIComServer(JIClsid.valueOf("AAAAAAAA-BBBB-CCCC-DDDD-EEEEEEEEEEEE"), session);
            IJIComObject comObject = comServer.createInstance();

            return (comObject.queryInterface("FFFFFFFF-GGGG-HHHH-IIII-JJJJJJJJJJJJ"));
            }

            private JICallBuilder getCallBuilder(int methodID) {
            JICallBuilder callBuilder = new JICallBuilder();
            callBuilder.reInit();
            callBuilder.setOpnum(methodID);

            return (callBuilder);
            }

            Here is a revised version of the code does not exhibit that problem.

            public void callFiveMinuteTask(String paramOne, String paramTwo) {
            JISession session = JISession.createSession();
            JIComServer comServer = null;
            IJIComObject comObject = null;
            IJIComObject comObjectInterface = null;

            try {
            comServer = getComServer(new JIComServer(JIClsid.valueOf("AAAAAAAA-BBBB-CCCC-DDDD-EEEEEEEEEEEE"), session));
            comObject = getComObject(comServer.createInstance());
            comObjectInterface = getComObjectInterface(comObject.queryInterface("FFFFFFFF-GGGG-HHHH-IIII-JJJJJJJJJJJJ"));

            JICallBuilder callBuilder = getCallBuilder(0x12345678);
            callBuilder.addInParamAsString(paramOne.toUpperCase(), JIFlags.FLAG_REPRESENTATION_STRING_BSTR);
            callBuilder.addInParamAsString(paramTwo.toUpperCase(), JIFlags.FLAG_REPRESENTATION_STRING_BSTR);
            callBuilder.addOutParamAsObject(Integer.class, JIFlags.FLAG_NULL);
            Object[] results = comObject.call(callBuilder);
            

            } finally {
            JISession.destroySession(session);
            }

            return (errorMessage);
            }

            private JICallBuilder getCallBuilder(int methodID) {
            JICallBuilder callBuilder = new JICallBuilder();
            callBuilder.reInit();
            callBuilder.setOpnum(methodID);

            return (callBuilder);
            }

            The main difference here is where the IJIComObjects (COM objects) go out of scope and become eligible for GC. It would appear that the general usage assumption is that strong references will be maintained to all COM objects created in the session, until the session is destroyed() by the user or the session itself is no longer strongly referenced.

            The cause :

            The main JSession static holds weak references to the com objects that are created by JSession instances. jinterop has it's own clean up thread, "jI_GarbageCollector", which is part of JSession, that monitors a queue of COM objects that become eligible for GC. When this is triggered the COM object/id is added to a list of de-referenced COM id's for the session. A timer task runs periodically to clear-up/release the COM Objects in the list for a session.

            With the first code snippet, it is possible in a system with regular/heavy GC to have the COM objects eligible for GC that are cleared/released as the session is being destroyed by the user, and this seems to generate the reported exception. To avoid this, COM object references should be held until the session is destroyed or perhaps rely on GC and clean up to remove sessions and COM objects rather than use destroy() (although we have not tested this).

            Regards

             

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks