Slow or incomplete updates in HTML5 event browsers



This is for OBM 2020.10 on RHEL7 with remote Oracle DB, HA with 2 DPs and 4 GWs. Patches up to early January, with patches from 1/15 and 1/22 pending in our dev environment so will soon be up on this environment. The production environment is eyes-on-glass 24x7 with multiple users handling events.

Since moving from the Flash event browser to HTML5 the users have reported slow refresh on new events. They have a 3-pane event browser, unwired, each with their own filter. New unassigned for this group events show in the top pane. A user takes ownership, so the event then appears in the 2nd pane (assigned to users in this group). The 3rd pane is for events assigned to other groups from this group in the last 24 hours.

The users typically set the first pane to trigger the sound on new event. In some cases a user will hear the ding but see no event. If they refresh the pane or the entire window they then see the event. The Event counter may or may not reflect the unseen event, but that may be unreliable as there is a 1/22 hotfix soon to be installed addressing the event counter updates.

Some users do not get a ding or see an event, but the counter on "Assigned to group" shows a number, so they refresh and _then_ see the event.

Server logs do not indicate any particular errors. We have a forwarder sending events to Splunk and it is updated with new/changed events as they arrive, so it's not the event pipeline being stopped up.

I personally get the sense that the browser is just slower to refresh. "Not showing" for the users is anything more than several seconds, but one user might see the event several more seconds before other users. It boils down to a new event is not pushed to the user's event browser, but that the event browser appears to poll periodically, and perhaps that poll might be slow if the user's system is lagging for any reason. I have not confirmed this, but it feels to me like the HTML5 browser is less proactive than the old Flash browser.

I am trying now to confirm if that is truly the case. I have the static Flash-enabled Firefox browser built and will try to compare the concurrency of the HTML5 vs Flash event browsers. Luckily, the HTML5 event browser these users rely on was copied from a matching Flash event browser. I feel like the slowness is in all HTML5 event browsers, but their particular page if most import right now.

I am going to throw all of this into a support case as well. Wondering here if others have noticed this effect.

  • Hi,

    Do the missing events appear in the event list after some time, or do you have to manual refresh?
    I have an issue in 2020.05 which means that some events don´t appear in the event list, despite being handled in the event  pipeline (event counters at the bottom of the browser are updated, so it´s just posting the events in the event list that fails). A manual refresh fetches all events. In my case this is related to using more than 1 criteria for event sorting, works fine with "plain" event page (standard sorting and no filters).
    Support says that my issue is solved in 2020.10, but your issue sounds somewhat similar......



  • Some of the users report having to refresh their browser (F5). It appears that events may appear in two panes with mutually-exclusive filters, indicating some delay in refresh in each pane. DevTools shows fairly steady traffic at about 5 second intervals. I have not yet compared to the old Flash page for refresh concurrency.

    The event counter problem has a hotfix out, and that hotfix did resolve the problem with severify numbers being 0 and status numbers falling out of sync.

    I do not believe I experience the issue...if I get a ding I see an event, but the users report long delays if not outright gotta-refresh-browser experiences. I do have a user-level account for testing, and again did not experience the problem, which is what makes me think they were accustomed to a faster, more timely Flash page. The HTML5 page should be as snappy. We are pushing that question up the line now.

  • Hello Scot,

    because of Flash EOL, we have upgraded to 2020.10 too in the  beginning of January.

    In our environment, OBM is being monitored by 24x7 operators, who - since transition to HTML browser - argue about the same problems: Event browser stops being updated with new events, page refresh is required to resume the auto refresh behavior.

    I think I have done about month ago the parallel html/flash browser test and the flash browser was updated normally, as in old OBM.

    Tested in multiple browsers (Chrome-default, Firefox, Edge), it behaves the same.

    We have also tried to have one HTML browser open for whole day and it refreshed OK. This makes me think, that it is maybe somehow related to the complexity of event browser filter? (we don't use view filters). But I don't know.

    I have opened support ticket for this issue, as part of solution, I am installing event browser / opr-webapp hotfixes, the latest is, installed on last Wednesday. I think that the hotfixes improved the browser behavior somehow, but I still don't have confirmed from the operators, that the issue is resolved...


    Stan Pokorny


  • I only now opened a case (finally) for one condition I have confirmed.

    We have an event browser page with 3 panes, no wiring, each with a different event filter applied. The first filter is simple: events assigned to a specific group but not assigned to a user.

    If an event lands in the pane, assigned to the group but not assigned to a user, and is immediately closed, it will remain in view in the pane. I can click on the event and open it into an event view window. If, however, I click Export in the pane to create an xlsx file the exported list is events shown at all, despite (in this case) two events being displayed in the pane.

    I have a Firefox ESR with Flash running with a Flash version of the same event browser page, with the same filters applied to the individual panes. The assigned-to-group-but-not-to-user is blank.

    I had have two HTML5 windows open. I refreshed on and the events disappeared, but the other I have left, still showing the two closed events. All 3 (Flash and HTML5x2) show new events as they arrive and clear them as they are owned by the ITOps operators. It appears to be just these events that landed in the filter and were promptly cleared that leaves them in the browser.

    Users report the same problem in the 2nd pane, which filters for assigned-to-group-and-assigned-to-user. If an event is cleared (closed by clearing event or closing of related events) then a refresh is required to clear the event from the view. Same applies to yet another filtered pane showing events in a 5-minute hold group (in case they are cleared within 5 minutes).

    The upshot is that an event pane with a filter applied may not clear events from the pane even when they no longer qualify for the filter. A refresh of the pane (ellipsis, Reload) or the entire page (browser F5/Ctrl-R) builds a new display list, and is the only way to remove the stale events.

  • I have OCTCR19G1206123 on the way up our stack. I will apply it to our dev servers today, then deploy to the non-prod stack in the next 1-2 days and finally promote to prod next week if not before.

    It took me quite a while to pin this down. Today was the actual breakthrough. In HTML5 and Flash before now I could not recreate the issue, but now that it is pinned down to a filtered event list not clearing events no longer qualified for the filter we at least have something to go on. Leaving the browsers open overnight gave me a couple of the errant events.

    We have all the hotfixes up to Feb 2nd applied already, which included a few other event browser tweaks.

  • We have everything applied up to Feb 2nd. I am currently staging up the following hotfixes through our Dev environment, then to non-prod before going to prod:

    • '2021-02-08 - Cumulative fix for OCTCR19G1206123 OCTCR19G1203943 2020.10'
    • '2021-02-08 - OCTCR19G1242023 create_assignment_by_aspect fails if mandatory instance parameter empty 2020.10'
    • '2021-02-10 - OCTCR19G1251163 - SD02839997 - Unable to close certain events'


  • Clearing this display issue requires a reload of the event browser pane, whether by ellipsis Reload or a browser F5/Ctrl-R. If two panes (each with a different filter) each have these stale events then each pane needs reload. A browser refresh is easiest, with page rebuild taking on average 5-8 seconds, which adds up.

    The event counters have their own hotfix. They were clearly out of sync overall in certain panes. As I watch even the Flash UI event filtered event browser the counter display does not quite match up to what I see for the "Assigned to my group" counter. In any event, the operators (users) did notice the counter alignment problems pretty quickly, as they could serve as an indicator of a event display problem.

    For us the lists are simple sort by a single column, so a complex sort won't be in play here. There was a hotfix to address when showing a column from a CMA where the CMA has a space in its name _and_ where the CMA contents have a space.

    In our case it was for ticket status on a sync from Service Now, but this first pane displays that column but none should have tickets assigned as the tickets are created by the operators upon receipt of the event. Events triggering automated tickets do not ever land in these filtered lists.

    The 2nd pane on the operators page is filtered to "assigned to group and assigned to user", and on those the CMA content space bug would apply.

  • This is specific to OCTCR19G1165239, which is listed on the ITOM Marketplace, regarding the aforementioned post, regarding the OBM 2020.10 Hot-Fixes. However, now, Intermediate Patch 1 for OBM 2020.10 is released, which I've tested in DEV, burned in for a week, and rolled into PROD.

    Release notes (

    Linux IP 1 is here:


    OCTCR19G1165239: OMi Event Delay is detected - bus started only in Active DPS [ CAUSE: issue on GWS html browser causing bus to slow down ]
    Long processing on the Gateway Servers of the html5 browser causes the bus to back up and resulting in event delay
    HTML Event View necessarily iterates the event list even if the event does not match the filter.
    A Hotfix is available through Software Support.

    However, I would have this question for you about the annotations in the events, if any, due to integration with any ticketing tools.

    Also, have you used the OBM Configuration Wizard (after all processes have been disabled on your Gateways and then DPSs), in order to assign more java heap memory?

    Thank you!