walterddr commented on code in PR #10322:
URL: https://github.com/apache/pinot/pull/10322#discussion_r1126714732


##########
pinot-query-runtime/src/main/java/org/apache/pinot/query/mailbox/MailboxService.java:
##########
@@ -50,21 +55,51 @@
   int getMailboxPort();
 
   /**
-   * Look up a receiving mailbox by {@link MailboxIdentifier}.
-   *
-   * <p>the acquired {@link ReceivingMailbox} will be constructed if not exist 
already, but it might not have been
-   * initialized.
+   * Return a {@link ReceivingMailbox} for the given {@link MailboxIdentifier}.
    *
    * @param mailboxId mailbox identifier.
    * @return a receiving mailbox.
    */
   ReceivingMailbox<T> getReceivingMailbox(MailboxIdentifier mailboxId);
 
   /**
-   * Look up a sending mailbox by {@link MailboxIdentifier}.
+   * Same as {@link #getReceivingMailbox} but this would return null if the 
mailbox isn't already created.
+   */
+  @Nullable
+  ReceivingMailbox<T> getReceivingMailboxIfPresent(MailboxIdentifier 
mailboxId);
+
+  /**
+   * Return a sending-mailbox for the given {@link MailboxIdentifier}. The 
returned {@link SendingMailbox} is
+   * uninitialized, i.e. it will not open the underlying channel or acquire 
any additional resources. Instead the
+   * {@link SendingMailbox} will initialize lazily when the data is sent for 
the first time through it.
    *
    * @param mailboxId mailbox identifier.
+   * @param deadlineMs deadline in milliseconds, which is usually the same as 
the query deadline.
    * @return a sending mailbox.
    */
-  SendingMailbox<T> getSendingMailbox(MailboxIdentifier mailboxId);
+  SendingMailbox<T> getSendingMailbox(MailboxIdentifier mailboxId, long 
deadlineMs);
+
+  /**
+   * A {@link ReceivingMailbox} for a given {@link OpChain} may be created 
before the OpChain is even registered.
+   * Reason being that the sender starts sending data, and the receiver starts 
receiving the same without waiting for
+   * the OpChain to be registered. The ownership for the ReceivingMailbox 
hence lies with the MailboxService and not
+   * the OpChain. There are two ways in which a MailboxService may release its 
references to a ReceivingMailbox and
+   * the underlying resources:
+   *
+   * <ol>
+   *   <li>
+   *     If the OpChain corresponding to a ReceivingMailbox was closed or 
cancelled. In that case,
+   *     {@link MailboxReceiveOperator} will call this method as part of its 
close/cancel call. This is the main
+   *     reason why this method exists.
+   *   </li>
+   *   <li>
+   *     There can be cases where the corresponding OpChain was never 
registered with the scheduler. In that case, it
+   *     is up to the {@link MailboxService} to ensure that there are no leaks 
of resources. E.g. it could setup a
+   *     periodic job to detect such mailbox and do any clean-up. Note that 
for this case, it is not mandatory for
+   *     the {@link MailboxService} to use this method. It can use any 
internal method it needs to do the clean-up.
+   *   </li>
+   * </ol>
+   * @param mailboxId
+   */
+  void releaseReceivingMailbox(MailboxIdentifier mailboxId);

Review Comment:
   IMO.
   
   1. `MailboxService` ALWAYS owns the `MailboxContentStreamObserver` (and thus 
the `GRPCReceivingMailbox`)
       - Throughout the interaction of the GRPC layer, both the mailbox grpc 
stub (`GRPCMailboxServer.open`) and the `MailboxReceiveOperator` will access 
`MailboxService.getReceivingMailbox` and thus we cannot transfer the ownership 
of the receiving mailbox to the mailbox operator (e.g. delete it from the cache)
   2. `MailboxReceiveOperator` DOES NOT OWN the observer. thus it should ONLY 
call method to interact with mailbox via mailboxService. This means:
       - it should not be acquiring any Receiving mailbox object, rather it 
should only use the APIs to get contents out of the receiving mailbox. 



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscr...@pinot.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@pinot.apache.org
For additional commands, e-mail: commits-h...@pinot.apache.org

Reply via email to