CODEWITHSUNDEEP
zeromqpublish-subscribedistributed-systemjeromq
Smaillns
Smaillns

Reputation: 3147

Get Errno 48 while using Pub-Sub ZeroMQ sockets with a specific IP address other than localhost

I get the following error

Exception in thread "main" org.zeromq.ZMQException: Errno 48 : Address already in use at org.zeromq.ZMQ$Socket.mayRaise(ZMQ.java:3533) at org.zeromq.ZMQ$Socket.bind(ZMQ.java:2987) at com.zmq.pub_sub.Publisher.main(Publisher.java:16)

This is my Publisher class : 

public class Publisher {
    public static void main(String[] args) throws Exception
    {
        //  Prepare our context and Publisher
        try (ZContext context = new ZContext()) {
            ZMQ.Socket publisher = context.createSocket(SocketType.PUB);
            publisher.bind("tcp://140.93.0.95:5678");
            int id = 1;
            String msg = "";

            while (true){
            Thread.sleep(1000);
            msg = "topic1- msg"+id ;
            publisher.send(msg);
            id++;
            }
        }
    }
}

PS : I want to use ZMQ between two remote machines

Upvotes: 0

Views: 584

Answers (1)

user3666197
user3666197

Reputation: 1

For this very purpose let me direct your kind attention first to the concept:
- ZeroMQ Hierarchy in Less than Five Seconds
as have been done in an answer to your previous ZeroMQ-related question.

If you try to make a local resource manager ( right, The Context()-instance ) to .bind() onto a resource, that is non-local ( in case the tcp://140.93.0.95:5678-target is not any of the localhost interfaces ), the result must fail to work as there is none such Context() that could grab a non-local ( foreign, remote O/S owned and managed ) resource and use it. Pirates used to execute such a wild strategy to grab a foreign owned resource ( ship, gold, you name it all ) yet that practice was definitely not considered fair, nor polite, the less legal.

If you try the same, while the target-IP-address in the .bind() method is local, then your code is fair to ask for using a local-resource ( one of the localhost's interfaces, get it equipped with a tpc:// protocol data-pump ), yet your code has run into another sort of problems, related to the resources handling. Here it seems that the O/S has rejected such fair-in-a-shape request, due to wrong time to ask for having it, as the O/S has not considered the requested target being "free-to-use", most probably due to a colliding use ( if some other application has successfully acquired a use of that resource and has not released it yet back to the O/S ) or due to a post-mortem locked use of that resource, which may happen if previous ZeroMQ-application run(s) did not gracefully .close()-ed and .term()-ed any of the Context()-instances, which may still keep this resource (dead-)locked due to their wrong resource-handling/release policies.

This is a long story, yet it gets quite often onto the table, if unhandled exceptions are let to leave crashed instances that still "hold" ip-address(es) in use and cannot help themselves, as the already crashed application code cannot and will not make them release their .bind()-acquired address. Infinite ( until reboot ) semi-(dead-)lock cases are not seldom to experience, if due care is not put into the crash-proof code-designs and the locked-resources are a mildest "punishment" for such designer's sins.

Upvotes: 1

Related Questions