zmsg | small program for sending messages via zcash encrypted memo | Runtime Evironment library

You need to dig further to work out what is leaking the memory.

Run your application under valgrind, once you are at the point you think the memory is being leaked, break the execution and valgrind should report all possible leaks. Hopefully the real leak should stand out as it will be large and obvious.

Other things to try would be reducing the HWM's to 1 for all sockets and see if that makes a difference. It could be that the memory leak is just ZeroMQ using the buffers (set by HWM). Linux will not always return the memory to the heap if its freed unless it is needed elsewhere.

Finally thanks to ZeroMQ's architecture you could very easily split your application into two, then your PUB and SUB would be separate and narrow down the leak further.

Yes, several ways.

a ) use a tandem of simplex archetypes: PUSH/PULL writes and PULL/PUSH reads
b ) use a tandem of simplex archetypes: (X)PUB/(X)SUB writes and (X)SUB/(X)PUB reads

Well, this observation is related more to the actual socket-archetype, some of which indeed require a mandatory two-step ( hardwired inside their internal FSA-s ) sequencing of .recv()--.send()--...

Well, here the challenge starts: ZeroMQ was since its initiation designed as principally zero-sharing so as to foster performance and independence. Zen-of-Zero is interesting design principle in distributed-system design.

Yet, recent re-design efforts have presented in API 4.2+ a will to achieve ZeroMQ socket Access-points to become thread-safe ( which goes against the initial principle of share-nothing ), so if going to experiment in this direction, your may arrive in territories, that work, but at a cost of decline from Zen-of-Zero.

ZeroMQ Socket Access-point(s) should never be shared, even if possible, because of design purity.

Better equip such class with another pair of simplex PUSH/PULL-s, if you strive for separation of OOP-concerns, but your head-end(s) of such read-only-specialised + write-only-specialised sockets will have to handle the cases, when a "remote" ( beyond the foreign class-boundary of abstraction ) ZeroMQ Socket-archetype FSA and it's settings and performance tweaking and error-state(s) and the "remote" class will have to arrange all such plus mediate all message-transfers to/from the native ZeroMQ-socket ( which is principally isolated and hidden for both of the head-end ( specialised ) classes ).

In any case, doable with due design care.

An idea of:

If your needs are exactly as expressed above, a just a change of the ZeroMQ Scalable Formal Communication Archetype pattern is enough.

If you opt to keep as close as possible to the REQ/REP "similarity", use XREQ/XREP, if having more to say and planning for some further extending the distributed signalling/messaging services infrastructure, better use a tandem of single-direction hoses C->S + S->C using a pair of PUSH/PULL + PUSH/PULL.

A PAIR/PAIR might be an option if a messaging paradigm can live with just one, exclusive, pair of nodes, where PAIR/PAIR ( as implemented ) does not provide a way to later expand to .connect() into N:1 or 1:M or N:M peer-nodes framework.

I don't see the definition of sender in Packet. I assume it is defined as a private instance variable?

The design indeed needs to be fixed. By having the Packet class do the sending, the design violates the Single responsibility principle. There should be a separate (possibly abstract) class that prepares the data to be sent (prepares a java.nio.Buffer instance) and it can have one or more sub classes, one of which returns a java.nio.ByteBuffer instance.

A separate class that gets a Buffer and performs the sending. This (possibly abstract) class can have sub classes for the different sending platforms and methods.

then, you need another class that implements the Builder pattern. Clients that wish to send packets, use the builder to specify concrete Packet and Sender (and possibly other needed properties, like a socket number) and then call send() that does the sending.

The code has a number of potential issues:

• An answer may be received before the call to retryHolder#put.
• Possibly there is a race condition when messages are retried too.
• If two messages are sent to the same address the second overwrites the first?
• Send always wastes time with a sleep, use a wait+notify instead.

I would store a class with more state instead. It could contain a flag (retryIfNoAnswer yes/no) that the retry handler could check. It could provide waitForAnswer/markAnswerReceived methods using wait/notify so that send doesn't have to sleep for a fixed time. The waitForAnswer method can return true if an answer was obtained and false on timeout. Put the object in the retry handler before sending and use a timestamp so that only messages older than a certain age are retried. That fixes the first race condition.

EDIT: updated example code below, compiles with your code, not tested:

According to the API, http://api.zeromq.org/4-2:zmq-term, it will block when there's still messages to transmit. This suggests that you other machine or process, the one that will open the REP socket; isn't running.

A REP socket must send a reply before it can receive again. If you're just wanting a 1 way communication you might be better using a PUB & SUB.