Probe Framework: Frequently Asked Questions
1. What happens if a Probe does not find any data at its data source?
If this occurs the first time the Probe is run, such as by an invocation of NetMeshBase.accessLocally, this accessLocally method throws one of the declared exceptions. The code invoking that method needs to catch and process all declared exceptions correctly. In particular, it needs to catch MeshObjectAccessException, which is the supertype of all exceptions thrown when something goes wrong reading from a Probe. Using the getCause method, the underlying reason can be found, such as ProbeException.EmptyDataSource.
2. I have added my Probe to the ProbeDirectory, but I cannot seem to get it invoked. What should I check?
Make sure your Probe class is actually available to the application:
- the application's StandardModule must contain the Probe class itself or declare a dependency on the StandardModule containing the Probe class
- the build process must make sure the Probe is actually being built
- the ProbeDirectory to which you added the Probe class is the ProbeDirectory used by the ShadowMeshBase attempting to invoke the Probe
- the MIME type of your data source is what you think it is.
In doubt, set a breakpoint on a suitable method in the ProbeDirectory implementation that you use, or in the ProbeDispatcher class to see what happens.
3. After a number of Probe runs, the objects returned by my Probe have null values and/or some are missing. How did that happen?
It is very important that your Probe throws an exception if anything at all goes wrong during the Probe run. For example, if you are accessing a backend system through an ApiProbe, and the backend system cannot be reached during a Probe run, or any other error occurred, you must throw an exception from the Probe.
If you do not throw an exception from the Probe and your Probe fails silently, the Probe Framework will assume - it has no information to the contrary - that your Probe ran successfully, and it just happens to be that only very few objects were instantiated during this Probe run. Consequently, the Differencer will delete most of the objects that were instantiated previously, and that may not what you intend. The behavior described in this question is the type of behavior you see if a Probe (incorrectly) fails silently.
Instead, if an error occurred, throw an exception (typically a java.io.IOException or one of the subclasses of ProbeException) and the Probe Framework will make sure that the previously obtained MeshObjectGraph should not be updated by this Probe run. In this case, any objects that your Probe may have instantiated during the run that ended with an exception will be discarded. Once the Probe runs successfully again, i.e. does not throw an exception (for example because the backend system came back up), the Probe Framework will continue the updates.
InfoGrid implements this default behavior under the assumption that out-of-date information is better than incorrect or no information. Of course, developers have complete control over which objects to instantiate or not in an error case, and whether to throw an exception.