jaked / orpc Goto Github PK

Hi,

This is not really a bug, but it is a problem I came across and which took some time to track down, so that's why I'm reporting it here.

I'm not sure if you should really be allowed to do this, but it is possible to extend an RPC interface (or rather replace it with a new interface that has more methods). This I found quite useful in having a library that provides common services that are used by different applications, such as a monitoring of the server. This library is then used in a application that extends the interface to include application specific methods.

In the interface specification for the application, you have to repeat the definition of methods that are defined and implemented in the library. If not it compiles fine (since the use of the methods are only in the library code), but you get a runtime Rpc_client error that the method the library uses is not found. The specification duplication fixes this, and the calls seems to work fine.

However, there is a real danger lurking here. If you extends the type definition used in the RPC protocol (in my case the application had an extra exception defined), the mapping of types becomes wrong. If you are lucky it might throw an exception when trying to parse the XDR value, but it might parse just fine, but returning a wrong value.

I'm not sure what the best solution to this is, or if it is really possible to fix other than avoid extending the interface. I can try to strip down the code to a smaller example that illustrates this issue if you would like.

Thanks,

Hans Ole

myocamlbuild.ml of orpc fails to compile on with OCaml 3.12 beta due to changes in ocamlbuild. The function "flags_of_pathname" has been removed

Values of type "string list" as argument or result values seems to fail with OCamlNet 3.0
In examples/modules/

adding
protocol.ml
val concat_list : string list -> string _r

server_impl.ml
let string_to_list s =
["a";"b";"c";"d"]

...
let string_to_list s =
return ["a";"b";"c";"d"]

client.ml
C.concat_list ["a"; "b"; "c"; "d"] >>= fun _ ->

fails with server side:
[Tue Sep 21 14:28:00 2010] [add1] [crit] RPC server caught exception: Xdr.Dest_failure

and client
concat_list [ "a"; "b"; "c"; "d" ]
<=!

I have tested using string arrays generated from .x files only using OCamlNet and that seems to work.

Fails both when the string list is an argument or result. Also sync call fails. Guess this might be due to some optimization/changes done to XDR packing.

In the current version it seems like exception wrappers in the client are only created if the protocol file has exceptions.

If you remove the exception definition in the examples/modules/protocol.ml file (and also the call maybe_raise call to get it to compile), then the behavior of the other calls changes with regard to internal Rpc_client exceptions, such as Rpc_client.Message_lost. Now the exception get handled by the Rpc_client exception handler, and not returned to the caller witch might be waiting to catch it with Lwt.catch().
(To test, just add a sleep between some of the calls and kill the server during the sleep.)

I think it should be possible to force the generation of exception wrappers independent of if there are exceptions or not, since, at the moment, adding exceptions to a new methods changes the behavior of other methods.

Thanks,

Hans Ole