nsqd: create Topic paused

[ploxiln]

Enables simplifications. Experimental, not fully tested.

Alternative to #1049. cc @mreiferson

[mreiferson]

Yea, this is definitely better, thanks. It's still pretty gnarly, but I'm not sure how much it's worth messing with it.

[ploxiln]

I should probably do some real testing :P

[ploxiln]

Initial testing looks good, as expected.

I wonder if there might be some potential for confusion due to this change ... maybe if some script creates a topic then immediately pauses it, that could happen before the automatic un-pause and the the topic could unexpectedly end up unpaused. Or something like that. I don't want to be paranoid about this, just something to keep in mind.

On the other hand, I like how this reduces how long topic locks are held. Though I guess it's a one-time thing.

As a further digression, I know you thought may be a good idea to make a NewTopic() that takes channels to pre-create. While that would work for loading metadata, I think that wouldn't work for the runtime-created topics. We would still need some kind of lock for multiple clients (http or tcp) touching the same new topic around the same time. We probably would not want to hold the nsqd lock while querying nsqlookupds, so we'd add a sub-lock ... so we might as well create the topic and use it for coordination ;)

[mreiferson]

I wonder if there might be some potential for confusion due to this change ... maybe if some script creates a topic then immediately pauses it, that could happen before the automatic un-pause and the the topic could unexpectedly end up unpaused. Or something like that. I don't want to be paranoid about this, just something to keep in mind.

That's an interesting edge case. It probably means we're abusing paused state when what we really need is tighter control over internals of topic creation, e.g. if we moved starting of topic.messagePump outside of NewTopic (into some Start() func) then we can control when that goro launches and not need to use pausing as a hack?

[ploxiln]

Yeah I think that's a good idea - instead of a special first "UnPause", have a separate "Start".

[ploxiln]

The tricky bit there is that Topic.Pause() and Topic.GetChannel() currently block until messagePump() consumes the notification (or until the exitChan is closed).