Skip to Content
author's profile photo
Former Member

MxEventAgentService:Error running eventagent check

Posted on May 05, 2011 at 01:53 PM 5 Views

As the title indicates, we've been getting these error messages in our system log from various event services for as long as I can remember:

MxEventAgentService:Error running eventagent check

It is JobId 0 (makes sense, as it is coming from one or the other of our event agents) and has no additional info.

Also, our event services seem to "lock up" and stop running at various points, and I can't help but wonder if this message is related. We'll see this message about 40 times a day from various event services, but usually only get one or two lock-ups per week. Still, it is a serious issue when role requests aren't processed in our Production environment because an event agent service just stops. Once we stop/start the service it will resume processing as normal.

Are we doing something wrong? Each of our event agent services has 4-5 event agents assigned to it. Is this too many? They are all reading different tables, I am not sure why this would be a problem, but maybe it is just overloaded?

Any similar experiences out there, hopefully with some sort of solution?

SAP Identity Management
Add comment
10|10000 characters needed characters exceeded

  • Follow
  • Get RSS Feed

1 Answer

  • author's profile photo
    Paul Abrahamson
    Posted on May 05, 2011 at 02:57 PM

    We thought of using an event agent to monitor a table and run a job to process it. Because the event agents have a polling interval before running the job, we felt that it would be simpler to just schedule the job itself to poll the table every x minutes. I couldn't quite understand the purpose of event agents for monitoring tables. Perhaps we have a gap in our understanding of them...

    Add comment
    10|10000 characters needed characters exceeded

    • Former Member
      May 05, 2011 at 06:17 PM

      You bring up a good point... This system was set up this way before I joined the project, and since then I've questioned quite a few of the original basic design assumptions and changed things, but I've kept using the event agents because they seemed like a good logical separation. Whether internally they are any more efficient than doing it your way, I really don't know...

      I guess I will describe the way we're using them:

      We have several queue tables that our custom User Interface (written in ABAP WebDynpro) will insert rows to. For instance, for a "Contractor Request", we drop a row into the ContractorRequestQueue table. There is a column for "Status" that we start at -1. The event agent reads this table and looks at the field Status, and will trigger our "handle contractor request" job if there are any rows. It polls every 30 seconds.

      QUERY: SELECT * FROM vlo.vapi_ContractorRequestQueue WHERE Status < 0
TESTFIELD: Status

      The "handle contractor request" job then changes the status to 0 while it processes, and then eventually will remove it from the table altogether.

      I suppose we could just have the "handle contractor request" job run every 30 seconds as well and only pull records that have status -1, but I just have to assume there is more overhead involved there... It must be more efficient to have the event agent services do it, right? Right?

      I really don't know. I wouldn't be questioning that assumption if the event services were running properly, but with this current issue, I'm tempted to give the other way a shot and see how it goes.

      Edit: I just found that the one that was crashing the most actually had 5 agents assigned to it that were all querying the same table... I've added WITH(NOLOCK) to the query in an attempt to keep a deadlock from causing the process to hang, in case that was the problem. I'll report back in a week and we'll see if it has lessened or resolved my issues.

      Edited by: Adam Harwell on May 5, 2011 4:39 PM