On Fri, Jan 2, 2009 at 2:27 PM, Scott McKellar <[email protected]> wrote: > In dispatchCRUDMethod() we branch on the method type, doing whichever > of six possible operations has been requested. For the first four such > operations, we finish up by calling osrfAppRespondComplete(). I believe > that the purpose of this call is to notify the client that the response > is complete, and that he shouldn't expect more. > > For the last two operations -- "search" and "id_list" -- we normally > finish up the same way. However -- there seems always to be a however -- > if doFieldmapperSearch() returns an error, we don't call > osrfAppRespondComplete(), and neither does doFieldmapperSearch(). > > I am far from understanding this stuff, but it looks like the likely > result in this scenario is that the client gets notice of the error but > never gets notice of response completion, and probably times out while > waiting for it. > > Or am I missing something? >
The problem is actually the other way around, in that the caller may see a success message /after/ a failure status message for all but search and id_list. That's actually not a problem (other than the extra network traffic) since the client should ignore the second completion status message. IIRC, the perl and JS do indeed act that way. Not certain about C, Java and Python, though. More generally, OpenSRF status codes attempt to mimic the HTTP status codes, so every code above 199 is a completion code (100-199 are non-completing codes, "continue" and the like). In cstore we try as hard as we can to return an osrfStatus message at the point of failure, and then set err to -1 to tell OpenSRF that there was a problem. Where there's an error we send the relevant error status message and then hand control back to the OpenSRF library. -- Mike Rylander | VP, Research and Design | Equinox Software, Inc. / The Evergreen Experts | phone: 1-877-OPEN-ILS (673-6457) | email: [email protected] | web: http://www.esilibrary.com
