# calling a nameko service from a Java client

**URL:** <https://discourse.nameko.io/t/calling-a-nameko-service-from-a-java-client/242>\
**Category:** googlegroup\
**Created:** [March 2, 2018, 2:53pm UTC](https://discourse.nameko.io/t/calling-a-nameko-service-from-a-java-client/242 "2018-03-02T14:53:55Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![Laurent\_Bois](https://avatars.discourse-cdn.com/v4/letter/l/49beb7/32.png) [@Laurent\_Bois](https://discourse.nameko.io/u/Laurent_Bois)\
**Post date:** [March 2, 2018, 2:53pm UTC](https://discourse.nameko.io/t/calling-a-nameko-service-from-a-java-client/242/1 "2018-03-02T14:53:55Z")

</div>

I have a simple service written with Python using Nameko based on RabbitMQ  
and RPC.

Here is the code of service.py

from nameko.rpc import rpc, RpcProxy  
class Crawler(object):  
&nbsp;&nbsp;&nbsp;&nbsp;name = "crawler"

&nbsp;&nbsp;&nbsp;&nbsp;@rpc  
&nbsp;&nbsp;&nbsp;&nbsp;def scrapit(self):  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;return 'OK'

Then i start it using the command :

nameko run service --broker amqguest:guest@localhost

Finally i have a simple RPCCLient written in Java :

import com.rabbitmq.client.\*;  
import java.io.IOException;import java.util.UUID;import java.util.concurrent.ArrayBlockingQueue;import java.util.concurrent.BlockingQueue;import java.util.concurrent.TimeoutException;  
public class RPCClient {

&nbsp;&nbsp;&nbsp;&nbsp;private Connection connection;  
&nbsp;&nbsp;&nbsp;&nbsp;private Channel channel;  
&nbsp;&nbsp;&nbsp;&nbsp;private String requestQueueName = "rpc-crawler";  
&nbsp;&nbsp;&nbsp;&nbsp;private String replyQueueName;

&nbsp;&nbsp;&nbsp;&nbsp;public RPCClient() throws IOException, TimeoutException {  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ConnectionFactory factory = new ConnectionFactory();  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;factory.setHost("localhost");

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;connection = factory.newConnection();  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;channel = connection.createChannel();

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;replyQueueName = channel.queueDeclare().getQueue();  
&nbsp;&nbsp;&nbsp;&nbsp;}

&nbsp;&nbsp;&nbsp;&nbsp;public String call(String message) throws IOException, InterruptedException {  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;String corrId = UUID.randomUUID().toString();

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;AMQP.BasicProperties props = new AMQP.BasicProperties  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;.Builder()  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;.correlationId(corrId)  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;.replyTo(replyQueueName)  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;.build();

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;channel.basicPublish("", requestQueueName, props, message.getBytes("UTF-8"));

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;final BlockingQueue\<String\> response = new ArrayBlockingQueue\<String\>(1);

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;channel.basicConsume(replyQueueName, true, new DefaultConsumer(channel) {  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;@Override  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;public void handleDelivery(String consumerTag, Envelope envelope, AMQP.BasicProperties properties, byte[] body) throws IOException {  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;if (properties.getCorrelationId().equals(corrId)) {  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;response.offer(new String(body, "UTF-8"));  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;});

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;return response.take();  
&nbsp;&nbsp;&nbsp;&nbsp;}

&nbsp;&nbsp;&nbsp;&nbsp;public void close() throws IOException {  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;connection.close();  
&nbsp;&nbsp;&nbsp;&nbsp;}

&nbsp;&nbsp;&nbsp;&nbsp;//...}

I call

RPCClient client = new RPCClient();  
msg = client.call("crawler.scrapit()");

In my RabbitMQ management i see the message and a ack, but the client is  
blocking and i do not see the returned message "OK"

Any idea Thanks a lot . Laurent

---

<div class="post-metadata">

**Author:** ![mattbennett](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.nameko.io/mattbennett/32/13_2.png) [@mattbennett](https://discourse.nameko.io/u/mattbennett)\
**Post date:** [March 4, 2018, 8:31am UTC](https://discourse.nameko.io/t/calling-a-nameko-service-from-a-java-client/242/2 "2018-03-04T08:31:19Z")

</div>

Does the service receive the request message and fire the entrypoint?

If so, do you see any message published to the RPC reply queue?

Any tracebacks anywhere?

There is a lot of detail on Nameko's AMQP-RPC protocol in  
[Microservice Communication over RPC?! | izmailoff](http://izmailoff.github.io/architecture/rpc-revived/) and  
[Issues · nameko/nameko · GitHub](https://github.com/nameko/nameko/issues/354%5C).

> **···**
>
> On Friday, March 2, 2018 at 2:53:55 PM UTC, lauren...@gmail.com wrote:
> 
> > I have a simple service written with Python using Nameko based on RabbitMQ  
> > and RPC.
> > 
> > Here is the code of service.py
> > 
> > from nameko.rpc import rpc, RpcProxy  
> > class Crawler(object):  
> > &nbsp;&nbsp;&nbsp;&nbsp;name = "crawler"
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;@rpc  
> > &nbsp;&nbsp;&nbsp;&nbsp;def scrapit(self):  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;return 'OK'
> > 
> > Then i start it using the command :
> > 
> > nameko run service --broker amqguest:guest@localhost
> > 
> > Finally i have a simple RPCCLient written in Java :
> > 
> > import com.rabbitmq.client.\*;  
> > import java.io.IOException;import java.util.UUID;import java.util.concurrent.ArrayBlockingQueue;import java.util.concurrent.BlockingQueue;import java.util.concurrent.TimeoutException;  
> > public class RPCClient {
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;private Connection connection;  
> > &nbsp;&nbsp;&nbsp;&nbsp;private Channel channel;  
> > &nbsp;&nbsp;&nbsp;&nbsp;private String requestQueueName = "rpc-crawler";  
> > &nbsp;&nbsp;&nbsp;&nbsp;private String replyQueueName;
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;public RPCClient() throws IOException, TimeoutException {  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ConnectionFactory factory = new ConnectionFactory();  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;factory.setHost("localhost");
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;connection = factory.newConnection();  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;channel = connection.createChannel();
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;replyQueueName = channel.queueDeclare().getQueue();  
> > &nbsp;&nbsp;&nbsp;&nbsp;}
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;public String call(String message) throws IOException, InterruptedException {  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;String corrId = UUID.randomUUID().toString();
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;AMQP.BasicProperties props = new AMQP.BasicProperties  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;.Builder()  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;.correlationId(corrId)  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;.replyTo(replyQueueName)  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;.build();
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;channel.basicPublish("", requestQueueName, props, message.getBytes("UTF-8"));
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;final BlockingQueue\<String\> response = new ArrayBlockingQueue\<String\>(1);
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;channel.basicConsume(replyQueueName, true, new DefaultConsumer(channel) {  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;@Override  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;public void handleDelivery(String consumerTag, Envelope envelope, AMQP.BasicProperties properties, byte body) throws IOException {  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;if (properties.getCorrelationId().equals(corrId)) {  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;response.offer(new String(body, "UTF-8"));  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;});
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;return response.take();  
> > &nbsp;&nbsp;&nbsp;&nbsp;}
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;public void close() throws IOException {  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;connection.close();  
> > &nbsp;&nbsp;&nbsp;&nbsp;}
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;//...}
> > 
> > I call
> > 
> > RPCClient client = new RPCClient();  
> > msg = client.call("crawler.scrapit()");
> > 
> > In my RabbitMQ management i see the message and a ack, but the client is  
> > blocking and i do not see the returned message "OK"
> > 
> > Any idea Thanks a lot . Laurent

---

<div class="post-metadata">

**Author:** ![Laurent\_Bois](https://avatars.discourse-cdn.com/v4/letter/l/49beb7/32.png) [@Laurent\_Bois](https://discourse.nameko.io/u/Laurent_Bois)\
**Post date:** [March 4, 2018, 11:43am UTC](https://discourse.nameko.io/t/calling-a-nameko-service-from-a-java-client/242/3 "2018-03-04T11:43:48Z")

</div>

I only see a ack on the RabbitMQ management page... i see my message sent  
I do not see answer in the reply queue  
I think the entrypoint is hit because there is an ack, but i do not  
understand why the replied message is not sent

---

<div class="post-metadata">

**Author:** ![mattbennett](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.nameko.io/mattbennett/32/13_2.png) [@mattbennett](https://discourse.nameko.io/u/mattbennett)\
**Post date:** [March 4, 2018, 11:48am UTC](https://discourse.nameko.io/t/calling-a-nameko-service-from-a-java-client/242/4 "2018-03-04T11:48:11Z")

</div>

An ack for the request message means that it was received and processed  
without any error, including sending the reply.

The reply message is almost certainly being published but not routed to the  
appropriate reply queue. Looking at your code... is your reply queue bound  
to the RPC exchange? If not, that's your problem.

> **···**
>
> On Sunday, March 4, 2018 at 11:43:49 AM UTC, lauren...@gmail.com wrote:
> 
> > I only see a ack on the RabbitMQ management page... i see my message sent  
> > I do not see answer in the reply queue  
> > I think the entrypoint is hit because there is an ack, but i do not  
> > understand why the replied message is not sent

---

<div class="post-metadata">

**Author:** ![Laurent\_Bois](https://avatars.discourse-cdn.com/v4/letter/l/49beb7/32.png) [@Laurent\_Bois](https://discourse.nameko.io/u/Laurent_Bois)\
**Post date:** [March 4, 2018, 6:25pm UTC](https://discourse.nameko.io/t/calling-a-nameko-service-from-a-java-client/242/5 "2018-03-04T18:25:01Z")

</div>

Yes but in my Java client i manage the replyQueue  
I Use correlationId.  
I started from the Java code in RabbitMQ RPC/Java/CorrelationId  
section [https://github.com/rabbitmq/rabbitmq-tutorials/blob/master/java/RPCClient.java](https://github.com/rabbitmq/rabbitmq-tutorials/blob/master/java/RPCClient.java)

In my RabbitMQ management page i see the message sent from client , the  
Publisher confirm, and the ack now

As you say maybe it's a problem with the reply queue, and error in my client  
Laurent

> **···**
>
> Le dimanche 4 mars 2018 12:48:11 UTC+1, Matt Yule-Bennett a écrit :
> 
> > An ack for the request message means that it was received and processed  
> > without any error, including sending the reply.
> > 
> > The reply message is almost certainly being published but not routed to  
> > the appropriate reply queue. Looking at your code... is your reply queue  
> > bound to the RPC exchange? If not, that's your problem.
> > 
> > On Sunday, March 4, 2018 at 11:43:49 AM UTC, lauren...@gmail.com wrote:
> > 
> > > I only see a ack on the RabbitMQ management page... i see my message sent  
> > > I do not see answer in the reply queue  
> > > I think the entrypoint is hit because there is an ack, but i do not  
> > > understand why the replied message is not sent

---

<div class="post-metadata">

**Author:** ![Laurent\_Bois](https://avatars.discourse-cdn.com/v4/letter/l/49beb7/32.png) [@Laurent\_Bois](https://discourse.nameko.io/u/Laurent_Bois)\
**Post date:** [March 4, 2018, 6:37pm UTC](https://discourse.nameko.io/t/calling-a-nameko-service-from-a-java-client/242/6 "2018-03-04T18:37:01Z")

</div>

The problem is before the correlationId.

In the Java source code that is handleDelivery which blocks

> **···**
>
> Le dimanche 4 mars 2018 19:25:01 UTC+1, lauren...@gmail.com a écrit :
> 
> > Yes but in my Java client i manage the replyQueue  
> > I Use correlationId.  
> > I started from the Java code in RabbitMQ RPC/Java/CorrelationId section  
> > [https://github.com/rabbitmq/rabbitmq-tutorials/blob/master/java/RPCClient.java](https://github.com/rabbitmq/rabbitmq-tutorials/blob/master/java/RPCClient.java)
> > 
> > In my RabbitMQ management page i see the message sent from client , the  
> > Publisher confirm, and the ack now
> > 
> > As you say maybe it's a problem with the reply queue, and error in my  
> > client  
> > Laurent
> > 
> > Le dimanche 4 mars 2018 12:48:11 UTC+1, Matt Yule-Bennett a écrit :
> > 
> > > An ack for the request message means that it was received and processed  
> > > without any error, including sending the reply.
> > > 
> > > The reply message is almost certainly being published but not routed to  
> > > the appropriate reply queue. Looking at your code... is your reply queue  
> > > bound to the RPC exchange? If not, that's your problem.
> > > 
> > > On Sunday, March 4, 2018 at 11:43:49 AM UTC, lauren...@gmail.com wrote:
> > > 
> > > > I only see a ack on the RabbitMQ management page... i see my message sent  
> > > > I do not see answer in the reply queue  
> > > > I think the entrypoint is hit because there is an ack, but i do not  
> > > > understand why the replied message is not sent

---

<div class="post-metadata">

**Author:** ![mattbennett](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.nameko.io/mattbennett/32/13_2.png) [@mattbennett](https://discourse.nameko.io/u/mattbennett)\
**Post date:** [March 4, 2018, 7:57pm UTC](https://discourse.nameko.io/t/calling-a-nameko-service-from-a-java-client/242/7 "2018-03-04T19:57:35Z")

</div>

The RPC reply queue must be bound to the `nameko-rpc` exchange. The reply  
message is published to that exchange with the 'reply\_to' as the routing  
key; if you haven't bound the reply queue to the correct exchange, the  
reply message will be discarded by the broker as not matching any routes.

Correlation ID has nothing to do with routing messages. It's only used to  
match replies up with requests so a client can have multiple requests in  
flight at the same time.

> **···**
>
> On Sunday, March 4, 2018 at 6:37:01 PM UTC, lauren...@gmail.com wrote:
> 
> > The problem is before the correlationId.
> > 
> > In the Java source code that is handleDelivery which blocks
> > 
> > Le dimanche 4 mars 2018 19:25:01 UTC+1, lauren...@gmail.com a écrit :
> > 
> > > Yes but in my Java client i manage the replyQueue  
> > > I Use correlationId.  
> > > I started from the Java code in RabbitMQ RPC/Java/CorrelationId section  
> > > [https://github.com/rabbitmq/rabbitmq-tutorials/blob/master/java/RPCClient.java](https://github.com/rabbitmq/rabbitmq-tutorials/blob/master/java/RPCClient.java)
> > > 
> > > In my RabbitMQ management page i see the message sent from client , the  
> > > Publisher confirm, and the ack now
> > > 
> > > As you say maybe it's a problem with the reply queue, and error in my  
> > > client  
> > > Laurent
> > > 
> > > Le dimanche 4 mars 2018 12:48:11 UTC+1, Matt Yule-Bennett a écrit :
> > > 
> > > > An ack for the request message means that it was received and processed  
> > > > without any error, including sending the reply.
> > > > 
> > > > The reply message is almost certainly being published but not routed to  
> > > > the appropriate reply queue. Looking at your code... is your reply queue  
> > > > bound to the RPC exchange? If not, that's your problem.
> > > > 
> > > > On Sunday, March 4, 2018 at 11:43:49 AM UTC, lauren...@gmail.com wrote:
> > > > 
> > > > > I only see a ack on the RabbitMQ management page... i see my message  
> > > > > sent  
> > > > > I do not see answer in the reply queue  
> > > > > I think the entrypoint is hit because there is an ack, but i do not  
> > > > > understand why the replied message is not sent

---

<div class="post-metadata">

**Author:** ![Laurent\_Bois](https://avatars.discourse-cdn.com/v4/letter/l/49beb7/32.png) [@Laurent\_Bois](https://discourse.nameko.io/u/Laurent_Bois)\
**Post date:** [March 4, 2018, 8:30pm UTC](https://discourse.nameko.io/t/calling-a-nameko-service-from-a-java-client/242/8 "2018-03-04T20:30:22Z")

</div>

Thanks.

In my client, after

channel = connection.createChannel();

replyQueueName = channel.queueDeclare().getQueue();

I've added this line

channel.queueBind( replyQueueName , "nameko-rpc", "reply\_to");

But same results... the client is stil blocking

In fact i retested my scrapit service , in which i've added a log, from a Python nameko client...

from nameko.standalone.rpc import ClusterRpcProxy

CONFIG = {'AMQP\_URI': "amqp://guest:guest@localhost"}

def scrapit():

&nbsp;&nbsp;&nbsp;&nbsp;with ClusterRpcProxy(CONFIG) as rpc:

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;result = rpc.crawler.scrapit()

if \_\_name\_\_ == '\_\_main\_\_':

&nbsp;&nbsp;scrapit()

And i see the message from my consumer in the Terminal Window, all works fine

That's not the case with my Java client\<.

So my consumer would not be hitten.

Are we sure the queue name is 'rpc-\<service\_name\>'?

In my case my service is :

class Crawler(object):

&nbsp;&nbsp;&nbsp;&nbsp;name = "crawler"

&nbsp;&nbsp;&nbsp;&nbsp;@rpc

&nbsp;&nbsp;&nbsp;&nbsp;def scrapit(self):

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;print("Received a request send response")

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;return 'OK'

So the queue would be 'rpc-crawler' right?

Laurent

> **···**
>
> Le dimanche 4 mars 2018 20:57:35 UTC+1, Matt Yule-Bennett a écrit :
> 
> > The RPC reply queue must be bound to the `nameko-rpc` exchange. The reply  
> > message is published to that exchange with the 'reply\_to' as the routing  
> > key; if you haven't bound the reply queue to the correct exchange, the  
> > reply message will be discarded by the broker as not matching any routes.
> > 
> > Correlation ID has nothing to do with routing messages. It's only used to  
> > match replies up with requests so a client can have multiple requests in  
> > flight at the same time.
> > 
> > On Sunday, March 4, 2018 at 6:37:01 PM UTC, lauren...@gmail.com wrote:
> > 
> > > The problem is before the correlationId.
> > > 
> > > In the Java source code that is handleDelivery which blocks
> > > 
> > > Le dimanche 4 mars 2018 19:25:01 UTC+1, lauren...@gmail.com a écrit :
> > > 
> > > > Yes but in my Java client i manage the replyQueue  
> > > > I Use correlationId.  
> > > > I started from the Java code in RabbitMQ RPC/Java/CorrelationId section  
> > > > [https://github.com/rabbitmq/rabbitmq-tutorials/blob/master/java/RPCClient.java](https://github.com/rabbitmq/rabbitmq-tutorials/blob/master/java/RPCClient.java)
> > > > 
> > > > In my RabbitMQ management page i see the message sent from client , the  
> > > > Publisher confirm, and the ack now
> > > > 
> > > > As you say maybe it's a problem with the reply queue, and error in my  
> > > > client  
> > > > Laurent
> > > > 
> > > > Le dimanche 4 mars 2018 12:48:11 UTC+1, Matt Yule-Bennett a écrit :
> > > > 
> > > > > An ack for the request message means that it was received and processed  
> > > > > without any error, including sending the reply.
> > > > > 
> > > > > The reply message is almost certainly being published but not routed to  
> > > > > the appropriate reply queue. Looking at your code... is your reply queue  
> > > > > bound to the RPC exchange? If not, that's your problem.
> > > > > 
> > > > > On Sunday, March 4, 2018 at 11:43:49 AM UTC, lauren...@gmail.com wrote:
> > > > > 
> > > > > > I only see a ack on the RabbitMQ management page... i see my message  
> > > > > > sent  
> > > > > > I do not see answer in the reply queue  
> > > > > > I think the entrypoint is hit because there is an ack, but i do not  
> > > > > > understand why the replied message is not sent

---

<div class="post-metadata">

**Author:** ![mattbennett](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.nameko.io/mattbennett/32/13_2.png) [@mattbennett](https://discourse.nameko.io/u/mattbennett)\
**Post date:** [March 4, 2018, 9:54pm UTC](https://discourse.nameko.io/t/calling-a-nameko-service-from-a-java-client/242/9 "2018-03-04T21:54:05Z")

</div>

> Thanks.
> 
> In my client, after
> 
> channel = connection.createChannel();
> 
> replyQueueName = channel.queueDeclare().getQueue();
> 
> I've added this line
> 
> channel.queueBind( replyQueueName , "nameko-rpc", "reply\_to");

Have you bound your reply queue with the \*literal value\* "reply\_to"? That  
won't work. It needs to be the value that you've specified in the "reply  
to" header in your request message. In your case that's replyQueueName.

> But same results... the client is stil blocking
> 
> \<snip\>
> 
> So the queue would be 'rpc-crawler' right?

That is correct, yes. If it wasn't correct you would not see the request  
message being ack'd by your service.

> **···**
>
> On Sunday, March 4, 2018 at 8:30:23 PM UTC, lauren...@gmail.com wrote:
> 
> > Laurent
> > 
> > Le dimanche 4 mars 2018 20:57:35 UTC+1, Matt Yule-Bennett a écrit :
> > 
> > > The RPC reply queue must be bound to the `nameko-rpc` exchange. The reply  
> > > message is published to that exchange with the 'reply\_to' as the routing  
> > > key; if you haven't bound the reply queue to the correct exchange, the  
> > > reply message will be discarded by the broker as not matching any routes.
> > > 
> > > Correlation ID has nothing to do with routing messages. It's only used to  
> > > match replies up with requests so a client can have multiple requests in  
> > > flight at the same time.
> > > 
> > > On Sunday, March 4, 2018 at 6:37:01 PM UTC, lauren...@gmail.com wrote:
> > > 
> > > > The problem is before the correlationId.
> > > > 
> > > > In the Java source code that is handleDelivery which blocks
> > > > 
> > > > Le dimanche 4 mars 2018 19:25:01 UTC+1, lauren...@gmail.com a écrit :
> > > > 
> > > > > Yes but in my Java client i manage the replyQueue  
> > > > > I Use correlationId.  
> > > > > I started from the Java code in RabbitMQ RPC/Java/CorrelationId section  
> > > > > [https://github.com/rabbitmq/rabbitmq-tutorials/blob/master/java/RPCClient.java](https://github.com/rabbitmq/rabbitmq-tutorials/blob/master/java/RPCClient.java)
> > > > > 
> > > > > In my RabbitMQ management page i see the message sent from client , the  
> > > > > Publisher confirm, and the ack now
> > > > > 
> > > > > As you say maybe it's a problem with the reply queue, and error in my  
> > > > > client  
> > > > > Laurent
> > > > > 
> > > > > Le dimanche 4 mars 2018 12:48:11 UTC+1, Matt Yule-Bennett a écrit :
> > > > > 
> > > > > > An ack for the request message means that it was received and  
> > > > > > processed without any error, including sending the reply.
> > > > > > 
> > > > > > The reply message is almost certainly being published but not routed  
> > > > > > to the appropriate reply queue. Looking at your code... is your reply queue  
> > > > > > bound to the RPC exchange? If not, that's your problem.
> > > > > > 
> > > > > > On Sunday, March 4, 2018 at 11:43:49 AM UTC, lauren...@gmail.com \>\>\>\>\> wrote:
> > > > > > 
> > > > > > > I only see a ack on the RabbitMQ management page... i see my message  
> > > > > > > sent  
> > > > > > > I do not see answer in the reply queue  
> > > > > > > I think the entrypoint is hit because there is an ack, but i do not  
> > > > > > > understand why the replied message is not sent

---

<div class="post-metadata">

**Author:** ![Laurent\_Bois](https://avatars.discourse-cdn.com/v4/letter/l/49beb7/32.png) [@Laurent\_Bois](https://discourse.nameko.io/u/Laurent_Bois)\
**Post date:** [March 5, 2018, 8:27am UTC](https://discourse.nameko.io/t/calling-a-nameko-service-from-a-java-client/242/10 "2018-03-05T08:27:31Z")

</div>

I changed my client code :

First i declare the exchange:

private static final String EXCHANGE\_NAME = "nameko-rpc";

Then after further tries i declare the exchange :

Channel channel = connection.createChannel();

channel.exchangeDeclare(EXCHANGE\_NAME, "topic", true);

Finally i publish my message directly to the exchange and not the requestQueueName ...found the code on RabbitMQ for Publish/Subscribe , section EmitLog client [RabbitMQ tutorial - Publish/Subscribe — RabbitMQ](https://www.rabbitmq.com/tutorials/tutorial-three-java.html)

channel.basicPublish(EXCHANGE\_NAME, "", props, message.getBytes());

The message is a string to the nameko service.methode\_name as it : crawler.scrapit()

I see the message in the RabbitMQ console management, no more the ack .

I have a log in my nameko service but nothing prints in the Terminal... as if the service is not hit

> **···**
>
> Le dimanche 4 mars 2018 22:54:06 UTC+1, Matt Yule-Bennett a écrit :
> 
> > On Sunday, March 4, 2018 at 8:30:23 PM UTC, lauren...@gmail.com wrote:
> > 
> > > Thanks.
> > > 
> > > In my client, after
> > > 
> > > channel = connection.createChannel();
> > > 
> > > replyQueueName = channel.queueDeclare().getQueue();
> > > 
> > > I've added this line
> > > 
> > > channel.queueBind( replyQueueName , "nameko-rpc", "reply\_to");
> > 
> > Have you bound your reply queue with the \*literal value\* "reply\_to"? That  
> > won't work. It needs to be the value that you've specified in the "reply  
> > to" header in your request message. In your case that's replyQueueName.
> > 
> > > But same results... the client is stil blocking
> > > 
> > > \<snip\>
> > > 
> > > So the queue would be 'rpc-crawler' right?
> > 
> > That is correct, yes. If it wasn't correct you would not see the request  
> > message being ack'd by your service.
> > 
> > > Laurent
> > > 
> > > Le dimanche 4 mars 2018 20:57:35 UTC+1, Matt Yule-Bennett a écrit :
> > > 
> > > > The RPC reply queue must be bound to the `nameko-rpc` exchange. The  
> > > > reply message is published to that exchange with the 'reply\_to' as the  
> > > > routing key; if you haven't bound the reply queue to the correct exchange,  
> > > > the reply message will be discarded by the broker as not matching any  
> > > > routes.
> > > > 
> > > > Correlation ID has nothing to do with routing messages. It's only used  
> > > > to match replies up with requests so a client can have multiple requests in  
> > > > flight at the same time.
> > > > 
> > > > On Sunday, March 4, 2018 at 6:37:01 PM UTC, lauren...@gmail.com wrote:
> > > > 
> > > > > The problem is before the correlationId.
> > > > > 
> > > > > In the Java source code that is handleDelivery which blocks
> > > > > 
> > > > > Le dimanche 4 mars 2018 19:25:01 UTC+1, lauren...@gmail.com a écrit :
> > > > > 
> > > > > > Yes but in my Java client i manage the replyQueue  
> > > > > > I Use correlationId.  
> > > > > > I started from the Java code in RabbitMQ RPC/Java/CorrelationId  
> > > > > > section  
> > > > > > [https://github.com/rabbitmq/rabbitmq-tutorials/blob/master/java/RPCClient.java](https://github.com/rabbitmq/rabbitmq-tutorials/blob/master/java/RPCClient.java)
> > > > > > 
> > > > > > In my RabbitMQ management page i see the message sent from client ,  
> > > > > > the Publisher confirm, and the ack now
> > > > > > 
> > > > > > As you say maybe it's a problem with the reply queue, and error in my  
> > > > > > client  
> > > > > > Laurent
> > > > > > 
> > > > > > Le dimanche 4 mars 2018 12:48:11 UTC+1, Matt Yule-Bennett a écrit :
> > > > > > 
> > > > > > > An ack for the request message means that it was received and  
> > > > > > > processed without any error, including sending the reply.
> > > > > > > 
> > > > > > > The reply message is almost certainly being published but not routed  
> > > > > > > to the appropriate reply queue. Looking at your code... is your reply queue  
> > > > > > > bound to the RPC exchange? If not, that's your problem.
> > > > > > > 
> > > > > > > On Sunday, March 4, 2018 at 11:43:49 AM UTC, lauren...@gmail.com \>\>\>\>\>\> wrote:
> > > > > > > 
> > > > > > > > I only see a ack on the RabbitMQ management page... i see my message  
> > > > > > > > sent  
> > > > > > > > I do not see answer in the reply queue  
> > > > > > > > I think the entrypoint is hit because there is an ack, but i do not  
> > > > > > > > understand why the replied message is not sent

---

<div class="post-metadata">

**Author:** ![mattbennett](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.nameko.io/mattbennett/32/13_2.png) [@mattbennett](https://discourse.nameko.io/u/mattbennett)\
**Post date:** [March 12, 2018, 9:41am UTC](https://discourse.nameko.io/t/calling-a-nameko-service-from-a-java-client/242/11 "2018-03-12T09:41:31Z")

</div>

I took a closer look at this and found more problems. I don't have a  
complete copy of your client so let me just explain in English how the RPC  
flow works.

\* The listening service will have declared the "nameko-rpc" exchange, and a  
queue called "rpc-\<service-name\>", bound to it with the routing key  
"\<service-name\>.\*" (it's a topic exchange)  
\* You must declare an RPC reply queue. The queue name can be anything but  
the nameko Python client names them "rpc.reply-\<service-name\>-\<uuid\>". It  
must be bound to the "nameko-rpc" exchange with a unique name; the Python  
client uses a uuid.  
\* To make a call, you publish a message to the "nameko-rpc" exchange, with  
"\<service-name\>.\<method-name\>" as the routing key. The payload must be a  
serialised dict containing the key "args" and "kwargs", with the values  
being the parameters for the method call. You must specify a "reply\_to"  
header with the routing key you've used to bind the reply queue to the RPC  
exchange. You should also specify a "correlation\_id" header so your client  
can issue multiple concurrent requests and match the replies back up again.  
You also need to specify content-type and encoding headers so the service  
knows how to deserialize the incoming data. By default the listening  
service will be expecting JSON.  
\* The request message will be routed to the listening service's queue,  
consumed, processed and ack'd. The service will then reply by publishing to  
the RPC exchange using the "reply\_to" as the routing key and including the  
"correlation\_id header from the request message.  
\* The response message will be routed to the reply queue. Your client  
should consume it and use the correlation id to match it up with a pending  
request.

Looking at your first post, the client is not publishing the request  
message correctly. It's sending it directly to the service queue via the  
default exchange, without the correct routing key. Your service is probably  
consuming the message and replying with a MethodNotFound message, which was  
being lost because your reply queue wasn't bound correctly either. Your  
payload also isn't correct in the first version. It should be (assuming  
JSON serialization) '{"args": , "kwargs": }'

> **···**
>
> On Monday, March 5, 2018 at 8:27:32 AM UTC, lauren...@gmail.com wrote:
> 
> > I changed my client code :
> > 
> > First i declare the exchange:
> > 
> > private static final String EXCHANGE\_NAME = "nameko-rpc";
> > 
> > Then after further tries i declare the exchange :
> > 
> > Channel channel = connection.createChannel();
> > 
> > channel.exchangeDeclare(EXCHANGE\_NAME, "topic", true);
> > 
> > Finally i publish my message directly to the exchange and not the requestQueueName ...found the code on RabbitMQ for Publish/Subscribe , section EmitLog client [RabbitMQ tutorial - Publish/Subscribe — RabbitMQ](https://www.rabbitmq.com/tutorials/tutorial-three-java.html)
> > 
> > channel.basicPublish(EXCHANGE\_NAME, "", props, message.getBytes());
> > 
> > The message is a string to the nameko service.methode\_name as it : crawler.scrapit()
> > 
> > I see the message in the RabbitMQ console management, no more the ack .
> > 
> > I have a log in my nameko service but nothing prints in the Terminal... as if the service is not hit
> > 
> > Le dimanche 4 mars 2018 22:54:06 UTC+1, Matt Yule-Bennett a écrit :
> > 
> > > On Sunday, March 4, 2018 at 8:30:23 PM UTC, lauren...@gmail.com wrote:
> > > 
> > > > Thanks.
> > > > 
> > > > In my client, after
> > > > 
> > > > channel = connection.createChannel();
> > > > 
> > > > replyQueueName = channel.queueDeclare().getQueue();
> > > > 
> > > > I've added this line
> > > > 
> > > > channel.queueBind( replyQueueName , "nameko-rpc", "reply\_to");
> > > 
> > > Have you bound your reply queue with the \*literal value\* "reply\_to"?  
> > > That won't work. It needs to be the value that you've specified in the  
> > > "reply to" header in your request message. In your case that's  
> > > replyQueueName.
> > > 
> > > > But same results... the client is stil blocking
> > > > 
> > > > \<snip\>
> > > > 
> > > > So the queue would be 'rpc-crawler' right?
> > > 
> > > That is correct, yes. If it wasn't correct you would not see the request  
> > > message being ack'd by your service.
> > > 
> > > > Laurent
> > > > 
> > > > Le dimanche 4 mars 2018 20:57:35 UTC+1, Matt Yule-Bennett a écrit :
> > > > 
> > > > > The RPC reply queue must be bound to the `nameko-rpc` exchange. The  
> > > > > reply message is published to that exchange with the 'reply\_to' as the  
> > > > > routing key; if you haven't bound the reply queue to the correct exchange,  
> > > > > the reply message will be discarded by the broker as not matching any  
> > > > > routes.
> > > > > 
> > > > > Correlation ID has nothing to do with routing messages. It's only used  
> > > > > to match replies up with requests so a client can have multiple requests in  
> > > > > flight at the same time.
> > > > > 
> > > > > On Sunday, March 4, 2018 at 6:37:01 PM UTC, lauren...@gmail.com wrote:
> > > > > 
> > > > > > The problem is before the correlationId.
> > > > > > 
> > > > > > In the Java source code that is handleDelivery which blocks
> > > > > > 
> > > > > > Le dimanche 4 mars 2018 19:25:01 UTC+1, lauren...@gmail.com a écrit :
> > > > > > 
> > > > > > > Yes but in my Java client i manage the replyQueue  
> > > > > > > I Use correlationId.  
> > > > > > > I started from the Java code in RabbitMQ RPC/Java/CorrelationId  
> > > > > > > section  
> > > > > > > [https://github.com/rabbitmq/rabbitmq-tutorials/blob/master/java/RPCClient.java](https://github.com/rabbitmq/rabbitmq-tutorials/blob/master/java/RPCClient.java)
> > > > > > > 
> > > > > > > In my RabbitMQ management page i see the message sent from client ,  
> > > > > > > the Publisher confirm, and the ack now
> > > > > > > 
> > > > > > > As you say maybe it's a problem with the reply queue, and error in my  
> > > > > > > client  
> > > > > > > Laurent
> > > > > > > 
> > > > > > > Le dimanche 4 mars 2018 12:48:11 UTC+1, Matt Yule-Bennett a écrit :
> > > > > > > 
> > > > > > > > An ack for the request message means that it was received and  
> > > > > > > > processed without any error, including sending the reply.
> > > > > > > > 
> > > > > > > > The reply message is almost certainly being published but not routed  
> > > > > > > > to the appropriate reply queue. Looking at your code... is your reply queue  
> > > > > > > > bound to the RPC exchange? If not, that's your problem.
> > > > > > > > 
> > > > > > > > On Sunday, March 4, 2018 at 11:43:49 AM UTC, lauren...@gmail.com \>\>\>\>\>\>\> wrote:
> > > > > > > > 
> > > > > > > > > I only see a ack on the RabbitMQ management page... i see my  
> > > > > > > > > message sent  
> > > > > > > > > I do not see answer in the reply queue  
> > > > > > > > > I think the entrypoint is hit because there is an ack, but i do  
> > > > > > > > > not understand why the replied message is not sent

---

<div class="post-metadata">

**Author:** ![Laurent\_Bois](https://avatars.discourse-cdn.com/v4/letter/l/49beb7/32.png) [@Laurent\_Bois](https://discourse.nameko.io/u/Laurent_Bois)\
**Post date:** [March 13, 2018, 3:30pm UTC](https://discourse.nameko.io/t/calling-a-nameko-service-from-a-java-client/242/12 "2018-03-13T15:30:23Z")

</div>

Thanks for this great explanation

I think the problem can come from the serialization of the payload in Java.  
In my code i just do a byte conversion from string (service.method)

In my last tries i sent the payload to the echange, with a reply queue (bit  
not named as you say)

I'm going to try what you wrote and come back

Thanks

> **···**
>
> Le lundi 12 mars 2018 10:41:31 UTC+1, Matt Yule-Bennett a écrit :
> 
> > I took a closer look at this and found more problems. I don't have a  
> > complete copy of your client so let me just explain in English how the RPC  
> > flow works.
> > 
> > \* The listening service will have declared the "nameko-rpc" exchange, and  
> > a queue called "rpc-\<service-name\>", bound to it with the routing key  
> > "\<service-name\>.\*" (it's a topic exchange)  
> > \* You must declare an RPC reply queue. The queue name can be anything but  
> > the nameko Python client names them "rpc.reply-\<service-name\>-\<uuid\>". It  
> > must be bound to the "nameko-rpc" exchange with a unique name; the Python  
> > client uses a uuid.  
> > \* To make a call, you publish a message to the "nameko-rpc" exchange, with  
> > "\<service-name\>.\<method-name\>" as the routing key. The payload must be a  
> > serialised dict containing the key "args" and "kwargs", with the values  
> > being the parameters for the method call. You must specify a "reply\_to"  
> > header with the routing key you've used to bind the reply queue to the RPC  
> > exchange. You should also specify a "correlation\_id" header so your client  
> > can issue multiple concurrent requests and match the replies back up again.  
> > You also need to specify content-type and encoding headers so the service  
> > knows how to deserialize the incoming data. By default the listening  
> > service will be expecting JSON.  
> > \* The request message will be routed to the listening service's queue,  
> > consumed, processed and ack'd. The service will then reply by publishing to  
> > the RPC exchange using the "reply\_to" as the routing key and including the  
> > "correlation\_id header from the request message.  
> > \* The response message will be routed to the reply queue. Your client  
> > should consume it and use the correlation id to match it up with a pending  
> > request.
> > 
> > Looking at your first post, the client is not publishing the request  
> > message correctly. It's sending it directly to the service queue via the  
> > default exchange, without the correct routing key. Your service is probably  
> > consuming the message and replying with a MethodNotFound message, which was  
> > being lost because your reply queue wasn't bound correctly either. Your  
> > payload also isn't correct in the first version. It should be (assuming  
> > JSON serialization) '{"args": , "kwargs": }'
> > 
> > On Monday, March 5, 2018 at 8:27:32 AM UTC, lauren...@gmail.com wrote:
> > 
> > > I changed my client code :
> > > 
> > > First i declare the exchange:
> > > 
> > > private static final String EXCHANGE\_NAME = "nameko-rpc";
> > > 
> > > Then after further tries i declare the exchange :
> > > 
> > > Channel channel = connection.createChannel();
> > > 
> > > channel.exchangeDeclare(EXCHANGE\_NAME, "topic", true);
> > > 
> > > Finally i publish my message directly to the exchange and not the requestQueueName ...found the code on RabbitMQ for Publish/Subscribe , section EmitLog client [RabbitMQ tutorial - Publish/Subscribe — RabbitMQ](https://www.rabbitmq.com/tutorials/tutorial-three-java.html)
> > > 
> > > channel.basicPublish(EXCHANGE\_NAME, "", props, message.getBytes());
> > > 
> > > The message is a string to the nameko service.methode\_name as it : crawler.scrapit()
> > > 
> > > I see the message in the RabbitMQ console management, no more the ack .
> > > 
> > > I have a log in my nameko service but nothing prints in the Terminal... as if the service is not hit
> > > 
> > > Le dimanche 4 mars 2018 22:54:06 UTC+1, Matt Yule-Bennett a écrit :
> > > 
> > > > On Sunday, March 4, 2018 at 8:30:23 PM UTC, lauren...@gmail.com wrote:
> > > > 
> > > > > Thanks.
> > > > > 
> > > > > In my client, after
> > > > > 
> > > > > channel = connection.createChannel();
> > > > > 
> > > > > replyQueueName = channel.queueDeclare().getQueue();
> > > > > 
> > > > > I've added this line
> > > > > 
> > > > > channel.queueBind( replyQueueName , "nameko-rpc", "reply\_to");
> > > > 
> > > > Have you bound your reply queue with the \*literal value\* "reply\_to"?  
> > > > That won't work. It needs to be the value that you've specified in the  
> > > > "reply to" header in your request message. In your case that's  
> > > > replyQueueName.
> > > > 
> > > > > But same results... the client is stil blocking
> > > > > 
> > > > > \<snip\>
> > > > > 
> > > > > So the queue would be 'rpc-crawler' right?
> > > > 
> > > > That is correct, yes. If it wasn't correct you would not see the request  
> > > > message being ack'd by your service.
> > > > 
> > > > > Laurent
> > > > > 
> > > > > Le dimanche 4 mars 2018 20:57:35 UTC+1, Matt Yule-Bennett a écrit :
> > > > > 
> > > > > > The RPC reply queue must be bound to the `nameko-rpc` exchange. The  
> > > > > > reply message is published to that exchange with the 'reply\_to' as the  
> > > > > > routing key; if you haven't bound the reply queue to the correct exchange,  
> > > > > > the reply message will be discarded by the broker as not matching any  
> > > > > > routes.
> > > > > > 
> > > > > > Correlation ID has nothing to do with routing messages. It's only used  
> > > > > > to match replies up with requests so a client can have multiple requests in  
> > > > > > flight at the same time.
> > > > > > 
> > > > > > On Sunday, March 4, 2018 at 6:37:01 PM UTC, lauren...@gmail.com wrote:
> > > > > > 
> > > > > > > The problem is before the correlationId.
> > > > > > > 
> > > > > > > In the Java source code that is handleDelivery which blocks
> > > > > > > 
> > > > > > > Le dimanche 4 mars 2018 19:25:01 UTC+1, lauren...@gmail.com a écrit :
> > > > > > > 
> > > > > > > > Yes but in my Java client i manage the replyQueue  
> > > > > > > > I Use correlationId.  
> > > > > > > > I started from the Java code in RabbitMQ RPC/Java/CorrelationId  
> > > > > > > > section  
> > > > > > > > [https://github.com/rabbitmq/rabbitmq-tutorials/blob/master/java/RPCClient.java](https://github.com/rabbitmq/rabbitmq-tutorials/blob/master/java/RPCClient.java)
> > > > > > > > 
> > > > > > > > In my RabbitMQ management page i see the message sent from client ,  
> > > > > > > > the Publisher confirm, and the ack now
> > > > > > > > 
> > > > > > > > As you say maybe it's a problem with the reply queue, and error in  
> > > > > > > > my client  
> > > > > > > > Laurent
> > > > > > > > 
> > > > > > > > Le dimanche 4 mars 2018 12:48:11 UTC+1, Matt Yule-Bennett a écrit :
> > > > > > > > 
> > > > > > > > > An ack for the request message means that it was received and  
> > > > > > > > > processed without any error, including sending the reply.
> > > > > > > > > 
> > > > > > > > > The reply message is almost certainly being published but not  
> > > > > > > > > routed to the appropriate reply queue. Looking at your code... is your  
> > > > > > > > > reply queue bound to the RPC exchange? If not, that's your problem.
> > > > > > > > > 
> > > > > > > > > On Sunday, March 4, 2018 at 11:43:49 AM UTC, lauren...@gmail.com \>\>\>\>\>\>\>\> wrote:
> > > > > > > > > 
> > > > > > > > > > I only see a ack on the RabbitMQ management page... i see my  
> > > > > > > > > > message sent  
> > > > > > > > > > I do not see answer in the reply queue  
> > > > > > > > > > I think the entrypoint is hit because there is an ack, but i do  
> > > > > > > > > > not understand why the replied message is not sent

---

<div class="post-metadata">

**Author:** ![Laurent\_Bois](https://avatars.discourse-cdn.com/v4/letter/l/49beb7/32.png) [@Laurent\_Bois](https://discourse.nameko.io/u/Laurent_Bois)\
**Post date:** [March 13, 2018, 3:30pm UTC](https://discourse.nameko.io/t/calling-a-nameko-service-from-a-java-client/242/13 "2018-03-13T15:30:45Z")

</div>

Hi folks

How can you translate a payload : service-name-method\_name in JSON with  
{args: , kwargs: } notation?

Thanks

Laurent

> **···**
>
> Le mardi 13 mars 2018 16:30:23 UTC+1, lauren...@gmail.com a écrit :
> 
> > Thanks for this great explanation
> > 
> > I think the problem can come from the serialization of the payload in  
> > Java. In my code i just do a byte conversion from string (service.method)
> > 
> > In my last tries i sent the payload to the echange, with a reply queue  
> > (bit not named as you say)
> > 
> > I'm going to try what you wrote and come back
> > 
> > Thanks
> > 
> > Le lundi 12 mars 2018 10:41:31 UTC+1, Matt Yule-Bennett a écrit :
> > 
> > > I took a closer look at this and found more problems. I don't have a  
> > > complete copy of your client so let me just explain in English how the RPC  
> > > flow works.
> > > 
> > > \* The listening service will have declared the "nameko-rpc" exchange, and  
> > > a queue called "rpc-\<service-name\>", bound to it with the routing key  
> > > "\<service-name\>.\*" (it's a topic exchange)  
> > > \* You must declare an RPC reply queue. The queue name can be anything but  
> > > the nameko Python client names them "rpc.reply-\<service-name\>-\<uuid\>". It  
> > > must be bound to the "nameko-rpc" exchange with a unique name; the Python  
> > > client uses a uuid.  
> > > \* To make a call, you publish a message to the "nameko-rpc" exchange,  
> > > with "\<service-name\>.\<method-name\>" as the routing key. The payload must be  
> > > a serialised dict containing the key "args" and "kwargs", with the values  
> > > being the parameters for the method call. You must specify a "reply\_to"  
> > > header with the routing key you've used to bind the reply queue to the RPC  
> > > exchange. You should also specify a "correlation\_id" header so your client  
> > > can issue multiple concurrent requests and match the replies back up again.  
> > > You also need to specify content-type and encoding headers so the service  
> > > knows how to deserialize the incoming data. By default the listening  
> > > service will be expecting JSON.  
> > > \* The request message will be routed to the listening service's queue,  
> > > consumed, processed and ack'd. The service will then reply by publishing to  
> > > the RPC exchange using the "reply\_to" as the routing key and including the  
> > > "correlation\_id header from the request message.  
> > > \* The response message will be routed to the reply queue. Your client  
> > > should consume it and use the correlation id to match it up with a pending  
> > > request.
> > > 
> > > Looking at your first post, the client is not publishing the request  
> > > message correctly. It's sending it directly to the service queue via the  
> > > default exchange, without the correct routing key. Your service is probably  
> > > consuming the message and replying with a MethodNotFound message, which was  
> > > being lost because your reply queue wasn't bound correctly either. Your  
> > > payload also isn't correct in the first version. It should be (assuming  
> > > JSON serialization) '{"args": , "kwargs": }'
> > > 
> > > On Monday, March 5, 2018 at 8:27:32 AM UTC, lauren...@gmail.com wrote:
> > > 
> > > > I changed my client code :
> > > > 
> > > > First i declare the exchange:
> > > > 
> > > > private static final String EXCHANGE\_NAME = "nameko-rpc";
> > > > 
> > > > Then after further tries i declare the exchange :
> > > > 
> > > > Channel channel = connection.createChannel();
> > > > 
> > > > channel.exchangeDeclare(EXCHANGE\_NAME, "topic", true);
> > > > 
> > > > Finally i publish my message directly to the exchange and not the requestQueueName ...found the code on RabbitMQ for Publish/Subscribe , section EmitLog client [RabbitMQ tutorial - Publish/Subscribe — RabbitMQ](https://www.rabbitmq.com/tutorials/tutorial-three-java.html)
> > > > 
> > > > channel.basicPublish(EXCHANGE\_NAME, "", props, message.getBytes());
> > > > 
> > > > The message is a string to the nameko service.methode\_name as it : crawler.scrapit()
> > > > 
> > > > I see the message in the RabbitMQ console management, no more the ack .
> > > > 
> > > > I have a log in my nameko service but nothing prints in the Terminal... as if the service is not hit
> > > > 
> > > > Le dimanche 4 mars 2018 22:54:06 UTC+1, Matt Yule-Bennett a écrit :
> > > > 
> > > > > On Sunday, March 4, 2018 at 8:30:23 PM UTC, lauren...@gmail.com wrote:
> > > > > 
> > > > > > Thanks.
> > > > > > 
> > > > > > In my client, after
> > > > > > 
> > > > > > channel = connection.createChannel();
> > > > > > 
> > > > > > replyQueueName = channel.queueDeclare().getQueue();
> > > > > > 
> > > > > > I've added this line
> > > > > > 
> > > > > > channel.queueBind( replyQueueName , "nameko-rpc", "reply\_to");
> > > > > 
> > > > > Have you bound your reply queue with the \*literal value\* "reply\_to"?  
> > > > > That won't work. It needs to be the value that you've specified in the  
> > > > > "reply to" header in your request message. In your case that's  
> > > > > replyQueueName.
> > > > > 
> > > > > > But same results... the client is stil blocking
> > > > > > 
> > > > > > \<snip\>
> > > > > > 
> > > > > > So the queue would be 'rpc-crawler' right?
> > > > > 
> > > > > That is correct, yes. If it wasn't correct you would not see the  
> > > > > request message being ack'd by your service.
> > > > > 
> > > > > > Laurent
> > > > > > 
> > > > > > Le dimanche 4 mars 2018 20:57:35 UTC+1, Matt Yule-Bennett a écrit :
> > > > > > 
> > > > > > > The RPC reply queue must be bound to the `nameko-rpc` exchange. The  
> > > > > > > reply message is published to that exchange with the 'reply\_to' as the  
> > > > > > > routing key; if you haven't bound the reply queue to the correct exchange,  
> > > > > > > the reply message will be discarded by the broker as not matching any  
> > > > > > > routes.
> > > > > > > 
> > > > > > > Correlation ID has nothing to do with routing messages. It's only  
> > > > > > > used to match replies up with requests so a client can have multiple  
> > > > > > > requests in flight at the same time.
> > > > > > > 
> > > > > > > On Sunday, March 4, 2018 at 6:37:01 PM UTC, lauren...@gmail.com \>\>\>\>\>\> wrote:
> > > > > > > 
> > > > > > > > The problem is before the correlationId.
> > > > > > > > 
> > > > > > > > In the Java source code that is handleDelivery which blocks
> > > > > > > > 
> > > > > > > > Le dimanche 4 mars 2018 19:25:01 UTC+1, lauren...@gmail.com a  
> > > > > > > > écrit :
> > > > > > > > 
> > > > > > > > > Yes but in my Java client i manage the replyQueue  
> > > > > > > > > I Use correlationId.  
> > > > > > > > > I started from the Java code in RabbitMQ RPC/Java/CorrelationId  
> > > > > > > > > section  
> > > > > > > > > [https://github.com/rabbitmq/rabbitmq-tutorials/blob/master/java/RPCClient.java](https://github.com/rabbitmq/rabbitmq-tutorials/blob/master/java/RPCClient.java)
> > > > > > > > > 
> > > > > > > > > In my RabbitMQ management page i see the message sent from client ,  
> > > > > > > > > the Publisher confirm, and the ack now
> > > > > > > > > 
> > > > > > > > > As you say maybe it's a problem with the reply queue, and error in  
> > > > > > > > > my client  
> > > > > > > > > Laurent
> > > > > > > > > 
> > > > > > > > > Le dimanche 4 mars 2018 12:48:11 UTC+1, Matt Yule-Bennett a écrit :
> > > > > > > > > 
> > > > > > > > > > An ack for the request message means that it was received and  
> > > > > > > > > > processed without any error, including sending the reply.
> > > > > > > > > > 
> > > > > > > > > > The reply message is almost certainly being published but not  
> > > > > > > > > > routed to the appropriate reply queue. Looking at your code... is your  
> > > > > > > > > > reply queue bound to the RPC exchange? If not, that's your problem.
> > > > > > > > > > 
> > > > > > > > > > On Sunday, March 4, 2018 at 11:43:49 AM UTC, lauren...@gmail.com \>\>\>\>\>\>\>\>\> wrote:
> > > > > > > > > > 
> > > > > > > > > > > I only see a ack on the RabbitMQ management page... i see my  
> > > > > > > > > > > message sent  
> > > > > > > > > > > I do not see answer in the reply queue  
> > > > > > > > > > > I think the entrypoint is hit because there is an ack, but i do  
> > > > > > > > > > > not understand why the replied message is not sent

---

<div class="post-metadata">

**Author:** ![Laurent\_Bois](https://avatars.discourse-cdn.com/v4/letter/l/49beb7/32.png) [@Laurent\_Bois](https://discourse.nameko.io/u/Laurent_Bois)\
**Post date:** [March 13, 2018, 3:31pm UTC](https://discourse.nameko.io/t/calling-a-nameko-service-from-a-java-client/242/14 "2018-03-13T15:31:33Z")

</div>

Here my Nameko Java client : the sent message is "\<service name\>.\<method

> " but should be json (args kwargs) formatted.

private static final String EXCHANGE\_NAME = "nameko-rpc";  
private String replyQueueName ;  
private String requestQueueName = "rpc-crawler";

...

try {  
&nbsp;&nbsp;&nbsp;&nbsp;ConnectionFactory factory = new ConnectionFactory();  
&nbsp;&nbsp;&nbsp;&nbsp;factory.setHost("localhost");  
&nbsp;&nbsp;&nbsp;&nbsp;Connection connection = factory.newConnection();  
&nbsp;&nbsp;&nbsp;&nbsp;Channel channel = connection.createChannel();

&nbsp;&nbsp;&nbsp;&nbsp;channel.exchangeDeclare(EXCHANGE\_NAME, "topic", true);

&nbsp;&nbsp;&nbsp;&nbsp;String corrId = UUID.randomUUID().toString();  
&nbsp;&nbsp;&nbsp;&nbsp;replyQueueName = "rpc.reply-crawler-" + corrId;

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;AMQP.BasicProperties props = new AMQP.BasicProperties  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;.Builder()  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;.correlationId(corrId)  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;.replyTo(replyQueueName)  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;.build();

&nbsp;&nbsp;&nbsp;&nbsp;channel.basicPublish( EXCHANGE\_NAME, "", props, message.getBytes("UTF-8"));  
&nbsp;&nbsp;&nbsp;&nbsp;System.out.println(" Sent '" + message + "'");

&nbsp;&nbsp;&nbsp;&nbsp;channel.close();  
&nbsp;&nbsp;&nbsp;&nbsp;connection.close();  
} catch (TimeoutException ioe) {  
&nbsp;&nbsp;&nbsp;&nbsp;System.err.println(ioe.getMessage());  
}

> **···**
>
> Le mardi 13 mars 2018 16:30:23 UTC+1, lauren...@gmail.com a écrit :
> 
> > Thanks for this great explanation
> > 
> > I think the problem can come from the serialization of the payload in  
> > Java. In my code i just do a byte conversion from string (service.method)
> > 
> > In my last tries i sent the payload to the echange, with a reply queue  
> > (bit not named as you say)
> > 
> > I'm going to try what you wrote and come back
> > 
> > Thanks
> > 
> > Le lundi 12 mars 2018 10:41:31 UTC+1, Matt Yule-Bennett a écrit :
> > 
> > > I took a closer look at this and found more problems. I don't have a  
> > > complete copy of your client so let me just explain in English how the RPC  
> > > flow works.
> > > 
> > > \* The listening service will have declared the "nameko-rpc" exchange, and  
> > > a queue called "rpc-\<service-name\>", bound to it with the routing key  
> > > "\<service-name\>.\*" (it's a topic exchange)  
> > > \* You must declare an RPC reply queue. The queue name can be anything but  
> > > the nameko Python client names them "rpc.reply-\<service-name\>-\<uuid\>". It  
> > > must be bound to the "nameko-rpc" exchange with a unique name; the Python  
> > > client uses a uuid.  
> > > \* To make a call, you publish a message to the "nameko-rpc" exchange,  
> > > with "\<service-name\>.\<method-name\>" as the routing key. The payload must be  
> > > a serialised dict containing the key "args" and "kwargs", with the values  
> > > being the parameters for the method call. You must specify a "reply\_to"  
> > > header with the routing key you've used to bind the reply queue to the RPC  
> > > exchange. You should also specify a "correlation\_id" header so your client  
> > > can issue multiple concurrent requests and match the replies back up again.  
> > > You also need to specify content-type and encoding headers so the service  
> > > knows how to deserialize the incoming data. By default the listening  
> > > service will be expecting JSON.  
> > > \* The request message will be routed to the listening service's queue,  
> > > consumed, processed and ack'd. The service will then reply by publishing to  
> > > the RPC exchange using the "reply\_to" as the routing key and including the  
> > > "correlation\_id header from the request message.  
> > > \* The response message will be routed to the reply queue. Your client  
> > > should consume it and use the correlation id to match it up with a pending  
> > > request.
> > > 
> > > Looking at your first post, the client is not publishing the request  
> > > message correctly. It's sending it directly to the service queue via the  
> > > default exchange, without the correct routing key. Your service is probably  
> > > consuming the message and replying with a MethodNotFound message, which was  
> > > being lost because your reply queue wasn't bound correctly either. Your  
> > > payload also isn't correct in the first version. It should be (assuming  
> > > JSON serialization) '{"args": , "kwargs": }'
> > > 
> > > On Monday, March 5, 2018 at 8:27:32 AM UTC, lauren...@gmail.com wrote:
> > > 
> > > > I changed my client code :
> > > > 
> > > > First i declare the exchange:
> > > > 
> > > > private static final String EXCHANGE\_NAME = "nameko-rpc";
> > > > 
> > > > Then after further tries i declare the exchange :
> > > > 
> > > > Channel channel = connection.createChannel();
> > > > 
> > > > channel.exchangeDeclare(EXCHANGE\_NAME, "topic", true);
> > > > 
> > > > Finally i publish my message directly to the exchange and not the requestQueueName ...found the code on RabbitMQ for Publish/Subscribe , section EmitLog client [RabbitMQ tutorial - Publish/Subscribe — RabbitMQ](https://www.rabbitmq.com/tutorials/tutorial-three-java.html)
> > > > 
> > > > channel.basicPublish(EXCHANGE\_NAME, "", props, message.getBytes());
> > > > 
> > > > The message is a string to the nameko service.methode\_name as it : crawler.scrapit()
> > > > 
> > > > I see the message in the RabbitMQ console management, no more the ack .
> > > > 
> > > > I have a log in my nameko service but nothing prints in the Terminal... as if the service is not hit
> > > > 
> > > > Le dimanche 4 mars 2018 22:54:06 UTC+1, Matt Yule-Bennett a écrit :
> > > > 
> > > > > On Sunday, March 4, 2018 at 8:30:23 PM UTC, lauren...@gmail.com wrote:
> > > > > 
> > > > > > Thanks.
> > > > > > 
> > > > > > In my client, after
> > > > > > 
> > > > > > channel = connection.createChannel();
> > > > > > 
> > > > > > replyQueueName = channel.queueDeclare().getQueue();
> > > > > > 
> > > > > > I've added this line
> > > > > > 
> > > > > > channel.queueBind( replyQueueName , "nameko-rpc", "reply\_to");
> > > > > 
> > > > > Have you bound your reply queue with the \*literal value\* "reply\_to"?  
> > > > > That won't work. It needs to be the value that you've specified in the  
> > > > > "reply to" header in your request message. In your case that's  
> > > > > replyQueueName.
> > > > > 
> > > > > > But same results... the client is stil blocking
> > > > > > 
> > > > > > \<snip\>
> > > > > > 
> > > > > > So the queue would be 'rpc-crawler' right?
> > > > > 
> > > > > That is correct, yes. If it wasn't correct you would not see the  
> > > > > request message being ack'd by your service.
> > > > > 
> > > > > > Laurent
> > > > > > 
> > > > > > Le dimanche 4 mars 2018 20:57:35 UTC+1, Matt Yule-Bennett a écrit :
> > > > > > 
> > > > > > > The RPC reply queue must be bound to the `nameko-rpc` exchange. The  
> > > > > > > reply message is published to that exchange with the 'reply\_to' as the  
> > > > > > > routing key; if you haven't bound the reply queue to the correct exchange,  
> > > > > > > the reply message will be discarded by the broker as not matching any  
> > > > > > > routes.
> > > > > > > 
> > > > > > > Correlation ID has nothing to do with routing messages. It's only  
> > > > > > > used to match replies up with requests so a client can have multiple  
> > > > > > > requests in flight at the same time.
> > > > > > > 
> > > > > > > On Sunday, March 4, 2018 at 6:37:01 PM UTC, lauren...@gmail.com \>\>\>\>\>\> wrote:
> > > > > > > 
> > > > > > > > The problem is before the correlationId.
> > > > > > > > 
> > > > > > > > In the Java source code that is handleDelivery which blocks
> > > > > > > > 
> > > > > > > > Le dimanche 4 mars 2018 19:25:01 UTC+1, lauren...@gmail.com a  
> > > > > > > > écrit :
> > > > > > > > 
> > > > > > > > > Yes but in my Java client i manage the replyQueue  
> > > > > > > > > I Use correlationId.  
> > > > > > > > > I started from the Java code in RabbitMQ RPC/Java/CorrelationId  
> > > > > > > > > section  
> > > > > > > > > [https://github.com/rabbitmq/rabbitmq-tutorials/blob/master/java/RPCClient.java](https://github.com/rabbitmq/rabbitmq-tutorials/blob/master/java/RPCClient.java)
> > > > > > > > > 
> > > > > > > > > In my RabbitMQ management page i see the message sent from client ,  
> > > > > > > > > the Publisher confirm, and the ack now
> > > > > > > > > 
> > > > > > > > > As you say maybe it's a problem with the reply queue, and error in  
> > > > > > > > > my client  
> > > > > > > > > Laurent
> > > > > > > > > 
> > > > > > > > > Le dimanche 4 mars 2018 12:48:11 UTC+1, Matt Yule-Bennett a écrit :
> > > > > > > > > 
> > > > > > > > > > An ack for the request message means that it was received and  
> > > > > > > > > > processed without any error, including sending the reply.
> > > > > > > > > > 
> > > > > > > > > > The reply message is almost certainly being published but not  
> > > > > > > > > > routed to the appropriate reply queue. Looking at your code... is your  
> > > > > > > > > > reply queue bound to the RPC exchange? If not, that's your problem.
> > > > > > > > > > 
> > > > > > > > > > On Sunday, March 4, 2018 at 11:43:49 AM UTC, lauren...@gmail.com \>\>\>\>\>\>\>\>\> wrote:
> > > > > > > > > > 
> > > > > > > > > > > I only see a ack on the RabbitMQ management page... i see my  
> > > > > > > > > > > message sent  
> > > > > > > > > > > I do not see answer in the reply queue  
> > > > > > > > > > > I think the entrypoint is hit because there is an ack, but i do  
> > > > > > > > > > > not understand why the replied message is not sent

---

<div class="post-metadata">

**Author:** ![mattbennett](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.nameko.io/mattbennett/32/13_2.png) [@mattbennett](https://discourse.nameko.io/u/mattbennett)\
**Post date:** [March 14, 2018, 4:23pm UTC](https://discourse.nameko.io/t/calling-a-nameko-service-from-a-java-client/242/15 "2018-03-14T16:23:55Z")

</div>

The \*routing\_key\* needs to be "\<service-name\>.\<method-name\>".  
The \*payload\* needs to be a serialized dict in the form: {"args":  
\<positional-arguments\>, "kwargs": \<keyword-arguments\>}

For example, if I had a service:

class Service:  
&nbsp;&nbsp;&nbsp;&nbsp;name = "service"

&nbsp;&nbsp;&nbsp;&nbsp;@rpc  
&nbsp;&nbsp;&nbsp;&nbsp;def method(self, a, b, c="C", d="D"):  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;print(a, b, c, d)

And I published a message to the RPC exchange with:

\*routing\_key\*: service.method  
\*payload\*: {'args': ['hello', 'world', 'kwargs': {'c':'foo', 'd':'bar'}]}

The service would print:

hello world foo bar

> **···**
>
> On Tuesday, March 13, 2018 at 3:30:46 PM UTC, Laurent Bois M/45/174/90/CF-L1 wrote:
> 
> > Hi folks
> > 
> > How can you translate a payload : service-name-method\_name in JSON with  
> > {args: , kwargs: } notation?
> > 
> > Thanks
> > 
> > Laurent
> > 
> > Le mardi 13 mars 2018 16:30:23 UTC+1, lauren...@gmail.com a écrit :
> > 
> > > Thanks for this great explanation
> > > 
> > > I think the problem can come from the serialization of the payload in  
> > > Java. In my code i just do a byte conversion from string (service.method)
> > > 
> > > In my last tries i sent the payload to the echange, with a reply queue  
> > > (bit not named as you say)
> > > 
> > > I'm going to try what you wrote and come back
> > > 
> > > Thanks
> > > 
> > > Le lundi 12 mars 2018 10:41:31 UTC+1, Matt Yule-Bennett a écrit :
> > > 
> > > > I took a closer look at this and found more problems. I don't have a  
> > > > complete copy of your client so let me just explain in English how the RPC  
> > > > flow works.
> > > > 
> > > > \* The listening service will have declared the "nameko-rpc" exchange,  
> > > > and a queue called "rpc-\<service-name\>", bound to it with the routing key  
> > > > "\<service-name\>.\*" (it's a topic exchange)  
> > > > \* You must declare an RPC reply queue. The queue name can be anything  
> > > > but the nameko Python client names them "rpc.reply-\<service-name\>-\<uuid\>".  
> > > > It must be bound to the "nameko-rpc" exchange with a unique name; the  
> > > > Python client uses a uuid.  
> > > > \* To make a call, you publish a message to the "nameko-rpc" exchange,  
> > > > with "\<service-name\>.\<method-name\>" as the routing key. The payload must be  
> > > > a serialised dict containing the key "args" and "kwargs", with the values  
> > > > being the parameters for the method call. You must specify a "reply\_to"  
> > > > header with the routing key you've used to bind the reply queue to the RPC  
> > > > exchange. You should also specify a "correlation\_id" header so your client  
> > > > can issue multiple concurrent requests and match the replies back up again.  
> > > > You also need to specify content-type and encoding headers so the service  
> > > > knows how to deserialize the incoming data. By default the listening  
> > > > service will be expecting JSON.  
> > > > \* The request message will be routed to the listening service's queue,  
> > > > consumed, processed and ack'd. The service will then reply by publishing to  
> > > > the RPC exchange using the "reply\_to" as the routing key and including the  
> > > > "correlation\_id header from the request message.  
> > > > \* The response message will be routed to the reply queue. Your client  
> > > > should consume it and use the correlation id to match it up with a pending  
> > > > request.
> > > > 
> > > > Looking at your first post, the client is not publishing the request  
> > > > message correctly. It's sending it directly to the service queue via the  
> > > > default exchange, without the correct routing key. Your service is probably  
> > > > consuming the message and replying with a MethodNotFound message, which was  
> > > > being lost because your reply queue wasn't bound correctly either. Your  
> > > > payload also isn't correct in the first version. It should be (assuming  
> > > > JSON serialization) '{"args": , "kwargs": }'
> > > > 
> > > > On Monday, March 5, 2018 at 8:27:32 AM UTC, lauren...@gmail.com wrote:
> > > > 
> > > > > I changed my client code :
> > > > > 
> > > > > First i declare the exchange:
> > > > > 
> > > > > private static final String EXCHANGE\_NAME = "nameko-rpc";
> > > > > 
> > > > > Then after further tries i declare the exchange :
> > > > > 
> > > > > Channel channel = connection.createChannel();
> > > > > 
> > > > > channel.exchangeDeclare(EXCHANGE\_NAME, "topic", true);
> > > > > 
> > > > > Finally i publish my message directly to the exchange and not the requestQueueName ...found the code on RabbitMQ for Publish/Subscribe , section EmitLog client [RabbitMQ tutorial - Publish/Subscribe — RabbitMQ](https://www.rabbitmq.com/tutorials/tutorial-three-java.html)
> > > > > 
> > > > > channel.basicPublish(EXCHANGE\_NAME, "", props, message.getBytes());
> > > > > 
> > > > > The message is a string to the nameko service.methode\_name as it : crawler.scrapit()
> > > > > 
> > > > > I see the message in the RabbitMQ console management, no more the ack .
> > > > > 
> > > > > I have a log in my nameko service but nothing prints in the Terminal... as if the service is not hit
> > > > > 
> > > > > Le dimanche 4 mars 2018 22:54:06 UTC+1, Matt Yule-Bennett a écrit :
> > > > > 
> > > > > > On Sunday, March 4, 2018 at 8:30:23 PM UTC, lauren...@gmail.com wrote:
> > > > > > 
> > > > > > > Thanks.
> > > > > > > 
> > > > > > > In my client, after
> > > > > > > 
> > > > > > > channel = connection.createChannel();
> > > > > > > 
> > > > > > > replyQueueName = channel.queueDeclare().getQueue();
> > > > > > > 
> > > > > > > I've added this line
> > > > > > > 
> > > > > > > channel.queueBind( replyQueueName , "nameko-rpc", "reply\_to");
> > > > > > 
> > > > > > Have you bound your reply queue with the \*literal value\* "reply\_to"?  
> > > > > > That won't work. It needs to be the value that you've specified in the  
> > > > > > "reply to" header in your request message. In your case that's  
> > > > > > replyQueueName.
> > > > > > 
> > > > > > > But same results... the client is stil blocking
> > > > > > > 
> > > > > > > \<snip\>
> > > > > > > 
> > > > > > > So the queue would be 'rpc-crawler' right?
> > > > > > 
> > > > > > That is correct, yes. If it wasn't correct you would not see the  
> > > > > > request message being ack'd by your service.
> > > > > > 
> > > > > > > Laurent
> > > > > > > 
> > > > > > > Le dimanche 4 mars 2018 20:57:35 UTC+1, Matt Yule-Bennett a écrit :
> > > > > > > 
> > > > > > > > The RPC reply queue must be bound to the `nameko-rpc` exchange. The  
> > > > > > > > reply message is published to that exchange with the 'reply\_to' as the  
> > > > > > > > routing key; if you haven't bound the reply queue to the correct exchange,  
> > > > > > > > the reply message will be discarded by the broker as not matching any  
> > > > > > > > routes.
> > > > > > > > 
> > > > > > > > Correlation ID has nothing to do with routing messages. It's only  
> > > > > > > > used to match replies up with requests so a client can have multiple  
> > > > > > > > requests in flight at the same time.
> > > > > > > > 
> > > > > > > > On Sunday, March 4, 2018 at 6:37:01 PM UTC, lauren...@gmail.com \>\>\>\>\>\>\> wrote:
> > > > > > > > 
> > > > > > > > > The problem is before the correlationId.
> > > > > > > > > 
> > > > > > > > > In the Java source code that is handleDelivery which blocks
> > > > > > > > > 
> > > > > > > > > Le dimanche 4 mars 2018 19:25:01 UTC+1, lauren...@gmail.com a  
> > > > > > > > > écrit :
> > > > > > > > > 
> > > > > > > > > > Yes but in my Java client i manage the replyQueue  
> > > > > > > > > > I Use correlationId.  
> > > > > > > > > > I started from the Java code in RabbitMQ RPC/Java/CorrelationId  
> > > > > > > > > > section  
> > > > > > > > > > [https://github.com/rabbitmq/rabbitmq-tutorials/blob/master/java/RPCClient.java](https://github.com/rabbitmq/rabbitmq-tutorials/blob/master/java/RPCClient.java)
> > > > > > > > > > 
> > > > > > > > > > In my RabbitMQ management page i see the message sent from client  
> > > > > > > > > > , the Publisher confirm, and the ack now
> > > > > > > > > > 
> > > > > > > > > > As you say maybe it's a problem with the reply queue, and error in  
> > > > > > > > > > my client  
> > > > > > > > > > Laurent
> > > > > > > > > > 
> > > > > > > > > > Le dimanche 4 mars 2018 12:48:11 UTC+1, Matt Yule-Bennett a écrit :
> > > > > > > > > > 
> > > > > > > > > > > An ack for the request message means that it was received and  
> > > > > > > > > > > processed without any error, including sending the reply.
> > > > > > > > > > > 
> > > > > > > > > > > The reply message is almost certainly being published but not  
> > > > > > > > > > > routed to the appropriate reply queue. Looking at your code... is your  
> > > > > > > > > > > reply queue bound to the RPC exchange? If not, that's your problem.
> > > > > > > > > > > 
> > > > > > > > > > > On Sunday, March 4, 2018 at 11:43:49 AM UTC, lauren...@gmail.com \>\>\>\>\>\>\>\>\>\> wrote:
> > > > > > > > > > > 
> > > > > > > > > > > > I only see a ack on the RabbitMQ management page... i see my  
> > > > > > > > > > > > message sent  
> > > > > > > > > > > > I do not see answer in the reply queue  
> > > > > > > > > > > > I think the entrypoint is hit because there is an ack, but i do  
> > > > > > > > > > > > not understand why the replied message is not sent

---

<div class="post-metadata">

**Author:** ![Laurent\_Bois](https://avatars.discourse-cdn.com/v4/letter/l/49beb7/32.png) [@Laurent\_Bois](https://discourse.nameko.io/u/Laurent_Bois)\
**Post date:** [March 14, 2018, 5:01pm UTC](https://discourse.nameko.io/t/calling-a-nameko-service-from-a-java-client/242/16 "2018-03-14T17:01:26Z")

</div>

\<[https://lh3.googleusercontent.com/-sFO5jtV\_CRA/WqlVQIyYCSI/AAAAAAAAU5Q/6uylmT2jpbgYS4ChEnuXy6Jzn-CqqKvfQCLcBGAs/s1600/Capture%2Bd%25E2%2580%2599e%25CC%2581cran%2B2018-03-14%2Ba%25CC%2580%2B17.59.37.png&gt](https://lh3.googleusercontent.com/-sFO5jtV_CRA/WqlVQIyYCSI/AAAAAAAAU5Q/6uylmT2jpbgYS4ChEnuXy6Jzn-CqqKvfQCLcBGAs/s1600/Capture%2Bd%25E2%2580%2599e%25CC%2581cran%2B2018-03-14%2Ba%25CC%2580%2B17.59.37.png&gt);  
Thanks

I found how to set the routing key. I missed it

\<[https://lh3.googleusercontent.com/-sFO5jtV\_CRA/WqlVQIyYCSI/AAAAAAAAU5Q/6uylmT2jpbgYS4ChEnuXy6Jzn-CqqKvfQCLcBGAs/s1600/Capture%2Bd%25E2%2580%2599e%25CC%2581cran%2B2018-03-14%2Ba%25CC%2580%2B17.59.37.png&gt](https://lh3.googleusercontent.com/-sFO5jtV_CRA/WqlVQIyYCSI/AAAAAAAAU5Q/6uylmT2jpbgYS4ChEnuXy6Jzn-CqqKvfQCLcBGAs/s1600/Capture%2Bd%25E2%2580%2599e%25CC%2581cran%2B2018-03-14%2Ba%25CC%2580%2B17.59.37.png&gt);  
Now with my Routing key, i have something new , i see a message queued

I check for the payload.

Thanks again

> **···**
>
> Le mercredi 14 mars 2018 17:23:55 UTC+1, Matt Yule-Bennett a écrit :
> 
> > The \*routing\_key\* needs to be "\<service-name\>.\<method-name\>".  
> > The \*payload\* needs to be a serialized dict in the form: {"args":  
> > \<positional-arguments\>, "kwargs": \<keyword-arguments\>}
> > 
> > For example, if I had a service:
> > 
> > class Service:  
> > &nbsp;&nbsp;&nbsp;&nbsp;name = "service"
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;@rpc  
> > &nbsp;&nbsp;&nbsp;&nbsp;def method(self, a, b, c="C", d="D"):  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;print(a, b, c, d)
> > 
> > And I published a message to the RPC exchange with:
> > 
> > \*routing\_key\*: service.method  
> > \*payload\*: {'args': ['hello', 'world', 'kwargs': {'c':'foo', 'd':'bar'}]}
> > 
> > The service would print:
> > 
> > hello world foo bar
> > 
> > On Tuesday, March 13, 2018 at 3:30:46 PM UTC, Laurent Bois \> M/45/174/90/CF-L1 wrote:
> > 
> > > Hi folks
> > > 
> > > How can you translate a payload : service-name-method\_name in JSON with  
> > > {args: , kwargs: } notation?
> > > 
> > > Thanks
> > > 
> > > Laurent
> > > 
> > > Le mardi 13 mars 2018 16:30:23 UTC+1, lauren...@gmail.com a écrit :
> > > 
> > > > Thanks for this great explanation
> > > > 
> > > > I think the problem can come from the serialization of the payload in  
> > > > Java. In my code i just do a byte conversion from string (service.method)
> > > > 
> > > > In my last tries i sent the payload to the echange, with a reply queue  
> > > > (bit not named as you say)
> > > > 
> > > > I'm going to try what you wrote and come back
> > > > 
> > > > Thanks
> > > > 
> > > > Le lundi 12 mars 2018 10:41:31 UTC+1, Matt Yule-Bennett a écrit :
> > > > 
> > > > > I took a closer look at this and found more problems. I don't have a  
> > > > > complete copy of your client so let me just explain in English how the RPC  
> > > > > flow works.
> > > > > 
> > > > > \* The listening service will have declared the "nameko-rpc" exchange,  
> > > > > and a queue called "rpc-\<service-name\>", bound to it with the routing key  
> > > > > "\<service-name\>.\*" (it's a topic exchange)  
> > > > > \* You must declare an RPC reply queue. The queue name can be anything  
> > > > > but the nameko Python client names them "rpc.reply-\<service-name\>-\<uuid\>".  
> > > > > It must be bound to the "nameko-rpc" exchange with a unique name; the  
> > > > > Python client uses a uuid.  
> > > > > \* To make a call, you publish a message to the "nameko-rpc" exchange,  
> > > > > with "\<service-name\>.\<method-name\>" as the routing key. The payload must be  
> > > > > a serialised dict containing the key "args" and "kwargs", with the values  
> > > > > being the parameters for the method call. You must specify a "reply\_to"  
> > > > > header with the routing key you've used to bind the reply queue to the RPC  
> > > > > exchange. You should also specify a "correlation\_id" header so your client  
> > > > > can issue multiple concurrent requests and match the replies back up again.  
> > > > > You also need to specify content-type and encoding headers so the service  
> > > > > knows how to deserialize the incoming data. By default the listening  
> > > > > service will be expecting JSON.  
> > > > > \* The request message will be routed to the listening service's queue,  
> > > > > consumed, processed and ack'd. The service will then reply by publishing to  
> > > > > the RPC exchange using the "reply\_to" as the routing key and including the  
> > > > > "correlation\_id header from the request message.  
> > > > > \* The response message will be routed to the reply queue. Your client  
> > > > > should consume it and use the correlation id to match it up with a pending  
> > > > > request.
> > > > > 
> > > > > Looking at your first post, the client is not publishing the request  
> > > > > message correctly. It's sending it directly to the service queue via the  
> > > > > default exchange, without the correct routing key. Your service is probably  
> > > > > consuming the message and replying with a MethodNotFound message, which was  
> > > > > being lost because your reply queue wasn't bound correctly either. Your  
> > > > > payload also isn't correct in the first version. It should be (assuming  
> > > > > JSON serialization) '{"args": , "kwargs": }'
> > > > > 
> > > > > On Monday, March 5, 2018 at 8:27:32 AM UTC, lauren...@gmail.com wrote:
> > > > > 
> > > > > > I changed my client code :
> > > > > > 
> > > > > > First i declare the exchange:
> > > > > > 
> > > > > > private static final String EXCHANGE\_NAME = "nameko-rpc";
> > > > > > 
> > > > > > Then after further tries i declare the exchange :
> > > > > > 
> > > > > > Channel channel = connection.createChannel();
> > > > > > 
> > > > > > channel.exchangeDeclare(EXCHANGE\_NAME, "topic", true);
> > > > > > 
> > > > > > Finally i publish my message directly to the exchange and not the requestQueueName ...found the code on RabbitMQ for Publish/Subscribe , section EmitLog client [RabbitMQ tutorial - Publish/Subscribe — RabbitMQ](https://www.rabbitmq.com/tutorials/tutorial-three-java.html)
> > > > > > 
> > > > > > channel.basicPublish(EXCHANGE\_NAME, "", props, message.getBytes());
> > > > > > 
> > > > > > The message is a string to the nameko service.methode\_name as it : crawler.scrapit()
> > > > > > 
> > > > > > I see the message in the RabbitMQ console management, no more the ack .
> > > > > > 
> > > > > > I have a log in my nameko service but nothing prints in the Terminal... as if the service is not hit
> > > > > > 
> > > > > > Le dimanche 4 mars 2018 22:54:06 UTC+1, Matt Yule-Bennett a écrit :
> > > > > > 
> > > > > > > On Sunday, March 4, 2018 at 8:30:23 PM UTC, lauren...@gmail.com \>\>\>\>\>\> wrote:
> > > > > > > 
> > > > > > > > Thanks.
> > > > > > > > 
> > > > > > > > In my client, after
> > > > > > > > 
> > > > > > > > channel = connection.createChannel();
> > > > > > > > 
> > > > > > > > replyQueueName = channel.queueDeclare().getQueue();
> > > > > > > > 
> > > > > > > > I've added this line
> > > > > > > > 
> > > > > > > > channel.queueBind( replyQueueName , "nameko-rpc", "reply\_to");
> > > > > > > 
> > > > > > > Have you bound your reply queue with the \*literal value\* "reply\_to"?  
> > > > > > > That won't work. It needs to be the value that you've specified in the  
> > > > > > > "reply to" header in your request message. In your case that's  
> > > > > > > replyQueueName.
> > > > > > > 
> > > > > > > > But same results... the client is stil blocking
> > > > > > > > 
> > > > > > > > \<snip\>
> > > > > > > > 
> > > > > > > > So the queue would be 'rpc-crawler' right?
> > > > > > > 
> > > > > > > That is correct, yes. If it wasn't correct you would not see the  
> > > > > > > request message being ack'd by your service.
> > > > > > > 
> > > > > > > > Laurent
> > > > > > > > 
> > > > > > > > Le dimanche 4 mars 2018 20:57:35 UTC+1, Matt Yule-Bennett a écrit :
> > > > > > > > 
> > > > > > > > > The RPC reply queue must be bound to the `nameko-rpc` exchange. The  
> > > > > > > > > reply message is published to that exchange with the 'reply\_to' as the  
> > > > > > > > > routing key; if you haven't bound the reply queue to the correct exchange,  
> > > > > > > > > the reply message will be discarded by the broker as not matching any  
> > > > > > > > > routes.
> > > > > > > > > 
> > > > > > > > > Correlation ID has nothing to do with routing messages. It's only  
> > > > > > > > > used to match replies up with requests so a client can have multiple  
> > > > > > > > > requests in flight at the same time.
> > > > > > > > > 
> > > > > > > > > On Sunday, March 4, 2018 at 6:37:01 PM UTC, lauren...@gmail.com \>\>\>\>\>\>\>\> wrote:
> > > > > > > > > 
> > > > > > > > > > The problem is before the correlationId.
> > > > > > > > > > 
> > > > > > > > > > In the Java source code that is handleDelivery which blocks
> > > > > > > > > > 
> > > > > > > > > > Le dimanche 4 mars 2018 19:25:01 UTC+1, lauren...@gmail.com a  
> > > > > > > > > > écrit :
> > > > > > > > > > 
> > > > > > > > > > > Yes but in my Java client i manage the replyQueue  
> > > > > > > > > > > I Use correlationId.  
> > > > > > > > > > > I started from the Java code in RabbitMQ RPC/Java/CorrelationId  
> > > > > > > > > > > section  
> > > > > > > > > > > [https://github.com/rabbitmq/rabbitmq-tutorials/blob/master/java/RPCClient.java](https://github.com/rabbitmq/rabbitmq-tutorials/blob/master/java/RPCClient.java)
> > > > > > > > > > > 
> > > > > > > > > > > In my RabbitMQ management page i see the message sent from client  
> > > > > > > > > > > , the Publisher confirm, and the ack now
> > > > > > > > > > > 
> > > > > > > > > > > As you say maybe it's a problem with the reply queue, and error  
> > > > > > > > > > > in my client  
> > > > > > > > > > > Laurent
> > > > > > > > > > > 
> > > > > > > > > > > Le dimanche 4 mars 2018 12:48:11 UTC+1, Matt Yule-Bennett a  
> > > > > > > > > > > écrit :
> > > > > > > > > > > 
> > > > > > > > > > > > An ack for the request message means that it was received and  
> > > > > > > > > > > > processed without any error, including sending the reply.
> > > > > > > > > > > > 
> > > > > > > > > > > > The reply message is almost certainly being published but not  
> > > > > > > > > > > > routed to the appropriate reply queue. Looking at your code... is your  
> > > > > > > > > > > > reply queue bound to the RPC exchange? If not, that's your problem.
> > > > > > > > > > > > 
> > > > > > > > > > > > On Sunday, March 4, 2018 at 11:43:49 AM UTC, lauren...@gmail.com \>\>\>\>\>\>\>\>\>\>\> wrote:
> > > > > > > > > > > > 
> > > > > > > > > > > > > I only see a ack on the RabbitMQ management page... i see my  
> > > > > > > > > > > > > message sent  
> > > > > > > > > > > > > I do not see answer in the reply queue  
> > > > > > > > > > > > > I think the entrypoint is hit because there is an ack, but i  
> > > > > > > > > > > > > do not understand why the replied message is not sent

---

<div class="post-metadata">

**Author:** ![Laurent\_Bois](https://avatars.discourse-cdn.com/v4/letter/l/49beb7/32.png) [@Laurent\_Bois](https://discourse.nameko.io/u/Laurent_Bois)\
**Post date:** [March 15, 2018, 7:11am UTC](https://discourse.nameko.io/t/calling-a-nameko-service-from-a-java-client/242/17 "2018-03-15T07:11:35Z")

</div>

Trying to play with payload.  
I have a consumer ack already

my service is now  
class Crawler(object):  
&nbsp;&nbsp;&nbsp;&nbsp;name = "crawler"  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;  
&nbsp;&nbsp;&nbsp;&nbsp;@rpc  
&nbsp;&nbsp;&nbsp;&nbsp;def scrapit(self, a, b, c='C', d='D'):  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;return (a,b,c,d)

and in my Java Client

channel.basicPublish( EXCHANGE\_NAME, "crawler.scrapit", props, "{'args':  
['hello', 'world', 'kwargs': {'c':'foo', 'd':'bar'}]}".getBytes("UTF-8"));

Now i got a returned message like this

"Returned message from service: {'args': ['hello', 'world', 'kwargs': {'c':'foo', 'd':'bar'}]} !"}

Is it normal? Or is it just an echo

Laurent

> **···**
>
> Le mercredi 14 mars 2018 17:23:55 UTC+1, Matt Yule-Bennett a écrit :
> 
> > The \*routing\_key\* needs to be "\<service-name\>.\<method-name\>".  
> > The \*payload\* needs to be a serialized dict in the form: {"args":  
> > \<positional-arguments\>, "kwargs": \<keyword-arguments\>}
> > 
> > For example, if I had a service:
> > 
> > class Service:  
> > &nbsp;&nbsp;&nbsp;&nbsp;name = "service"
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;@rpc  
> > &nbsp;&nbsp;&nbsp;&nbsp;def method(self, a, b, c="C", d="D"):  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;print(a, b, c, d)
> > 
> > And I published a message to the RPC exchange with:
> > 
> > \*routing\_key\*: service.method  
> > \*payload\*: {'args': ['hello', 'world', 'kwargs': {'c':'foo', 'd':'bar'}]}
> > 
> > The service would print:
> > 
> > hello world foo bar
> > 
> > On Tuesday, March 13, 2018 at 3:30:46 PM UTC, Laurent Bois \> M/45/174/90/CF-L1 wrote:
> > 
> > > Hi folks
> > > 
> > > How can you translate a payload : service-name-method\_name in JSON with  
> > > {args: , kwargs: } notation?
> > > 
> > > Thanks
> > > 
> > > Laurent
> > > 
> > > Le mardi 13 mars 2018 16:30:23 UTC+1, lauren...@gmail.com a écrit :
> > > 
> > > > Thanks for this great explanation
> > > > 
> > > > I think the problem can come from the serialization of the payload in  
> > > > Java. In my code i just do a byte conversion from string (service.method)
> > > > 
> > > > In my last tries i sent the payload to the echange, with a reply queue  
> > > > (bit not named as you say)
> > > > 
> > > > I'm going to try what you wrote and come back
> > > > 
> > > > Thanks
> > > > 
> > > > Le lundi 12 mars 2018 10:41:31 UTC+1, Matt Yule-Bennett a écrit :
> > > > 
> > > > > I took a closer look at this and found more problems. I don't have a  
> > > > > complete copy of your client so let me just explain in English how the RPC  
> > > > > flow works.
> > > > > 
> > > > > \* The listening service will have declared the "nameko-rpc" exchange,  
> > > > > and a queue called "rpc-\<service-name\>", bound to it with the routing key  
> > > > > "\<service-name\>.\*" (it's a topic exchange)  
> > > > > \* You must declare an RPC reply queue. The queue name can be anything  
> > > > > but the nameko Python client names them "rpc.reply-\<service-name\>-\<uuid\>".  
> > > > > It must be bound to the "nameko-rpc" exchange with a unique name; the  
> > > > > Python client uses a uuid.  
> > > > > \* To make a call, you publish a message to the "nameko-rpc" exchange,  
> > > > > with "\<service-name\>.\<method-name\>" as the routing key. The payload must be  
> > > > > a serialised dict containing the key "args" and "kwargs", with the values  
> > > > > being the parameters for the method call. You must specify a "reply\_to"  
> > > > > header with the routing key you've used to bind the reply queue to the RPC  
> > > > > exchange. You should also specify a "correlation\_id" header so your client  
> > > > > can issue multiple concurrent requests and match the replies back up again.  
> > > > > You also need to specify content-type and encoding headers so the service  
> > > > > knows how to deserialize the incoming data. By default the listening  
> > > > > service will be expecting JSON.  
> > > > > \* The request message will be routed to the listening service's queue,  
> > > > > consumed, processed and ack'd. The service will then reply by publishing to  
> > > > > the RPC exchange using the "reply\_to" as the routing key and including the  
> > > > > "correlation\_id header from the request message.  
> > > > > \* The response message will be routed to the reply queue. Your client  
> > > > > should consume it and use the correlation id to match it up with a pending  
> > > > > request.
> > > > > 
> > > > > Looking at your first post, the client is not publishing the request  
> > > > > message correctly. It's sending it directly to the service queue via the  
> > > > > default exchange, without the correct routing key. Your service is probably  
> > > > > consuming the message and replying with a MethodNotFound message, which was  
> > > > > being lost because your reply queue wasn't bound correctly either. Your  
> > > > > payload also isn't correct in the first version. It should be (assuming  
> > > > > JSON serialization) '{"args": , "kwargs": }'
> > > > > 
> > > > > On Monday, March 5, 2018 at 8:27:32 AM UTC, lauren...@gmail.com wrote:
> > > > > 
> > > > > > I changed my client code :
> > > > > > 
> > > > > > First i declare the exchange:
> > > > > > 
> > > > > > private static final String EXCHANGE\_NAME = "nameko-rpc";
> > > > > > 
> > > > > > Then after further tries i declare the exchange :
> > > > > > 
> > > > > > Channel channel = connection.createChannel();
> > > > > > 
> > > > > > channel.exchangeDeclare(EXCHANGE\_NAME, "topic", true);
> > > > > > 
> > > > > > Finally i publish my message directly to the exchange and not the requestQueueName ...found the code on RabbitMQ for Publish/Subscribe , section EmitLog client [RabbitMQ tutorial - Publish/Subscribe — RabbitMQ](https://www.rabbitmq.com/tutorials/tutorial-three-java.html)
> > > > > > 
> > > > > > channel.basicPublish(EXCHANGE\_NAME, "", props, message.getBytes());
> > > > > > 
> > > > > > The message is a string to the nameko service.methode\_name as it : crawler.scrapit()
> > > > > > 
> > > > > > I see the message in the RabbitMQ console management, no more the ack .
> > > > > > 
> > > > > > I have a log in my nameko service but nothing prints in the Terminal... as if the service is not hit
> > > > > > 
> > > > > > Le dimanche 4 mars 2018 22:54:06 UTC+1, Matt Yule-Bennett a écrit :
> > > > > > 
> > > > > > > On Sunday, March 4, 2018 at 8:30:23 PM UTC, lauren...@gmail.com \>\>\>\>\>\> wrote:
> > > > > > > 
> > > > > > > > Thanks.
> > > > > > > > 
> > > > > > > > In my client, after
> > > > > > > > 
> > > > > > > > channel = connection.createChannel();
> > > > > > > > 
> > > > > > > > replyQueueName = channel.queueDeclare().getQueue();
> > > > > > > > 
> > > > > > > > I've added this line
> > > > > > > > 
> > > > > > > > channel.queueBind( replyQueueName , "nameko-rpc", "reply\_to");
> > > > > > > 
> > > > > > > Have you bound your reply queue with the \*literal value\* "reply\_to"?  
> > > > > > > That won't work. It needs to be the value that you've specified in the  
> > > > > > > "reply to" header in your request message. In your case that's  
> > > > > > > replyQueueName.
> > > > > > > 
> > > > > > > > But same results... the client is stil blocking
> > > > > > > > 
> > > > > > > > \<snip\>
> > > > > > > > 
> > > > > > > > So the queue would be 'rpc-crawler' right?
> > > > > > > 
> > > > > > > That is correct, yes. If it wasn't correct you would not see the  
> > > > > > > request message being ack'd by your service.
> > > > > > > 
> > > > > > > > Laurent
> > > > > > > > 
> > > > > > > > Le dimanche 4 mars 2018 20:57:35 UTC+1, Matt Yule-Bennett a écrit :
> > > > > > > > 
> > > > > > > > > The RPC reply queue must be bound to the `nameko-rpc` exchange. The  
> > > > > > > > > reply message is published to that exchange with the 'reply\_to' as the  
> > > > > > > > > routing key; if you haven't bound the reply queue to the correct exchange,  
> > > > > > > > > the reply message will be discarded by the broker as not matching any  
> > > > > > > > > routes.
> > > > > > > > > 
> > > > > > > > > Correlation ID has nothing to do with routing messages. It's only  
> > > > > > > > > used to match replies up with requests so a client can have multiple  
> > > > > > > > > requests in flight at the same time.
> > > > > > > > > 
> > > > > > > > > On Sunday, March 4, 2018 at 6:37:01 PM UTC, lauren...@gmail.com \>\>\>\>\>\>\>\> wrote:
> > > > > > > > > 
> > > > > > > > > > The problem is before the correlationId.
> > > > > > > > > > 
> > > > > > > > > > In the Java source code that is handleDelivery which blocks
> > > > > > > > > > 
> > > > > > > > > > Le dimanche 4 mars 2018 19:25:01 UTC+1, lauren...@gmail.com a  
> > > > > > > > > > écrit :
> > > > > > > > > > 
> > > > > > > > > > > Yes but in my Java client i manage the replyQueue  
> > > > > > > > > > > I Use correlationId.  
> > > > > > > > > > > I started from the Java code in RabbitMQ RPC/Java/CorrelationId  
> > > > > > > > > > > section  
> > > > > > > > > > > [https://github.com/rabbitmq/rabbitmq-tutorials/blob/master/java/RPCClient.java](https://github.com/rabbitmq/rabbitmq-tutorials/blob/master/java/RPCClient.java)
> > > > > > > > > > > 
> > > > > > > > > > > In my RabbitMQ management page i see the message sent from client  
> > > > > > > > > > > , the Publisher confirm, and the ack now
> > > > > > > > > > > 
> > > > > > > > > > > As you say maybe it's a problem with the reply queue, and error  
> > > > > > > > > > > in my client  
> > > > > > > > > > > Laurent
> > > > > > > > > > > 
> > > > > > > > > > > Le dimanche 4 mars 2018 12:48:11 UTC+1, Matt Yule-Bennett a  
> > > > > > > > > > > écrit :
> > > > > > > > > > > 
> > > > > > > > > > > > An ack for the request message means that it was received and  
> > > > > > > > > > > > processed without any error, including sending the reply.
> > > > > > > > > > > > 
> > > > > > > > > > > > The reply message is almost certainly being published but not  
> > > > > > > > > > > > routed to the appropriate reply queue. Looking at your code... is your  
> > > > > > > > > > > > reply queue bound to the RPC exchange? If not, that's your problem.
> > > > > > > > > > > > 
> > > > > > > > > > > > On Sunday, March 4, 2018 at 11:43:49 AM UTC, lauren...@gmail.com \>\>\>\>\>\>\>\>\>\>\> wrote:
> > > > > > > > > > > > 
> > > > > > > > > > > > > I only see a ack on the RabbitMQ management page... i see my  
> > > > > > > > > > > > > message sent  
> > > > > > > > > > > > > I do not see answer in the reply queue  
> > > > > > > > > > > > > I think the entrypoint is hit because there is an ack, but i  
> > > > > > > > > > > > > do not understand why the replied message is not sent

---

<div class="post-metadata">

**Author:** ![Laurent\_Bois](https://avatars.discourse-cdn.com/v4/letter/l/49beb7/32.png) [@Laurent\_Bois](https://discourse.nameko.io/u/Laurent_Bois)\
**Post date:** [March 14, 2018, 5:03pm UTC](https://discourse.nameko.io/t/calling-a-nameko-service-from-a-java-client/242/18 "2018-03-14T17:03:42Z")

</div>

And i got a consumer ack.

\<[https://lh3.googleusercontent.com/-z2ka0QBoxHk/WqlV5zDkoVI/AAAAAAAAU5U/P1iYGsurOgsa6G7iIuoOeOrbPX-u4jNkgCLcBGAs/s1600/Capture%2Bd%25E2%2580%2599e%25CC%2581cran%2B2018-03-14%2Ba%25CC%2580%2B18.02.52.png&gt](https://lh3.googleusercontent.com/-z2ka0QBoxHk/WqlV5zDkoVI/AAAAAAAAU5U/P1iYGsurOgsa6G7iIuoOeOrbPX-u4jNkgCLcBGAs/s1600/Capture%2Bd%25E2%2580%2599e%25CC%2581cran%2B2018-03-14%2Ba%25CC%2580%2B18.02.52.png&gt);

> **···**
>
> Le mercredi 14 mars 2018 18:01:26 UTC+1, lauren...@gmail.com a écrit :
> 
> > \<[https://lh3.googleusercontent.com/-sFO5jtV\_CRA/WqlVQIyYCSI/AAAAAAAAU5Q/6uylmT2jpbgYS4ChEnuXy6Jzn-CqqKvfQCLcBGAs/s1600/Capture%2Bd%25E2%2580%2599e%25CC%2581cran%2B2018-03-14%2Ba%25CC%2580%2B17.59.37.png&gt](https://lh3.googleusercontent.com/-sFO5jtV_CRA/WqlVQIyYCSI/AAAAAAAAU5Q/6uylmT2jpbgYS4ChEnuXy6Jzn-CqqKvfQCLcBGAs/s1600/Capture%2Bd%25E2%2580%2599e%25CC%2581cran%2B2018-03-14%2Ba%25CC%2580%2B17.59.37.png&gt);  
> > Thanks
> > 
> > I found how to set the routing key. I missed it
> > 
> > \<[https://lh3.googleusercontent.com/-sFO5jtV\_CRA/WqlVQIyYCSI/AAAAAAAAU5Q/6uylmT2jpbgYS4ChEnuXy6Jzn-CqqKvfQCLcBGAs/s1600/Capture%2Bd%25E2%2580%2599e%25CC%2581cran%2B2018-03-14%2Ba%25CC%2580%2B17.59.37.png&gt](https://lh3.googleusercontent.com/-sFO5jtV_CRA/WqlVQIyYCSI/AAAAAAAAU5Q/6uylmT2jpbgYS4ChEnuXy6Jzn-CqqKvfQCLcBGAs/s1600/Capture%2Bd%25E2%2580%2599e%25CC%2581cran%2B2018-03-14%2Ba%25CC%2580%2B17.59.37.png&gt);  
> > Now with my Routing key, i have something new , i see a message queued
> > 
> > I check for the payload.
> > 
> > Thanks again
> > 
> > Le mercredi 14 mars 2018 17:23:55 UTC+1, Matt Yule-Bennett a écrit :
> > 
> > > The \*routing\_key\* needs to be "\<service-name\>.\<method-name\>".  
> > > The \*payload\* needs to be a serialized dict in the form: {"args":  
> > > \<positional-arguments\>, "kwargs": \<keyword-arguments\>}
> > > 
> > > For example, if I had a service:
> > > 
> > > class Service:  
> > > &nbsp;&nbsp;&nbsp;&nbsp;name = "service"
> > > 
> > > &nbsp;&nbsp;&nbsp;&nbsp;@rpc  
> > > &nbsp;&nbsp;&nbsp;&nbsp;def method(self, a, b, c="C", d="D"):  
> > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;print(a, b, c, d)
> > > 
> > > And I published a message to the RPC exchange with:
> > > 
> > > \*routing\_key\*: service.method  
> > > \*payload\*: {'args': ['hello', 'world', 'kwargs': {'c':'foo', 'd':'bar'}]}
> > > 
> > > The service would print:
> > > 
> > > hello world foo bar
> > > 
> > > On Tuesday, March 13, 2018 at 3:30:46 PM UTC, Laurent Bois \>\> M/45/174/90/CF-L1 wrote:
> > > 
> > > > Hi folks
> > > > 
> > > > How can you translate a payload : service-name-method\_name in JSON with  
> > > > {args: , kwargs: } notation?
> > > > 
> > > > Thanks
> > > > 
> > > > Laurent
> > > > 
> > > > Le mardi 13 mars 2018 16:30:23 UTC+1, lauren...@gmail.com a écrit :
> > > > 
> > > > > Thanks for this great explanation
> > > > > 
> > > > > I think the problem can come from the serialization of the payload in  
> > > > > Java. In my code i just do a byte conversion from string (service.method)
> > > > > 
> > > > > In my last tries i sent the payload to the echange, with a reply queue  
> > > > > (bit not named as you say)
> > > > > 
> > > > > I'm going to try what you wrote and come back
> > > > > 
> > > > > Thanks
> > > > > 
> > > > > Le lundi 12 mars 2018 10:41:31 UTC+1, Matt Yule-Bennett a écrit :
> > > > > 
> > > > > > I took a closer look at this and found more problems. I don't have a  
> > > > > > complete copy of your client so let me just explain in English how the RPC  
> > > > > > flow works.
> > > > > > 
> > > > > > \* The listening service will have declared the "nameko-rpc" exchange,  
> > > > > > and a queue called "rpc-\<service-name\>", bound to it with the routing key  
> > > > > > "\<service-name\>.\*" (it's a topic exchange)  
> > > > > > \* You must declare an RPC reply queue. The queue name can be anything  
> > > > > > but the nameko Python client names them "rpc.reply-\<service-name\>-\<uuid\>".  
> > > > > > It must be bound to the "nameko-rpc" exchange with a unique name; the  
> > > > > > Python client uses a uuid.  
> > > > > > \* To make a call, you publish a message to the "nameko-rpc" exchange,  
> > > > > > with "\<service-name\>.\<method-name\>" as the routing key. The payload must be  
> > > > > > a serialised dict containing the key "args" and "kwargs", with the values  
> > > > > > being the parameters for the method call. You must specify a "reply\_to"  
> > > > > > header with the routing key you've used to bind the reply queue to the RPC  
> > > > > > exchange. You should also specify a "correlation\_id" header so your client  
> > > > > > can issue multiple concurrent requests and match the replies back up again.  
> > > > > > You also need to specify content-type and encoding headers so the service  
> > > > > > knows how to deserialize the incoming data. By default the listening  
> > > > > > service will be expecting JSON.  
> > > > > > \* The request message will be routed to the listening service's queue,  
> > > > > > consumed, processed and ack'd. The service will then reply by publishing to  
> > > > > > the RPC exchange using the "reply\_to" as the routing key and including the  
> > > > > > "correlation\_id header from the request message.  
> > > > > > \* The response message will be routed to the reply queue. Your client  
> > > > > > should consume it and use the correlation id to match it up with a pending  
> > > > > > request.
> > > > > > 
> > > > > > Looking at your first post, the client is not publishing the request  
> > > > > > message correctly. It's sending it directly to the service queue via the  
> > > > > > default exchange, without the correct routing key. Your service is probably  
> > > > > > consuming the message and replying with a MethodNotFound message, which was  
> > > > > > being lost because your reply queue wasn't bound correctly either. Your  
> > > > > > payload also isn't correct in the first version. It should be (assuming  
> > > > > > JSON serialization) '{"args": , "kwargs": }'
> > > > > > 
> > > > > > On Monday, March 5, 2018 at 8:27:32 AM UTC, lauren...@gmail.com wrote:
> > > > > > 
> > > > > > > I changed my client code :
> > > > > > > 
> > > > > > > First i declare the exchange:
> > > > > > > 
> > > > > > > private static final String EXCHANGE\_NAME = "nameko-rpc";
> > > > > > > 
> > > > > > > Then after further tries i declare the exchange :
> > > > > > > 
> > > > > > > Channel channel = connection.createChannel();
> > > > > > > 
> > > > > > > channel.exchangeDeclare(EXCHANGE\_NAME, "topic", true);
> > > > > > > 
> > > > > > > Finally i publish my message directly to the exchange and not the requestQueueName ...found the code on RabbitMQ for Publish/Subscribe , section EmitLog client [RabbitMQ tutorial - Publish/Subscribe — RabbitMQ](https://www.rabbitmq.com/tutorials/tutorial-three-java.html)
> > > > > > > 
> > > > > > > channel.basicPublish(EXCHANGE\_NAME, "", props, message.getBytes());
> > > > > > > 
> > > > > > > The message is a string to the nameko service.methode\_name as it : crawler.scrapit()
> > > > > > > 
> > > > > > > I see the message in the RabbitMQ console management, no more the ack .
> > > > > > > 
> > > > > > > I have a log in my nameko service but nothing prints in the Terminal... as if the service is not hit
> > > > > > > 
> > > > > > > Le dimanche 4 mars 2018 22:54:06 UTC+1, Matt Yule-Bennett a écrit :
> > > > > > > 
> > > > > > > > On Sunday, March 4, 2018 at 8:30:23 PM UTC, lauren...@gmail.com \>\>\>\>\>\>\> wrote:
> > > > > > > > 
> > > > > > > > > Thanks.
> > > > > > > > > 
> > > > > > > > > In my client, after
> > > > > > > > > 
> > > > > > > > > channel = connection.createChannel();
> > > > > > > > > 
> > > > > > > > > replyQueueName = channel.queueDeclare().getQueue();
> > > > > > > > > 
> > > > > > > > > I've added this line
> > > > > > > > > 
> > > > > > > > > channel.queueBind( replyQueueName , "nameko-rpc", "reply\_to");
> > > > > > > > 
> > > > > > > > Have you bound your reply queue with the \*literal value\*  
> > > > > > > > "reply\_to"? That won't work. It needs to be the value that you've specified  
> > > > > > > > in the "reply to" header in your request message. In your case that's  
> > > > > > > > replyQueueName.
> > > > > > > > 
> > > > > > > > > But same results... the client is stil blocking
> > > > > > > > > 
> > > > > > > > > \<snip\>
> > > > > > > > > 
> > > > > > > > > So the queue would be 'rpc-crawler' right?
> > > > > > > > 
> > > > > > > > That is correct, yes. If it wasn't correct you would not see the  
> > > > > > > > request message being ack'd by your service.
> > > > > > > > 
> > > > > > > > > Laurent
> > > > > > > > > 
> > > > > > > > > Le dimanche 4 mars 2018 20:57:35 UTC+1, Matt Yule-Bennett a écrit :
> > > > > > > > > 
> > > > > > > > > > The RPC reply queue must be bound to the `nameko-rpc` exchange.  
> > > > > > > > > > The reply message is published to that exchange with the 'reply\_to' as the  
> > > > > > > > > > routing key; if you haven't bound the reply queue to the correct exchange,  
> > > > > > > > > > the reply message will be discarded by the broker as not matching any  
> > > > > > > > > > routes.
> > > > > > > > > > 
> > > > > > > > > > Correlation ID has nothing to do with routing messages. It's only  
> > > > > > > > > > used to match replies up with requests so a client can have multiple  
> > > > > > > > > > requests in flight at the same time.
> > > > > > > > > > 
> > > > > > > > > > On Sunday, March 4, 2018 at 6:37:01 PM UTC, lauren...@gmail.com \>\>\>\>\>\>\>\>\> wrote:
> > > > > > > > > > 
> > > > > > > > > > > The problem is before the correlationId.
> > > > > > > > > > > 
> > > > > > > > > > > In the Java source code that is handleDelivery which blocks
> > > > > > > > > > > 
> > > > > > > > > > > Le dimanche 4 mars 2018 19:25:01 UTC+1, lauren...@gmail.com a  
> > > > > > > > > > > écrit :
> > > > > > > > > > > 
> > > > > > > > > > > > Yes but in my Java client i manage the replyQueue  
> > > > > > > > > > > > I Use correlationId.  
> > > > > > > > > > > > I started from the Java code in RabbitMQ RPC/Java/CorrelationId  
> > > > > > > > > > > > section  
> > > > > > > > > > > > [https://github.com/rabbitmq/rabbitmq-tutorials/blob/master/java/RPCClient.java](https://github.com/rabbitmq/rabbitmq-tutorials/blob/master/java/RPCClient.java)
> > > > > > > > > > > > 
> > > > > > > > > > > > In my RabbitMQ management page i see the message sent from  
> > > > > > > > > > > > client , the Publisher confirm, and the ack now
> > > > > > > > > > > > 
> > > > > > > > > > > > As you say maybe it's a problem with the reply queue, and error  
> > > > > > > > > > > > in my client  
> > > > > > > > > > > > Laurent
> > > > > > > > > > > > 
> > > > > > > > > > > > Le dimanche 4 mars 2018 12:48:11 UTC+1, Matt Yule-Bennett a  
> > > > > > > > > > > > écrit :
> > > > > > > > > > > > 
> > > > > > > > > > > > > An ack for the request message means that it was received and  
> > > > > > > > > > > > > processed without any error, including sending the reply.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > The reply message is almost certainly being published but not  
> > > > > > > > > > > > > routed to the appropriate reply queue. Looking at your code... is your  
> > > > > > > > > > > > > reply queue bound to the RPC exchange? If not, that's your problem.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > On Sunday, March 4, 2018 at 11:43:49 AM UTC, \>\>\>\>\>\>\>\>\>\>\>\> lauren...@gmail.com wrote:
> > > > > > > > > > > > > 
> > > > > > > > > > > > > > I only see a ack on the RabbitMQ management page... i see my  
> > > > > > > > > > > > > > message sent  
> > > > > > > > > > > > > > I do not see answer in the reply queue  
> > > > > > > > > > > > > > I think the entrypoint is hit because there is an ack, but i  
> > > > > > > > > > > > > > do not understand why the replied message is not sent

---

<div class="post-metadata">

**Author:** ![mattbennett](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.nameko.io/mattbennett/32/13_2.png) [@mattbennett](https://discourse.nameko.io/u/mattbennett)\
**Post date:** [March 15, 2018, 9:56am UTC](https://discourse.nameko.io/t/calling-a-nameko-service-from-a-java-client/242/19 "2018-03-15T09:56:58Z")

</div>

Congratulations, your client is working.

> Trying to play with payload.  
> I have a consumer ack already
> 
> my service is now  
> class Crawler(object):  
> &nbsp;&nbsp;&nbsp;&nbsp;name = "crawler"  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;  
> &nbsp;&nbsp;&nbsp;&nbsp;@rpc  
> &nbsp;&nbsp;&nbsp;&nbsp;def scrapit(self, a, b, c='C', d='D'):  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;return (a,b,c,d)
> 
> and in my Java Client
> 
> channel.basicPublish( EXCHANGE\_NAME, "crawler.scrapit", props, "{'args':  
> ['hello', 'world', 'kwargs': {'c':'foo', 'd':'bar'}]}".getBytes("UTF-8"));
> 
> Now i got a returned message like this
> 
> "Returned message from service: {'args': ['hello', 'world', 'kwargs': {'c':'foo', 'd':'bar'}]} !"}
> 
> Is it normal? Or is it just an echo

This is what you've asked your service to return. The RPC entrypoint will  
serialize (if it can) whatever is returned from the decorated method and  
return that to the client.

> **···**
>
> On Thursday, March 15, 2018 at 7:11:35 AM UTC, Laurent Bois M/45/174/90/CF-L1 wrote:
> 
> > Laurent
> > 
> > Le mercredi 14 mars 2018 17:23:55 UTC+1, Matt Yule-Bennett a écrit :
> > 
> > > The \*routing\_key\* needs to be "\<service-name\>.\<method-name\>".  
> > > The \*payload\* needs to be a serialized dict in the form: {"args":  
> > > \<positional-arguments\>, "kwargs": \<keyword-arguments\>}
> > > 
> > > For example, if I had a service:
> > > 
> > > class Service:  
> > > &nbsp;&nbsp;&nbsp;&nbsp;name = "service"
> > > 
> > > &nbsp;&nbsp;&nbsp;&nbsp;@rpc  
> > > &nbsp;&nbsp;&nbsp;&nbsp;def method(self, a, b, c="C", d="D"):  
> > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;print(a, b, c, d)
> > > 
> > > And I published a message to the RPC exchange with:
> > > 
> > > \*routing\_key\*: service.method  
> > > \*payload\*: {'args': ['hello', 'world', 'kwargs': {'c':'foo', 'd':'bar'}]}
> > > 
> > > The service would print:
> > > 
> > > hello world foo bar
> > > 
> > > On Tuesday, March 13, 2018 at 3:30:46 PM UTC, Laurent Bois \>\> M/45/174/90/CF-L1 wrote:
> > > 
> > > > Hi folks
> > > > 
> > > > How can you translate a payload : service-name-method\_name in JSON with  
> > > > {args: , kwargs: } notation?
> > > > 
> > > > Thanks
> > > > 
> > > > Laurent
> > > > 
> > > > Le mardi 13 mars 2018 16:30:23 UTC+1, lauren...@gmail.com a écrit :
> > > > 
> > > > > Thanks for this great explanation
> > > > > 
> > > > > I think the problem can come from the serialization of the payload in  
> > > > > Java. In my code i just do a byte conversion from string (service.method)
> > > > > 
> > > > > In my last tries i sent the payload to the echange, with a reply queue  
> > > > > (bit not named as you say)
> > > > > 
> > > > > I'm going to try what you wrote and come back
> > > > > 
> > > > > Thanks
> > > > > 
> > > > > Le lundi 12 mars 2018 10:41:31 UTC+1, Matt Yule-Bennett a écrit :
> > > > > 
> > > > > > I took a closer look at this and found more problems. I don't have a  
> > > > > > complete copy of your client so let me just explain in English how the RPC  
> > > > > > flow works.
> > > > > > 
> > > > > > \* The listening service will have declared the "nameko-rpc" exchange,  
> > > > > > and a queue called "rpc-\<service-name\>", bound to it with the routing key  
> > > > > > "\<service-name\>.\*" (it's a topic exchange)  
> > > > > > \* You must declare an RPC reply queue. The queue name can be anything  
> > > > > > but the nameko Python client names them "rpc.reply-\<service-name\>-\<uuid\>".  
> > > > > > It must be bound to the "nameko-rpc" exchange with a unique name; the  
> > > > > > Python client uses a uuid.  
> > > > > > \* To make a call, you publish a message to the "nameko-rpc" exchange,  
> > > > > > with "\<service-name\>.\<method-name\>" as the routing key. The payload must be  
> > > > > > a serialised dict containing the key "args" and "kwargs", with the values  
> > > > > > being the parameters for the method call. You must specify a "reply\_to"  
> > > > > > header with the routing key you've used to bind the reply queue to the RPC  
> > > > > > exchange. You should also specify a "correlation\_id" header so your client  
> > > > > > can issue multiple concurrent requests and match the replies back up again.  
> > > > > > You also need to specify content-type and encoding headers so the service  
> > > > > > knows how to deserialize the incoming data. By default the listening  
> > > > > > service will be expecting JSON.  
> > > > > > \* The request message will be routed to the listening service's queue,  
> > > > > > consumed, processed and ack'd. The service will then reply by publishing to  
> > > > > > the RPC exchange using the "reply\_to" as the routing key and including the  
> > > > > > "correlation\_id header from the request message.  
> > > > > > \* The response message will be routed to the reply queue. Your client  
> > > > > > should consume it and use the correlation id to match it up with a pending  
> > > > > > request.
> > > > > > 
> > > > > > Looking at your first post, the client is not publishing the request  
> > > > > > message correctly. It's sending it directly to the service queue via the  
> > > > > > default exchange, without the correct routing key. Your service is probably  
> > > > > > consuming the message and replying with a MethodNotFound message, which was  
> > > > > > being lost because your reply queue wasn't bound correctly either. Your  
> > > > > > payload also isn't correct in the first version. It should be (assuming  
> > > > > > JSON serialization) '{"args": , "kwargs": }'
> > > > > > 
> > > > > > On Monday, March 5, 2018 at 8:27:32 AM UTC, lauren...@gmail.com wrote:
> > > > > > 
> > > > > > > I changed my client code :
> > > > > > > 
> > > > > > > First i declare the exchange:
> > > > > > > 
> > > > > > > private static final String EXCHANGE\_NAME = "nameko-rpc";
> > > > > > > 
> > > > > > > Then after further tries i declare the exchange :
> > > > > > > 
> > > > > > > Channel channel = connection.createChannel();
> > > > > > > 
> > > > > > > channel.exchangeDeclare(EXCHANGE\_NAME, "topic", true);
> > > > > > > 
> > > > > > > Finally i publish my message directly to the exchange and not the requestQueueName ...found the code on RabbitMQ for Publish/Subscribe , section EmitLog client [RabbitMQ tutorial - Publish/Subscribe — RabbitMQ](https://www.rabbitmq.com/tutorials/tutorial-three-java.html)
> > > > > > > 
> > > > > > > channel.basicPublish(EXCHANGE\_NAME, "", props, message.getBytes());
> > > > > > > 
> > > > > > > The message is a string to the nameko service.methode\_name as it : crawler.scrapit()
> > > > > > > 
> > > > > > > I see the message in the RabbitMQ console management, no more the ack .
> > > > > > > 
> > > > > > > I have a log in my nameko service but nothing prints in the Terminal... as if the service is not hit
> > > > > > > 
> > > > > > > Le dimanche 4 mars 2018 22:54:06 UTC+1, Matt Yule-Bennett a écrit :
> > > > > > > 
> > > > > > > > On Sunday, March 4, 2018 at 8:30:23 PM UTC, lauren...@gmail.com \>\>\>\>\>\>\> wrote:
> > > > > > > > 
> > > > > > > > > Thanks.
> > > > > > > > > 
> > > > > > > > > In my client, after
> > > > > > > > > 
> > > > > > > > > channel = connection.createChannel();
> > > > > > > > > 
> > > > > > > > > replyQueueName = channel.queueDeclare().getQueue();
> > > > > > > > > 
> > > > > > > > > I've added this line
> > > > > > > > > 
> > > > > > > > > channel.queueBind( replyQueueName , "nameko-rpc", "reply\_to");
> > > > > > > > 
> > > > > > > > Have you bound your reply queue with the \*literal value\*  
> > > > > > > > "reply\_to"? That won't work. It needs to be the value that you've specified  
> > > > > > > > in the "reply to" header in your request message. In your case that's  
> > > > > > > > replyQueueName.
> > > > > > > > 
> > > > > > > > > But same results... the client is stil blocking
> > > > > > > > > 
> > > > > > > > > \<snip\>
> > > > > > > > > 
> > > > > > > > > So the queue would be 'rpc-crawler' right?
> > > > > > > > 
> > > > > > > > That is correct, yes. If it wasn't correct you would not see the  
> > > > > > > > request message being ack'd by your service.
> > > > > > > > 
> > > > > > > > > Laurent
> > > > > > > > > 
> > > > > > > > > Le dimanche 4 mars 2018 20:57:35 UTC+1, Matt Yule-Bennett a écrit :
> > > > > > > > > 
> > > > > > > > > > The RPC reply queue must be bound to the `nameko-rpc` exchange.  
> > > > > > > > > > The reply message is published to that exchange with the 'reply\_to' as the  
> > > > > > > > > > routing key; if you haven't bound the reply queue to the correct exchange,  
> > > > > > > > > > the reply message will be discarded by the broker as not matching any  
> > > > > > > > > > routes.
> > > > > > > > > > 
> > > > > > > > > > Correlation ID has nothing to do with routing messages. It's only  
> > > > > > > > > > used to match replies up with requests so a client can have multiple  
> > > > > > > > > > requests in flight at the same time.
> > > > > > > > > > 
> > > > > > > > > > On Sunday, March 4, 2018 at 6:37:01 PM UTC, lauren...@gmail.com \>\>\>\>\>\>\>\>\> wrote:
> > > > > > > > > > 
> > > > > > > > > > > The problem is before the correlationId.
> > > > > > > > > > > 
> > > > > > > > > > > In the Java source code that is handleDelivery which blocks
> > > > > > > > > > > 
> > > > > > > > > > > Le dimanche 4 mars 2018 19:25:01 UTC+1, lauren...@gmail.com a  
> > > > > > > > > > > écrit :
> > > > > > > > > > > 
> > > > > > > > > > > > Yes but in my Java client i manage the replyQueue  
> > > > > > > > > > > > I Use correlationId.  
> > > > > > > > > > > > I started from the Java code in RabbitMQ RPC/Java/CorrelationId  
> > > > > > > > > > > > section  
> > > > > > > > > > > > [https://github.com/rabbitmq/rabbitmq-tutorials/blob/master/java/RPCClient.java](https://github.com/rabbitmq/rabbitmq-tutorials/blob/master/java/RPCClient.java)
> > > > > > > > > > > > 
> > > > > > > > > > > > In my RabbitMQ management page i see the message sent from  
> > > > > > > > > > > > client , the Publisher confirm, and the ack now
> > > > > > > > > > > > 
> > > > > > > > > > > > As you say maybe it's a problem with the reply queue, and error  
> > > > > > > > > > > > in my client  
> > > > > > > > > > > > Laurent
> > > > > > > > > > > > 
> > > > > > > > > > > > Le dimanche 4 mars 2018 12:48:11 UTC+1, Matt Yule-Bennett a  
> > > > > > > > > > > > écrit :
> > > > > > > > > > > > 
> > > > > > > > > > > > > An ack for the request message means that it was received and  
> > > > > > > > > > > > > processed without any error, including sending the reply.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > The reply message is almost certainly being published but not  
> > > > > > > > > > > > > routed to the appropriate reply queue. Looking at your code... is your  
> > > > > > > > > > > > > reply queue bound to the RPC exchange? If not, that's your problem.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > On Sunday, March 4, 2018 at 11:43:49 AM UTC, \>\>\>\>\>\>\>\>\>\>\>\> lauren...@gmail.com wrote:
> > > > > > > > > > > > > 
> > > > > > > > > > > > > > I only see a ack on the RabbitMQ management page... i see my  
> > > > > > > > > > > > > > message sent  
> > > > > > > > > > > > > > I do not see answer in the reply queue  
> > > > > > > > > > > > > > I think the entrypoint is hit because there is an ack, but i  
> > > > > > > > > > > > > > do not understand why the replied message is not sent

---

<div class="post-metadata">

**Author:** ![Laurent\_Bois](https://avatars.discourse-cdn.com/v4/letter/l/49beb7/32.png) [@Laurent\_Bois](https://discourse.nameko.io/u/Laurent_Bois)\
**Post date:** [March 15, 2018, 10:04am UTC](https://discourse.nameko.io/t/calling-a-nameko-service-from-a-java-client/242/20 "2018-03-15T10:04:33Z")

</div>

My last question

Is the answer from the consumer (Nameko service in Python) formatted in  
JSON/dict?

Laurent

> **···**
>
> Le jeudi 15 mars 2018 10:56:58 UTC+1, Matt Yule-Bennett a écrit :
> 
> > Congratulations, your client is working.
> > 
> > On Thursday, March 15, 2018 at 7:11:35 AM UTC, Laurent Bois \> M/45/174/90/CF-L1 wrote:
> > 
> > > Trying to play with payload.  
> > > I have a consumer ack already
> > > 
> > > my service is now  
> > > class Crawler(object):  
> > > &nbsp;&nbsp;&nbsp;&nbsp;name = "crawler"  
> > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;  
> > > &nbsp;&nbsp;&nbsp;&nbsp;@rpc  
> > > &nbsp;&nbsp;&nbsp;&nbsp;def scrapit(self, a, b, c='C', d='D'):  
> > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;return (a,b,c,d)
> > > 
> > > and in my Java Client
> > > 
> > > channel.basicPublish( EXCHANGE\_NAME, "crawler.scrapit", props, "{'args':  
> > > ['hello', 'world', 'kwargs': {'c':'foo', 'd':'bar'}]}".getBytes("UTF-8"  
> > > ));
> > > 
> > > Now i got a returned message like this
> > > 
> > > "Returned message from service: {'args': ['hello', 'world', 'kwargs': {'c':'foo', 'd':'bar'}]} !"}
> > > 
> > > Is it normal? Or is it just an echo
> > 
> > This is what you've asked your service to return. The RPC entrypoint will  
> > serialize (if it can) whatever is returned from the decorated method and  
> > return that to the client.
> > 
> > > Laurent
> > > 
> > > Le mercredi 14 mars 2018 17:23:55 UTC+1, Matt Yule-Bennett a écrit :
> > > 
> > > > The \*routing\_key\* needs to be "\<service-name\>.\<method-name\>".  
> > > > The \*payload\* needs to be a serialized dict in the form: {"args":  
> > > > \<positional-arguments\>, "kwargs": \<keyword-arguments\>}
> > > > 
> > > > For example, if I had a service:
> > > > 
> > > > class Service:  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;name = "service"
> > > > 
> > > > &nbsp;&nbsp;&nbsp;&nbsp;@rpc  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;def method(self, a, b, c="C", d="D"):  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;print(a, b, c, d)
> > > > 
> > > > And I published a message to the RPC exchange with:
> > > > 
> > > > \*routing\_key\*: service.method  
> > > > \*payload\*: {'args': ['hello', 'world', 'kwargs': {'c':'foo',  
> > > > 'd':'bar'}]}
> > > > 
> > > > The service would print:
> > > > 
> > > > hello world foo bar
> > > > 
> > > > On Tuesday, March 13, 2018 at 3:30:46 PM UTC, Laurent Bois \>\>\> M/45/174/90/CF-L1 wrote:
> > > > 
> > > > > Hi folks
> > > > > 
> > > > > How can you translate a payload : service-name-method\_name in JSON with  
> > > > > {args: , kwargs: } notation?
> > > > > 
> > > > > Thanks
> > > > > 
> > > > > Laurent
> > > > > 
> > > > > Le mardi 13 mars 2018 16:30:23 UTC+1, lauren...@gmail.com a écrit :
> > > > > 
> > > > > > Thanks for this great explanation
> > > > > > 
> > > > > > I think the problem can come from the serialization of the payload in  
> > > > > > Java. In my code i just do a byte conversion from string (service.method)
> > > > > > 
> > > > > > In my last tries i sent the payload to the echange, with a reply queue  
> > > > > > (bit not named as you say)
> > > > > > 
> > > > > > I'm going to try what you wrote and come back
> > > > > > 
> > > > > > Thanks
> > > > > > 
> > > > > > Le lundi 12 mars 2018 10:41:31 UTC+1, Matt Yule-Bennett a écrit :
> > > > > > 
> > > > > > > I took a closer look at this and found more problems. I don't have a  
> > > > > > > complete copy of your client so let me just explain in English how the RPC  
> > > > > > > flow works.
> > > > > > > 
> > > > > > > \* The listening service will have declared the "nameko-rpc" exchange,  
> > > > > > > and a queue called "rpc-\<service-name\>", bound to it with the routing key  
> > > > > > > "\<service-name\>.\*" (it's a topic exchange)  
> > > > > > > \* You must declare an RPC reply queue. The queue name can be anything  
> > > > > > > but the nameko Python client names them "rpc.reply-\<service-name\>-\<uuid\>".  
> > > > > > > It must be bound to the "nameko-rpc" exchange with a unique name; the  
> > > > > > > Python client uses a uuid.  
> > > > > > > \* To make a call, you publish a message to the "nameko-rpc" exchange,  
> > > > > > > with "\<service-name\>.\<method-name\>" as the routing key. The payload must be  
> > > > > > > a serialised dict containing the key "args" and "kwargs", with the values  
> > > > > > > being the parameters for the method call. You must specify a "reply\_to"  
> > > > > > > header with the routing key you've used to bind the reply queue to the RPC  
> > > > > > > exchange. You should also specify a "correlation\_id" header so your client  
> > > > > > > can issue multiple concurrent requests and match the replies back up again.  
> > > > > > > You also need to specify content-type and encoding headers so the service  
> > > > > > > knows how to deserialize the incoming data. By default the listening  
> > > > > > > service will be expecting JSON.  
> > > > > > > \* The request message will be routed to the listening service's  
> > > > > > > queue, consumed, processed and ack'd. The service will then reply by  
> > > > > > > publishing to the RPC exchange using the "reply\_to" as the routing key and  
> > > > > > > including the "correlation\_id header from the request message.  
> > > > > > > \* The response message will be routed to the reply queue. Your client  
> > > > > > > should consume it and use the correlation id to match it up with a pending  
> > > > > > > request.
> > > > > > > 
> > > > > > > Looking at your first post, the client is not publishing the request  
> > > > > > > message correctly. It's sending it directly to the service queue via the  
> > > > > > > default exchange, without the correct routing key. Your service is probably  
> > > > > > > consuming the message and replying with a MethodNotFound message, which was  
> > > > > > > being lost because your reply queue wasn't bound correctly either. Your  
> > > > > > > payload also isn't correct in the first version. It should be (assuming  
> > > > > > > JSON serialization) '{"args": , "kwargs": }'
> > > > > > > 
> > > > > > > On Monday, March 5, 2018 at 8:27:32 AM UTC, lauren...@gmail.com \>\>\>\>\>\> wrote:
> > > > > > > 
> > > > > > > > I changed my client code :
> > > > > > > > 
> > > > > > > > First i declare the exchange:
> > > > > > > > 
> > > > > > > > private static final String EXCHANGE\_NAME = "nameko-rpc";
> > > > > > > > 
> > > > > > > > Then after further tries i declare the exchange :
> > > > > > > > 
> > > > > > > > Channel channel = connection.createChannel();
> > > > > > > > 
> > > > > > > > channel.exchangeDeclare(EXCHANGE\_NAME, "topic", true);
> > > > > > > > 
> > > > > > > > Finally i publish my message directly to the exchange and not the requestQueueName ...found the code on RabbitMQ for Publish/Subscribe , section EmitLog client [RabbitMQ tutorial - Publish/Subscribe — RabbitMQ](https://www.rabbitmq.com/tutorials/tutorial-three-java.html)
> > > > > > > > 
> > > > > > > > channel.basicPublish(EXCHANGE\_NAME, "", props, message.getBytes());
> > > > > > > > 
> > > > > > > > The message is a string to the nameko service.methode\_name as it : crawler.scrapit()
> > > > > > > > 
> > > > > > > > I see the message in the RabbitMQ console management, no more the ack .
> > > > > > > > 
> > > > > > > > I have a log in my nameko service but nothing prints in the Terminal... as if the service is not hit
> > > > > > > > 
> > > > > > > > Le dimanche 4 mars 2018 22:54:06 UTC+1, Matt Yule-Bennett a écrit :
> > > > > > > > 
> > > > > > > > > On Sunday, March 4, 2018 at 8:30:23 PM UTC, lauren...@gmail.com \>\>\>\>\>\>\>\> wrote:
> > > > > > > > > 
> > > > > > > > > > Thanks.
> > > > > > > > > > 
> > > > > > > > > > In my client, after
> > > > > > > > > > 
> > > > > > > > > > channel = connection.createChannel();
> > > > > > > > > > 
> > > > > > > > > > replyQueueName = channel.queueDeclare().getQueue();
> > > > > > > > > > 
> > > > > > > > > > I've added this line
> > > > > > > > > > 
> > > > > > > > > > channel.queueBind( replyQueueName , "nameko-rpc", "reply\_to");
> > > > > > > > > 
> > > > > > > > > Have you bound your reply queue with the \*literal value\*  
> > > > > > > > > "reply\_to"? That won't work. It needs to be the value that you've specified  
> > > > > > > > > in the "reply to" header in your request message. In your case that's  
> > > > > > > > > replyQueueName.
> > > > > > > > > 
> > > > > > > > > > But same results... the client is stil blocking
> > > > > > > > > > 
> > > > > > > > > > \<snip\>
> > > > > > > > > > 
> > > > > > > > > > So the queue would be 'rpc-crawler' right?
> > > > > > > > > 
> > > > > > > > > That is correct, yes. If it wasn't correct you would not see the  
> > > > > > > > > request message being ack'd by your service.
> > > > > > > > > 
> > > > > > > > > > Laurent
> > > > > > > > > > 
> > > > > > > > > > Le dimanche 4 mars 2018 20:57:35 UTC+1, Matt Yule-Bennett a écrit :
> > > > > > > > > > 
> > > > > > > > > > > The RPC reply queue must be bound to the `nameko-rpc` exchange.  
> > > > > > > > > > > The reply message is published to that exchange with the 'reply\_to' as the  
> > > > > > > > > > > routing key; if you haven't bound the reply queue to the correct exchange,  
> > > > > > > > > > > the reply message will be discarded by the broker as not matching any  
> > > > > > > > > > > routes.
> > > > > > > > > > > 
> > > > > > > > > > > Correlation ID has nothing to do with routing messages. It's only  
> > > > > > > > > > > used to match replies up with requests so a client can have multiple  
> > > > > > > > > > > requests in flight at the same time.
> > > > > > > > > > > 
> > > > > > > > > > > On Sunday, March 4, 2018 at 6:37:01 PM UTC, lauren...@gmail.com \>\>\>\>\>\>\>\>\>\> wrote:
> > > > > > > > > > > 
> > > > > > > > > > > > The problem is before the correlationId.
> > > > > > > > > > > > 
> > > > > > > > > > > > In the Java source code that is handleDelivery which blocks
> > > > > > > > > > > > 
> > > > > > > > > > > > Le dimanche 4 mars 2018 19:25:01 UTC+1, lauren...@gmail.com a  
> > > > > > > > > > > > écrit :
> > > > > > > > > > > > 
> > > > > > > > > > > > > Yes but in my Java client i manage the replyQueue  
> > > > > > > > > > > > > I Use correlationId.  
> > > > > > > > > > > > > I started from the Java code in RabbitMQ RPC/Java/CorrelationId  
> > > > > > > > > > > > > section  
> > > > > > > > > > > > > [https://github.com/rabbitmq/rabbitmq-tutorials/blob/master/java/RPCClient.java](https://github.com/rabbitmq/rabbitmq-tutorials/blob/master/java/RPCClient.java)
> > > > > > > > > > > > > 
> > > > > > > > > > > > > In my RabbitMQ management page i see the message sent from  
> > > > > > > > > > > > > client , the Publisher confirm, and the ack now
> > > > > > > > > > > > > 
> > > > > > > > > > > > > As you say maybe it's a problem with the reply queue, and error  
> > > > > > > > > > > > > in my client  
> > > > > > > > > > > > > Laurent
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Le dimanche 4 mars 2018 12:48:11 UTC+1, Matt Yule-Bennett a  
> > > > > > > > > > > > > écrit :
> > > > > > > > > > > > > 
> > > > > > > > > > > > > > An ack for the request message means that it was received and  
> > > > > > > > > > > > > > processed without any error, including sending the reply.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > The reply message is almost certainly being published but not  
> > > > > > > > > > > > > > routed to the appropriate reply queue. Looking at your code... is your  
> > > > > > > > > > > > > > reply queue bound to the RPC exchange? If not, that's your problem.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > On Sunday, March 4, 2018 at 11:43:49 AM UTC, \>\>\>\>\>\>\>\>\>\>\>\>\> lauren...@gmail.com wrote:
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > I only see a ack on the RabbitMQ management page... i see my  
> > > > > > > > > > > > > > > message sent  
> > > > > > > > > > > > > > > I do not see answer in the reply queue  
> > > > > > > > > > > > > > > I think the entrypoint is hit because there is an ack, but i  
> > > > > > > > > > > > > > > do not understand why the replied message is not sent

[Next page](https://discourse.nameko.io/t/calling-a-nameko-service-from-a-java-client/242.md?page=2)