nsqlookupd: inactive #ephemeral topics

[fredhuang9Street]

Hello,

I would like to ask this problem that it shows "Below is a tree of Topics/Channels that are currently inactive (i.e. not produced on any nsqd in the cluster but are present in the lookup data)" in the nsqadmin lookup page when I use ephemeral topic or I delete the topic manually.

I developed by golang, and use nsq.NewConsumer to create a consumer, and then connectToNSQD.

I was wondering if I use the wrong function so that it shows the alert in lookup page, and how should I do to avoid this warning?

Thank you very much

Fred

[ploxiln]

I think this is an issue with ephemeral topics - they'll end up in nsqlookupd, and later be automatically cleaned up from nsqd, but remain in nsqlookupd. It's not a huge problem, but I guess we should try to think of what we can do about it. This would be an nsqd/nsqlookupd issue btw.

[mreiferson]

I've never observed this issue and use #ephemeral topics/channels extensively — @fredhuang9Street can you provide any more information that might help us debug this? e.g. your NSQ cluster configuration and topology, nsqd, nsqlookupd, and nsqadmin logs?

[fredhuang9Street]

Hello,

I developed by golang. and there is the part of my code below,

after connect to nsqd,
this is the streams page.

and I disconnect it by the following code

this is the stream page after disconnection.

this is the lookup page after disconnection.

this is the log after disconnection

Please tell me if you need more information

Thanks

[mreiferson]

thanks! can you provide the command line arguments (or configuration file) to nsqd and nsqadmin?

It looks like you're connecting nsqadmin (and consumer) directly to nsqd, I'd like to confirm that.

[fredhuang9Street]

Hello,

This is the way I start nsq service.

and it connects to 192.168.192.145:4150 which is the nsq server address directly.

I'm not sure what information you need. Could you kindly tell me the exact way or where can I find the information for you since I'm not really familiar with it.

you mentioned that you didn't observe this issue. I would like to know is the way I did is wrong?
or how can I avoid this issue?

Thanks,

[ploxiln]

The --lookupd-tcp-address=0.0.0.0:4160 is odd and not recommended - when listening, "0.0.0.0" means "listen on all interfaces/addresses". When connecting, I think it is just wrong, you probably want "127.0.0.1:4160"

[mreiferson]

fixed in #1116, thanks for the report!