calling a nameko service from a Java client

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):
    name = "crawler"

    @rpc
    def scrapit(self):
        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 {

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

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

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

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

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

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

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

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

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

        return response.take();
    }

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

    //...}

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

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 and
Issues · nameko/nameko · GitHub.

···

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):
    name = "crawler"

    @rpc
    def scrapit(self):
        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 {

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

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

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

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

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

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

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

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

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

        return response.take();
    }

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

    //...}

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

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

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

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

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

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

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

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

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

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():

    with ClusterRpcProxy(CONFIG) as rpc:

        result = rpc.crawler.scrapit()

if __name__ == '__main__':

  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):

    name = "crawler"

    @rpc

    def scrapit(self):

        print("Received a request send response")

        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

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

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

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

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

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

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

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

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

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

1 Like

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

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

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

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

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

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

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 {
    ConnectionFactory factory = new ConnectionFactory();
    factory.setHost("localhost");
    Connection connection = factory.newConnection();
    Channel channel = connection.createChannel();

    channel.exchangeDeclare(EXCHANGE_NAME, "topic", true);

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

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

    channel.basicPublish( EXCHANGE_NAME, "", props, message.getBytes("UTF-8"));
    System.out.println(" Sent '" + message + "'");

    channel.close();
    connection.close();
} catch (TimeoutException ioe) {
    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

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

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

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:
    name = "service"

    @rpc
    def method(self, a, b, c="C", d="D"):
        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

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

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

<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;
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:
    name = "service"

    @rpc
    def method(self, a, b, c="C", d="D"):
        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

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

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

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

my service is now
class Crawler(object):
    name = "crawler"
        
    @rpc
    def scrapit(self, a, b, c='C', d='D'):
        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:
    name = "service"

    @rpc
    def method(self, a, b, c="C", d="D"):
        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

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

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

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;

···

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;
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;
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:
    name = "service"

    @rpc
    def method(self, a, b, c="C", d="D"):
        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

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

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

Congratulations, your client is working.

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

my service is now
class Crawler(object):
    name = "crawler"
        
    @rpc
    def scrapit(self, a, b, c='C', d='D'):
        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:
    name = "service"

    @rpc
    def method(self, a, b, c="C", d="D"):
        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

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

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

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):
    name = "crawler"
        
    @rpc
    def scrapit(self, a, b, c='C', d='D'):
        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:
    name = "service"

    @rpc
    def method(self, a, b, c="C", d="D"):
        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

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

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