Part I: " Is there something wrong in my code? " :
No, the ZeroMQ use-case code seems trouble-free.
Feel free to add as many debugging tracepoints into the MCVE-source as needed on the hunt, so as to document in detail, where it gets and what actual ZMQError()
gets reported on the fly:
[ 'EADDRINUSE', # L3
'EADDRNOTAVAIL', # L3
'ECONNREFUSED', # L3
'ENETDOWN', # L1 / L2 / L3
'ENODEV', # L1
'EFAULT',
'EFSM', # ZMQ Finite State Machine not in a state to obey this
'EAGAIN', # ZMQ Context() blocked
'EINPROGRESS',
'EINVAL', # ZMQ did not recognise a valid value in param
'EMTHREAD',
'ENOBUFS', # resources
'ENOMEM', # resources
'ENOCOMPATPROTO', # ZMQ protocol-handshaking
'EPROTONOSUPPORT', # ZMQ protocol
'ENOTSOCK', # ZMQ resource - not recognised as an "own" socket
'ENOTSUP', # ZMQ cannot support a request
'ETERM', # ZMQ Context() already entered into a .term()-state
...
]
Part II: " How could I adjust my setting in AWS? " :
This part is a bit tricky.
First, consult your contracted parameters. If AWS operator does not permit you to initiate TCP/IP-services among instances, no other step but a contract renegotiation ( selecting other, less restricted product ) may help.
In case TCP/IP-services are not blocked, consult with the AWS operator Support line, what port-numbers are permitted on respective instances. Operating system, besides the operator policies mentioned above, may have some further restricted port-number ranges and if your application uses an O/S-blocked <transport-class>://<address>:<port#>
( being == 1111
in the use-case MCVE above ), any attempt will systematically fail right due to attempt to use a forbidden resource ( changing the <port#>
being the easiest remedy, isn't it? ).
For any other cases, the ZMQError
will help you diagnose the root-cause of the operations blocked. Feel free to add as many debugging tracepoints as needed on the hunt.