You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
RpcClient is a good fit for one-off RPCs. However for a one-off use one has to remember to close the RpcClient otherwise, the channel will retain the consumer forever and when the channel is used some time later for another one-off RPC, the new and old consumer will collide.
It sure would be nice to have some support with not-forgetting this. I for one certainly need it.
Describe the solution you'd like
The preferred way to remind developers to call the close method surely would be to make RpcClient implement Closeable or at least AutoCloseable if we truly do not want the close method to be idempotent (I cannot imagine why we would want that, but maybe there's a reason it's written as non-idempotent now).
Describe alternatives you've considered
Implementing the try-with-resources-construct I want to use by writing the appropriate try-finally-block myself. This is a. ugly and b. error-prone, because it's one of the cases where one needs an extra layer of try-catch inside the finally-block. Of course I can look up what the correct pattern is, but we force that onto users?
Additional context
No response
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
RpcClient
is a good fit for one-off RPCs. However for a one-off use one has to remember to close theRpcClient
otherwise, the channel will retain the consumer forever and when the channel is used some time later for another one-off RPC, the new and old consumer will collide.It sure would be nice to have some support with not-forgetting this. I for one certainly need it.
Describe the solution you'd like
The preferred way to remind developers to call the
close
method surely would be to makeRpcClient
implementCloseable
or at leastAutoCloseable
if we truly do not want theclose
method to be idempotent (I cannot imagine why we would want that, but maybe there's a reason it's written as non-idempotent now).Describe alternatives you've considered
Implementing the try-with-resources-construct I want to use by writing the appropriate try-finally-block myself. This is a. ugly and b. error-prone, because it's one of the cases where one needs an extra layer of try-catch inside the finally-block. Of course I can look up what the correct pattern is, but we force that onto users?
Additional context
No response
The text was updated successfully, but these errors were encountered: