Today I’d like to discuss an uncommon error that can occur when trying to launch selected .bps files that are active in the BatchPatch service instance. First, if you’re not sure what the BatchPatch service instance is, you might not be running BatchPatch as a service. This error can and will only occur when a grid is already running in the BatchPatch service instance, and then you try to view the contents of that grid. Running BatchPatch as a service is something that users can do if/when they want to be able to have BatchPatch run and execute scheduled tasks without needing to be logged-on to a computer with BatchPatch actively open and running. The service instance enables BatchPatch to run as a service, in the background, even when no one is logged-on to the computer. To learn more about running BatchPatch as a service, please review this page: Running BatchPatch as a Service
The error shown below that I want to address is:
Error retrieving service instance data: The maximum message size quota for incoming messages has been exceeded. To increase the quota, use the MaxReceivedMessageSize property on the appropriate binding element
When BatchPatch is running as a service, the main BatchPatch instance (the one you see when you manually launch BatchPatch) communicates programmatically with the (hidden/invisible) BatchPatch service instance. When you view grids that are currently active/running inside the service instance, the main BatchPatch instance queries the BatchPatch service instance to retrieve the data that it then displays in the service instance grid viewer, as illustrated in the screenshot below.
When the main BatchPatch instance queries the BatchPatch service instance for grid data, the BatchPatch service instance then packages and compresses the data to send to main BatchPatch instance. If this compressed grid data is not smaller than the MaxReceivedMessageSize property, then the above-mentioned error message is generated. At the time of this writing, the BatchPatch MaxReceivedMessageSize is set to 2000000. This value is *not* user-configurable at the time of this writing, though we may expose this is as a user-configurable setting in a future version. In practice, 2000000 is plenty large enough to accommodate the very large majority of grids. However, if your actual .bps file grid data starts approaching 20MB (or greater), you might encounter the above-mentioned error. Even in the absence of this error message, a 20MB .bps grid file is still very large and should be cleaned up to make smaller.
Reducing the size of a BatchPatch .bps grid file
To check how large your .bps grid file is, simply browse to the location of the .bps file in Windows Explorer, and then right-click on the file and select ‘Properties.’ You can see in the screenshot below that my .bps file is only 24.4KB. If you are seeing the above-mentioned error message, then your .bps file is probably at least 15MB-20MB in size.
To reduce the size of your .bps file you have a few different options:
- Find where the bulk of the data in the .bps file is, and then remove/purge that data. Usually if you have a very large .bps file, the bulk of the data is going to be in the ‘All Messages’ column. You can selectively and simply purge this data by selecting the desired rows in the grid, and then clicking on ‘Actions > Clear column contents’ as described here: Clearing Column and Grid Contents in BatchPatch. If you are using BatchPatch job queues, you can even add a step to your queues that will execute a ‘Clear column contents’ operation for you.
- If you don’t want to clear the column contents in your existing .bps file, you may simply archive your existing .bps file, and then start a new one from scratch.
- Alternatively, you might prefer to split up your existing .bps file into multiple .bps files, which you can do by moving hosts from one grid to another. To do this, select the desired hosts to be moved, and then click on ‘Actions > Move or copy host(s) to different tab‘, and then make sure to select the option to ‘Move entire rows‘.