Package io.grpc

Class ServerCall.Listener<ReqT>

  • Direct Known Subclasses:
    Enclosing class:

    public abstract static class ServerCall.Listener<ReqT>
    extends Object
    Callbacks for consuming incoming RPC messages.

    Any contexts are guaranteed to arrive before any messages, which are guaranteed before half close, which is guaranteed before completion.

    Implementations are free to block for extended periods of time. Implementations are not required to be thread-safe, but they must not be thread-hostile. The caller is free to call an instance from multiple threads, but only one call simultaneously. A single thread may interleave calls to multiple instances, so implementations using ThreadLocals must be careful to avoid leaking inappropriate state (e.g., clearing the ThreadLocal before returning).

    • Constructor Detail

      • Listener

        public Listener()
    • Method Detail

      • onMessage

        public void onMessage​(ReqT message)
        A request message has been received. For streaming calls, there may be zero or more request messages.
        message - a received request message.
      • onHalfClose

        public void onHalfClose()
        The client completed all message sending. However, the call may still be cancelled.
      • onCancel

        public void onCancel()
        The call was cancelled and the server is encouraged to abort processing to save resources, since the client will not process any further messages. Cancellations can be caused by timeouts, explicit cancellation by the client, network errors, etc.

        There will be no further callbacks for the call.

      • onComplete

        public void onComplete()
        The call is considered complete and onCancel() is guaranteed not to be called. However, the client is not guaranteed to have received all messages.

        There will be no further callbacks for the call.

      • onReady

        public void onReady()
        This indicates that the call may now be capable of sending additional messages (via ServerCall.sendMessage(RespT)) without requiring excessive buffering internally. This event is just a suggestion and the application is free to ignore it, however doing so may result in excessive buffering within the call.

        Because there is a processing delay to deliver this notification, it is possible for concurrent writes to cause isReady() == false within this callback. Handle "spurious" notifications by checking isReady()'s current value instead of assuming it is now true. If isReady() == false the normal expectations apply, so there would be another onReady() callback.