Introducing Critical Events

Sat, 12/08/2018 - 11:40 By Dave Brooks

Not long ago, we were discussing a customer's technical issue here in the office. It seems that three of their Windows printers had gotten out of date, perhaps behind on driver updates or related problems. Anyway, when they scheduled a job in RPM Remote Print Manager® (RPM) to print to one of these devices, RPM suffered a failure.

However, the only symptom in RPM evident to the customer was that jobs weren’t printing. Further, they didn’t even know they had a problem with their Windows print drivers.

In our defense, the printer definitions were in such bad shape that if you selected one of them in a regular Windows application, Windows put up an error message that they were “driverless". We literally had never heard of this before, and I regret we don’t have a screenshot to share.

Nonetheless, it became instantly clear that we needed a better way of notifying the user regarding a category of more severe errors.

How to view critical events

In the user interface, go to the View menu. 

View menu

A sample critical event

Here is a sample critical event dialog from a recent post:

Critical events, device errors

Critical events, device errors

The category shown is a descriptive term from RPM. The date and time in the second column are when this event was encountered. The message is an attempt to describe what happened. None of this information suggests that RPM itself had an error. Rather, something happened that RPM needs to report.

To remove entries from this list, select one or more and click "Delete". Until you do that, the messages will remain.

The premise for a critical event

In our view, what makes an event significant is that it affects the outcome of your job processing, and you should know about it.

A critical event may require intervention from the administrator. Typical measures would include a configuration change, such as updating the login credentials for a user account in RPM after it they updated it in the “real” world of the Windows domain.

Another critical event may warn you that job processing failed, but RPM will attempt it again, and maybe it will work the next time. For instance, if RPM warns you that disk space is low, but in the interim, someone manages the disk space, then a future retry may succeed.

Another critical event may warn of an exception. It may be our code failure or an unexpected error return from Windows (which happens).

Yet another critical event may warn you that you need to stop the service and perform database maintenance

How do we notify about critical events?

We used the event handling system in RPM that we use for nearly everything already. With it, we can generate an event, then create handlers in the code to do something meaningful in the context of that handler.

We set up a database handler that will write the critical event to a new database table we created, called “alerts.” If your database does not have this table for any reason, the handler will generate an event log message, so you’ll still get the critical event by opening the Event pane in the user interface.

We created an email handler that will use the alert settings to send an email. To configure the alert settings (“from” and “to” plus others) go to the user interface, go to Configure / Notification Settings.

Please note that we take every effort not to duplicate critical events, so if a device is offline, you should not get 10,000 messages about it in your inbox.

Finally, if the RPM user interface is running, it will pop up the Critical Events dialog. You can also use the View menu as described above.

What are the current critical events?

  1. If RPM attempts to execute a user login to prepare for a device or action configured to use login credentials, and that login fails
  2. If you send a job to the AppSocket port and there is no setup for that port, including printer emulation data
  3. If the device tester fails a device for any reason
  4. For any number of specific printer related issues
  5. If a database operation results in an error message returned from the database, or if there is an exception processing the request; this includes updates, inserts, deletes, and queries
  6. For the following license-related errors:
    • The product code in the license does not match the product currently running
    • If any of the licenses return an error on open
    • If a license trial expires
  7. If the network code detects that the MAC address has changed from the last time RPM ran
  8. Any error reported by the PCL to PDF transform process
  9. Once every 10,000 new print jobs, RPM will remind you to perform database maintenance
  10. The LPD protocol module reports critical events for several, related, reasons:
    • if the commands are random data and not LPD commands; this may happen when someone sends a print job directly to the LPD printer port or uses a security scanner that sends web requests
    • if we receive a queue status request for a queue that does not exist
    • if we receive a print job for a queue that does not exist and we don't have permission to create it
    • if it looks like a properly formatted LPD command but we don't recognize the command code
  11. Another event reported by LPD is when you send a print job to a queue you have not created yet, and RPM creates it because "auto-create queue" is on by default. We are just letting you know. You must assign some setup to this queue or the jobs won't print.
  12. If a transform takes an exception during job processing
  13. If the email program fails for any reason, including sending a job or an alert
  14. If you are running a filter action, which runs a program, and the program returns an error code or writes to the standard error log
  15. Errors on files RPM opens for you, writes to, or reads; this includes files related to print jobs
  16. If RPM is unable to create a folder (such as one of our system folders) or to create a file in a folder, which would usually be an incoming job or a file created while processing a job