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

[Former Member]

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)?

Thanks,

Marc

[Former Member · Accepted solution]

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

[]

Regards

Michael

[Former Member]

problem disappeared after further netweaver performance tuning was done

[jcgood25]

Marc,

Have you looked at SAP Note 1386055 for the SP08 updates? Based upon your NW tuning making the situation go away without resolving root cause, I would be suspect that a heavily loaded schedule with numerous jobs running at higher frequencies would lead to the locks described in the note.

Glad to hear it is not causing you problems, but it would be a good idea to look into updates and testing to your landscape to confirm the SP08 with your solution.

Regards,

Jeremy

[Former Member]

Hello,

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.

regards,

Pramod

[Former Member]

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.

-Suresh

[Former Member]

Hi Suresh,

There is nothing obvious in the logs at the warning level of severity or above.

In the past, I have experimented with two schedules that call the same transaction, putting a Pause action block in it so as to simulate instances of a long-running transaction that could overlap. I found that the first schedule would run, then the second would skip its planned execution because the first was still running. There also appeared to be no problem with the scheduler eventually stalling, although maybe I didn't test over a long enough period, or with enough over-running schedules.

-- Marc

[Former Member]

Marc,

I didn't know that we can schedule two transactions. Thanks for the info.

May be Jeremy can give some inputs on this.

-Suresh

[Former Member]

Sounds like a bug to me. There is no reason that you should be restricted to running a single instance of a transaction at a time, particularly if they are on different servers. Even on the same server, this should work fine. To be safe, if you are calling the same transaction from two different scheduled items on the same server, be sure to provide slightly different parameters to the transaction, just to make them "unique" (even if they are just "dummy" parameters). Maybe the scheduler gets confused otherwise.

[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

[Former Member]

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