TryRpc

Realice lotes de solicitudes RPC.

Esta operación realiza de forma asincrónica una sola solicitud RPC o un lote de solicitudes. Las solicitudes de RPC se definen mediante tres parámetros principales:

- `address` (el host + puerto o dirección BNS de la solicitud) -` method` (el nombre del método para la solicitud) - `request` (la cadena proto serializada, o vector de cadenas, del argumento de solicitud RPC).

Por ejemplo, si tiene un servicio RPC ejecutándose en el puerto localhost: 2345, y su interfaz está configurada con la siguiente declaración de proto:

service MyService {
   rpc MyMethod(MyRequestProto) returns (MyResponseProto) {
   
 };
 }

, llame a esta operación con argumentos:

address = "localhost:2345"
 method = "MyService/MyMethod"
 

El tensor `request` es un tensor de cadena que representa` MyRequestProto` serializado instrumentos de cuerda; y el tensor de cadena de salida `response` tendrá la misma forma y contendrá (una vez completado con éxito) las cadenas serializadas correspondientes de` MyResponseProto`.

Por ejemplo, para enviar un único `MyRequestProto` vacío, llame a esta operación con` request = "" `. Para enviar 5 solicitudes vacías paralelas , llame a esta operación con `request = [" "," "," "," "," "]`.

De manera más general, se puede crear un lote de protos serializados `MyRequestProto` a partir de tensores por lotes regulares usando la operación` encode_proto`, y convertir la respuesta protos serializados `MyResponseProto` en tensores por lotes usando la operación` decode_proto`.

NOTA Trabajar con proto strings serializadas es más rápido que instanciar objetos proto reales en la memoria, por lo que no se espera una degradación del rendimiento en comparación con la escritura de kernels personalizados para este flujo de trabajo.

A diferencia de la operación estándar `Rpc`, si la conexión falla o el trabajador remoto devuelve un estado de error, esta operación no vuelve a generar la excepción. En su lugar, la entrada `status_code` y` status_message` para la llamada RPC correspondiente se establece con el error devuelto por la llamada RPC. El tensor de "respuesta" contendrá valores de respuesta válidos para aquellas entradas de minibatch cuyas RPC no fallaron; el resto de las entradas tendrán cadenas vacías.