Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.3.2
    • Fix Version/s: 1.3.4
    • Component/s: BPEL Runtime
    • Labels:
      None
    • Environment:
      any

      Description

      In Memory DAO, there is a cleanup strategy, which assigns TTL 10 min. for in-memory instances.
      I works for 1 in-memory process, but for 2 or more, there are cases when it doesn't do cleanup.

      I figured out that cleaning strategy in bpel-runtime/src/main/java/org/apache/ode/bpel/memdao/ProcessDaoImpl.java holds a static _lastRemoval field, which is updated globally. But if there are >1 in-mem processes, it may cause only one to do cleanup.

      A simple patch, which removes static declaration solves problem, because then, cleanup is done separately for each process.

        Activity

        Hide
        Rafal Rusin added a comment -

        #797066, #797065

        Show
        Rafal Rusin added a comment - #797066, #797065
        Hide
        Karthick Sankarachary added a comment -

        Rafal, Can you please add the subversion revision number of your actual commit here? Thanks, Karthick

        Show
        Karthick Sankarachary added a comment - Rafal, Can you please add the subversion revision number of your actual commit here? Thanks, Karthick
        Hide
        Rafal Rusin added a comment -

        What's up with this comment?
        memdao-dumper was just for diagnosing leak. For actual commits, please check subversion commits.
        BTW. This issue is fixed. If you have some problems with it, please reopen.

        Show
        Rafal Rusin added a comment - What's up with this comment? memdao-dumper was just for diagnosing leak. For actual commits, please check subversion commits. BTW. This issue is fixed. If you have some problems with it, please reopen.
        Hide
        Karthick Sankarachary added a comment -

        I believe we already cleanup process instances on a process-by-process basis. As you can tell from the declaration below, the _lastRemoval field is local to the process DAO (at least in ODE 1.X):

        private volatile long _lastRemoval = 0;

        Right now, every time a new instance is started, the process checks to see if it can clean up any instances that have been running for more than 10 minutes. I think a cleaner approach would be to try and discard long-running instances periodically (say every minute), as opposed to just when a new instance starts.

        The rationale behind the TTL constraint is that in-memory processes are typically short-lived and should not have to run for longer than 10 minutes. Having said that, if there is a good reason for creating in-memory processes that need to run for more than 10 minutes, then we may want to make that TTL threshold configurable (i.e., initialize it based on a user-defined configuration parameter).

        Finally, I see that you marked a number of DAO fields as transient, which seems redundant, considering that the in-memory DAO objects are never serialized.

        Show
        Karthick Sankarachary added a comment - I believe we already cleanup process instances on a process-by-process basis. As you can tell from the declaration below, the _lastRemoval field is local to the process DAO (at least in ODE 1.X): private volatile long _lastRemoval = 0; Right now, every time a new instance is started, the process checks to see if it can clean up any instances that have been running for more than 10 minutes. I think a cleaner approach would be to try and discard long-running instances periodically (say every minute), as opposed to just when a new instance starts. The rationale behind the TTL constraint is that in-memory processes are typically short-lived and should not have to run for longer than 10 minutes. Having said that, if there is a good reason for creating in-memory processes that need to run for more than 10 minutes, then we may want to make that TTL threshold configurable (i.e., initialize it based on a user-defined configuration parameter). Finally, I see that you marked a number of DAO fields as transient, which seems redundant, considering that the in-memory DAO objects are never serialized.
        Hide
        Rafal Rusin added a comment -

        Attaches is a memdao to xml dumper using xstream.
        It does a dump each 30 secs.
        I used it for diagnosing leak.

        Show
        Rafal Rusin added a comment - Attaches is a memdao to xml dumper using xstream. It does a dump each 30 secs. I used it for diagnosing leak.
        Hide
        Ciaran Jessup added a comment -

        Excellent news, if this is the case you've just saved me a couple of days work I've had to schedule to look at why we're (still) receiving OutOfMemory errors in our ODE workflows (even after all the memory leak purges I went through a month or so ago.) I look forward to testing this patch!

        Show
        Ciaran Jessup added a comment - Excellent news, if this is the case you've just saved me a couple of days work I've had to schedule to look at why we're (still) receiving OutOfMemory errors in our ODE workflows (even after all the memory leak purges I went through a month or so ago.) I look forward to testing this patch!

          People

          • Assignee:
            Rafal Rusin
            Reporter:
            Rafal Rusin
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development