Community
Participate
Working Groups
The cache of the MI services should not only cache the result of successful commands but errors as well. This would avoid re-sending commands that will fail to the back end. For example, if the ExpressionService requests the back end to create an invalid expression, we should not re-send this command a second time, even if the views request it; instead, we should use the cache to know what the failure result will be.
Created attachment 82340 [details] Fix of error message in RequestMonitor
Since this tries to improve error handling, I would like to make a related suggestion. I noticed that the RequestMonitor class, uses the Status.toString() method to set the message of the parent status. This is the reason why the Exprssion View shows a very long error when trying to evaluate an invalid variable. I think the RequestMonitor should use Status.getMessage() instead of toString() This can be seen in the attach patch. However, this may affect the message stored for a MultiStatus. Basically, when merging a Status into a MultiStatus, the messages are not merged. I'm not sure if this is a problem for DSF. I am not comfortable with the potential impacts of such a change, so I really would like Pawel's and/or Randy's opinion. Thanks
Hi Marc, I agree with you, I created bug 209066 for this problem.
Created attachment 82557 [details] Caching of Status, in Services In MICommandCache, instead of caching only a successful result, we cache both the result and the status. That way, failed commands can also be cached. As a side-effect, the patch also fixes what I think was a bug, where a failed coalesced command would be cached as if it were successful. I will wait for approval before checking this in.
Created attachment 83457 [details] Updated patch with refactoring of contexts I redid the patch with the latest code from the context refactoring. Can I commit it?
Looks good to me, go for it.
committed
Changes reviewed.
Closing out 1.0 bugs.
