Login  Sign up

2022 Beta - Monitoring stalls with Queued items

I have 1097 monitors (all on CB).  To avoid bringing the system to its knees, the monitors are spaced out at :00, :03, :05 & :08 second intervals (e.g., checks every 100, 103, 105, 108, 110, 113, 115, 118, etc. second intervals), so that there should only be one monitor started at a given moment - serial vs parallel approach.

I noticed that there were no monitors recording, which is highly unusual.  When I looked in the monitor screen I noticed that there was a large number of monitors in Queued state and 18 monitors In Progress.  The In progress weren't valid (i.e., some of the targets weren't online anymore).

So, it appears that something happened that resulted in the In Progress not completing, and then stalled the queue.

It is very possible that there was a network transition.  The system is on VPN, and complete network transitions aren't frequent but aren't uncommon either.  JMR 7 recovered from these very gracefully, but perhaps JMR 2022 does not?

I'm now seeing jmrp.exe crashes.  I enabled debug, but when I click to send logs I see a warning about debug mode not being turned on.  There is no instruction to enable debug mode on restart, but I'm guessing that's necessary?  Anyway, once I have logs I feel uncomfortable uploading a ZIP file with my system configuration to this forum.  Is there an alternate way to get the logs to you?  And, are you able to confirm destruction of the logs upon completing analysis?

Please put JMR into debug mode and then repeat the actions that are causing the crash.  There is no identifying info in them about your machine besides its OS version number.  

Unfortunately, there is identifying information that would disclose who my clients are.  While I may be willing to share this information with you for troubleshooting purposes, I am not comfortable posting that information on a public forum for everyone to see!

Not sure what you mean by who your clients are and how anything could be tied back to you but anyway you can email them to support AT jaksta.com.  Please split the zip file into less than 6mb each email if larger than that.

Thanks.  Will send logs as soon as I can generate them.  

There's definitely a stability issue with the beta compared to JMR 7.  I never - not a single time - had a JMR 7 crash.  I've seen several crashes with JMR 2022.  I also see strange behavior (different from JMR 7), like a huge number of monitors "In Progress" in the monitor screen with no corresponding "Downloading" in the Home dashboard - the Home dashboard is correct, as these are not actually active monitors ... they just seem to linger behind in "In Progress" state.  

Like that, things seem to hang in JMR 2022 until the UI eventually just crashes.  When I check the taskbar, the JMR icon disappears when I mouse over it ... the process had died.  Again, I never saw anything even close to this in JMR 7.

I've wondered if JMR 2022 isn't recovering from network transitions gracefully when compared to JMR 7.  I use a VPN connection, which does experience state transitions occasionally.  Maybe JMR 2022 isn't handling these state transitions gracefully, leaving processes stuck "In Progress" because the underlying network connection was lost mid-check?  Speculation ...

I have 1018 monitors defined, and 305 actively monitoring to record.  This is all under Windows 10 64-bit.  Will send logs as soon as possible.  Thanks!

Once I have debug logs I should be able to see what is going on.

With that many monitors, might be good if you export them and send them through as well as I have never tested with any where near that many.

Please put a comment here once you have emailed them through.

Logs sent - two files (4MB each).

Noteworthy is that in the latest hang as seen in previous cases, I saw a large number of entries In Progress with no corresponding Downloading entries in the home dashboard.  I cancelled all active downloads and turned off monitoring.  Then I restarted monitoring, the JMR crashed.

Could you please send through your exported monitors?  Nothing in your logs is showing a crash, which probably means a deadlock of some sort.

The provided monitors export are not valid urls.  I gather you have changed them.  Could you please provide your exact export list so I can see what is going on with that many being monitored?

Login or Signup to post a comment