A zmq subscriber unable to subscribe to the published messages if socket.send() was used only once

Question

A zmq subscriber fails to subscribe to the message if socket.send() is used only once in publisher.

Subscriber was able to subscribe to the messages when the following code is used in publisher:

var zmq = require('zmq')
  , sock = zmq.socket('pub')

sock.bindSync('tcp://127.0.0.1:3000');
var message = {"test" : true};
setInterval(function(){
    sock.send(['notify_anomaly', JSON.stringify(message)]);
},1000);

But it doesn't work if setInterval is removed in the publisher code, as follows:

var zmq = require('zmq')
  , sock = zmq.socket('pub')

sock.bindSync('tcp://127.0.0.1:3000');
var message = {"test" : true};
sock.send(['notify_anomaly', JSON.stringify(message)]);

Answer 1

Well, not exactly, Sir.

Historically,
ZeroMQ used a SUB-side subscription ( topic-filtering ). That means two things. PUB-lisher has zero knowledge of who SUB'ed to what & spends Zero-effort on topic-filter processing. Plus, it pours and has to do so, all messages onto all diverse transport-class channels down the road, towards ( only down-there topic-filtering ) SUB-scribers ( which principally creates some level of inefficiency on the transport-layers resources ).

So, if your code uses "old" ZeroMQ wrapper / language-binding, your "PUB-lisher" is out of question not the root-cause of the problem, as it by-design does not care about any, including "late-SUBscriber", counterparties. The time-delay helps ( not the PUB.send(), but the

// unknown SUB code, a default SUB-state is TOPIC-FILTER throws everything, YES !
//                                                       THROWS EVERYTHING AWAY
SUB.setsockopt( zmq.SUBSCRIBE,
                "<some_TOPIC_FILTER_string_to_be_used_after_this_happens_in_time"
                );

So this has nothing to do with the code per-se on the PUB side, Q.E.D., but designers have to bear the timing-coincidences in mind, if designing robust app-architectures.

Next,
the newer ZeroMQ versions have switched to PUB-side filtering. This seems as a major change, but it does not have any great implications into your example.

PUB-side filtering has just removed the transport-layer congestions by centralised topic-filtering on the PUB-side, at a cost of sum-of-(so-far-cheap-'cause-distributed)-workloads, that now reside, concentrated, on the PUB-side.

So, your observation still shows not receiving any message on SUB-side, so why going into such details? Well, now, in the case of the newer version, if the SUB did not manage to "tell & deliver" it's SUB-scription preferences to the PUB-side, before that one had already dispatched the PUB.send( aFirstMESSAGE_to_Those_whom_I_know_they_SUBed_to_this_TOPICFILTER ) there would be no music down the road at all, again, due to timing-coincidence of the distributed system events' propagation & delivery in time and not due to a PUB-side ( only ) code tweaking.

Epilogue:

In either case, ZeroMQ is a broker-less messaging framework. That means, persistence of messages is not even intended to create, nor provided. Each of the Scaleable Formal Communication Pattern's behavioural archetype node has clearly specified in API-documentation, buffer-management and message-{ retain | discard } and other rules. Be sure to check also the different versions of ZeroMQ low-level protocol, that is being used on all nodes of your distributed system realm ( typically one cannot control that, but may design version-aware behavioral policy enforcements to handle this sort of production ecosystem uncertainties ).

The
Best
Next
Step:

If one strives to remain some time in an area of a professional design of distributed systems, the best thing one can do is to read the fabulous book from one of the ZeroMQ fathers, Pieter HINTJENS ( may check other post on ZeroMQ and follow the direct link to the book's PDF-version ).