Closed dranidis closed 2 years ago
Great to see that you are looking to use RPC with this library. :+1:
RabbitMQ has some non-standard behavior while using a reply-to
header - it creates a temporary exclusive queue and subscribes to it as well (see https://www.rabbitmq.com/stomp.html#d.tqd). This makes an ideal setup for RPC. In this case, since the stomp client did not explicitly subscribe, the messages will be delivered through unhandledMessage$
- this is done by this library not by the broker. This is the preferred working mode when used with RabbitMQ. However, it is not likely to work with Spring (or any other broker for that matter).
In the alternate case, one would need to create and subscribe to a queue that is unique (i.e., no two clients using the same queue name). In this case, the callback needs to subscribe as well. Your code snippet looks correct to me.
I guess you have read the guide at https://stomp-js.github.io/guide/rx-stomp/ng2-stompjs/remote-procedure-call.html
I do not use Spring. For me to help, you would need to enable debug and share the logs. Share the broker logs as well.
Alternatively, since you are familiar with RabiitMQ, you can modify the sample to use an explicit queue and check if it works with RabbitMQ. Once you find it working, you can check the same client code with Spring.
Thanks for the reply.
Unfortunately, I am not very familiar with RabbitMQ. I currently use the SimpleBroker in SPRING and not RabbitMQ. Most probably, the SimpleBroker does not work the way the RabbitMQ documentation describes.
But even the example you have at the documentation at https://stomp-js.github.io/guide/rx-stomp/ng2-stompjs/remote-procedure-call.html :
rxStomp.publish({
destination: replyTo,
body: responseBody,
headers: {'correlation-id': correlationId}
});
will not work with RabbitMQ since according to the documentation of RabbitMQ:
SEND and SUBSCRIBE frames must not contain /temp-queue destinations in the destination header.
Your replyTo destination is: /temp-queue/rpc-replies
Anyway, with the solution that I am using right now, I don't think that I satisfy:
In the alternate case, one would need to create and subscribe to a queue that is unique (i.e., no two clients using the same queue name).
Do you have any other projects in github where the library is at use to look at the code?
I will create a sample using the alternate technique and test it out. The code snippet in the tutorial is not tested by me. Give me a couple of days,
I have published a new sample that uses a custom reply queue with RabbitMQ, it should work with any broker. The server component may need to be modified.
While developing this sample I realized that there was a subtle error in the library code when this mode was used. I have fixed that and added test cases to cover custom reply queue mode. https://github.com/stomp-js/rx-stomp/pull/327.
Please check https://github.com/stomp-js/samples/blob/master/rpc/simple/rx-rpc-explicit-return-dest.html, the https://github.com/stomp-js/samples/blob/master/rpc/ruby-server/simple-server.rb has been updated for the RabbitMQ specific queue name translation.
Hi thanks for the support and sorry for the late answer. Unfortunately, I am quite busy right now in another project. As soon as I find time to come back to this I will check out your suggestions.
I connect to a Java Spring Web-socket app as a WS server. RPC is not working; I am not getting anything at the reply. The default implementation using
unhandledMessage$
is not working. I tried both with the SimpleBroker and the StompBrokerRelay connecting to RabbitMQ with no success.In a previous thread you mentioned that you have many projects in which the
unhandledMessage$
works. Can you please provide an example project using Spring if there is one?I had to change the reply function to:
in order for it to work. Will the specific function that I use for replyQueue cause any issues?
I was actually wondering why haven't you used this approach and you have chosen the
unhandledMessage$
approach.thanks