Durable subscription not receiving more messages

[harold-toledo]

I have a console app that subscribes to a subject/topic using a durable subscription, as part of my testing I was constantly stopping and starting the app and I was getting all the messages that were published while the app was down, as expected from a durable subscription. One day I stopped the app and since then when starting it again I have not been able to receive any more messages, even though messages are being published to that subject/topic, and I am sure of it because I have another app subscribing to the same subject/topic using a different client that is receiving them.

The following is some data I got from the monitoring endpoint on my cluster:

{
"client_id": "dc-dev-streaming-to-fluentd_HTOLED-BH64062-buytelco-com",
"inbox": "_INBOX.93PXC0KQT5A3IWUNNOF818",
"ack_inbox": "_STAN.ack.bv-cluster.dc.dev.falcon-windows-service.offer.created.Souo0W4QWFVSlTjrT83kdf",
"queue_name": "Streaming-To-Fluentd:Streaming-To-Fluentd",
"is_durable": true,
"is_offline": false,
"max_inflight": 1024,
"ack_wait": 30,
"last_sent": 138578,
"pending_count": 0,
"is_stalled": false
}

The fact that the "is_offline" property is set to false indicates that the server is aware of the subscription from the client, hence my question, why is the server not delivering the messages to that subscription? Any clue or something I can do in my side to avoid or solve this issue?

[ColinSullivan1]

Would you be able to run the streaming server with the debug (-SD) parameter and provide the output?

CC @kozlovic

[MGEHub]

I think I have the same issue too. When I use a simple console app with simple example everything seems ok but on my actual code with the same configurations it's somehow erratic when durable name is set. I went through the STAN's client code and saw that it doesn't get any callback from internal nats connection's subscription:

inboxSub = sc.NATSConnection.SubscribeAsync(inbox, sc.processMsg);

internal void processMsg(object sender, MsgHandlerEventArgs args)
{
bool isClosed = false;
AsyncSubscription sub = null;
Msg raw = null;

        MsgProto mp = new MsgProto();
        ProtocolSerializer.unmarshal(args.Message.Data, mp);

        raw = args.Message;

        lock (mu)
        {
            isClosed = (nc == null);
            subMap.TryGetValue(raw.Subject, out sub);
        }

        if (isClosed || sub == null)
            return;

        sub.processMsg(mp);
    }

It seems that some delay or time dependent issue is causing this.

[harold-toledo]

I have not experienced this anymore, and I am almost convinced now that what I was experiencing was not caused by anything related to the platform. My particular case involve durable queue groups and after some time I realized that I was using the same subject+queue for my local testing than the instances of the application running in our development environment, so my guess is that most probably all the other messages were being delivered to the other instances running in the development environment.

[MGEHub]

So I guess that's not the same issue. Thanks for clarifying this.

[ColinSullivan1]

I'm closing this for now, please re-open if this remains an issue.