Request timeout doesn't give any response

[mingfai]

apparently, when request timeout is set, the request only close the subscription without notify the caller. Should the Request provide a way to add/set a OnCloseListener/Handler?

//NatsImpl.java
@Override
    public Request request(final String subject, String message, long timeout, TimeUnit unit, final Integer maxReplies, MessageHandler... messageHandlers) {
        //...
        final ScheduledExecutorService scheduler = (channel == null) ? eventLoopGroup.next() : channel.eventLoop();
        scheduler.schedule(new Runnable() {
            @Override
            public void run() {
                subscription.close();
            }
        }, timeout, unit);
// ...

[mheath]

Without the timeout, the subscription waiting for replies can stay open indefinitely. This can cause subscription leaks on the NATS server. That is the primary reason for having the timeout.

Is there a specific use case for notifying the caller when the request timeout has expired?

[mingfai]

i try to simulate reliable messaging, use the reply to the request as an acknowledgement. if no acknowledgement, the caller may, for example, re-send a message.

as a new user to NATS, this is how I understand the use of "request". technically, the same thing can be done by using two different subjects. let's say Amy send message to Bon.

1. Amy subscribe to a reply subject first, e.g. "amy.inbox"
2. Amy send message to Bon's subject, e.g. "bon.inbox"
3. when Bon got message in his inbox, it replies by sending a message to Amy's inbox.

instead of using two subjects, the advantage of a "request flow" are:

• just like "syntax sugar" to set up a temp reply queue for an timeout interval, under the hook, it setup a temp/anonymous subject too, right?
• a practical benefit is, the receiver B can reply to an address,
  • without pre-define a receive address / can use a dynamic address
  • without putting the reply address in the message, as in protocol level, there is a no sender header to get that information (it is possible to simulate a sender header by using a subject like "amy.from.*" subject)
  • without knowing who is the sender at all

it seems to me the design of "request" should cover the acknowledgement use case. it is especially important in a fire-and-forget infrastructure. No matter it is designed with that in mind or not, a request-reply flow enable a timed reply anyway. without a timeout notification, the client can easily send a separated thread to count the time, and check Request.getReceivedReplies() to see if there are any reply. (this is my workaround right now)

As the Java client works in async manner with Netty, it is not possible to just throw an time out exception. but it is not hard to provide a listener to notify the sender a timeout has happened. does this feature make sense for java-nats?

[mheath]

I think this does make sense. I will get this implemented for the next release. Of course, pull-requests are always welcome.