[rabbitmq-discuss] Implementing an RPC backend

[Matthias Radestock]

Ben,

"Ben Hood" <0x6e6562 at gmail.com> writes:

>> I suspect that in the 1.0.0-alpha client the above results in a
>> deadlock. A thread dump should tell you whether that is the case.
>>
>> One way to get around the deadlock is to let handleDelivery push
>> requests onto a Java queue, and process that from a different
>> thread.
>
> OK, I'll have a look.

This may be a red herring. I think it's only RPCs that should be avoided
inside handleDelivery, and basicPublish isn't an RPC. Also, your tests
seem to indicate that the reply does actually reach the server, and
fails at the routing stage.

> I debugged the route method in rabbit_exchange, which does a mnesia
> lookup of the replyTo routing key:
>
> Handlers = case rabbit_misc:clean_read({binding, BindingKey}) of
> 		   {error, not_found} ->
> 		       handlers_for_missing_binding_record(X, RoutingKey);
> 		   {ok, #binding{handlers = H}} ->
> 		       H
> 	       end,
>
> This returns [], so it seems to be at that point that the message is
> unroutable. I found this last night, so I'll have a look to see what
> the contents of the binding table in mnesia is. I tried initially with
> TV, but it's difficult to see the actual content with that. I'll try
> using the API.

I find mnesia:dump_to_textfile/1 quite useful in debugging this sort of
problem.

>> The next version of the client API has a QueuingConsumer class
>> for that purpose, and is generally less prone to deadlocks.
>
> Is any of this code available in a repository?

No, but the new release will be out soon.


Matthias.