Skip to Content
avatar image
Former Member

Scheduler problems related to execution of a single BLT by many schedules

Hello all,

We are running several MII instances in a distibuted architecture using a single generic BL transaction to transfer different types of messages from the site instances to a single central instance. The central instance has several schedules that run the same generic transaction with different parameters in order to transfer different types of messages.

As far as possible we have tried to avoid overruns where two of these schedules are running at the same time, but eventually the scheduler becomes "stuck" where many of the "Next Run Time" values indicated on the Scheduler table are in the past. When in this state the Scheduler page indicates that the transactions are running, but no messages are transferred.

Do we need to ensure that a transaction is never reused across different schedules, or is there another likely cause for the problems we are experiencing (e.g. scheduled next run times not updating when the MII instance is restarted)?



Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

4 Answers

  • Best Answer
    avatar image
    Former Member
    Jul 15, 2009 at 11:53 AM

    Hi Marc,

    leads this to something like serializing transactions in MII? If so, have a look at the following threads:

    How to strictly serialize MII TXs


    CurrentWrite with Simulator Tag does not save value




    Add comment
    10|10000 characters needed characters exceeded

  • avatar image
    Former Member
    Jul 14, 2009 at 10:12 AM

    Hi Mark,

    Did you check the log? What message it is showing in logs.

    I think the same transaction is trying to run two times,there its got stuck.

    I dont know that we can use the same transaction to run at same time twice and even never tried.


    Add comment
    10|10000 characters needed characters exceeded

    • Former Member Former Member

      Hi Rick and the other gurus,

      Following is a description of the problem (to add to Marc's initial post).

      Problem description:

      The scheduler seems to get stuck in the past (where the next scheduled run time is in the past). Hence no transactions are executed henceforth. Additionally, when trying to execute the transaction manually via the schedule editor, the transaction does not run.

      Current Workaround:

      Currently we disable the scheduler, disable schedule > save > enable schedule > save. This progresses the next run time and the transaction executes at the next cycle.

      Possible Reasons (unsubstantiated):

      The only difference between this application compared to others, is that we designed a couple of generic transactions that are called via different schedule items (with different input parameters). Occasionally, there are also transaction overruns (transaction not completed before next scheduled run time). However, it is my understanding that if a transaction is still busy, the scheduler will not force/spawn a new instance of the transaction u2013 correct me if I am wrong.

      We have been through the Netweaver Logs (system and application) and are unable to point a possible reason for this happening. We think that the trigger may be schedule overrun attributed to load u2013 however cannot say for sure.

      Iu2019d really appreciate any input you could provide to assist. Thanks

  • avatar image
    Former Member
    Jul 14, 2009 at 09:53 AM

    Additional details: all instances are running MII Version 12.0.7 Build(20)

    Add comment
    10|10000 characters needed characters exceeded

  • avatar image
    Former Member
    Oct 26, 2009 at 02:13 PM

    problem disappeared after further netweaver performance tuning was done

    Add comment
    10|10000 characters needed characters exceeded

    • Former Member Jeremy Good


      We now have the exact same problem.

      When a transaction fails while running thr scheduler - it gets locked and stays at "running".

      We are on patch-6 SP08.

      Checked with basis- and they confirmed that they applied patch-6 directly - assuming -patch-06 includeds all the prior fixes.

      is that true?

      if so, then we have a problem of jobs getting into "deadlock" in prod.

      Please let me know.