issue when multiple workers have the same host_id

[RobinHuang123]

I am using Socketio+uwsgi+gevent, and I found that the host_id of multiple workers is the same. When two clients connect to two different workers and join the same room, the two clients cannot communicate normally.
For example:

1. worker1 and worker2 have same host_id.
2. client A --> worker 1, client A joins room_1 in worker1
   client B --> worker 2, client B joins room_1 in worker2

client B joins room_1 in work2
client A sends a message to room_1, but client B will not receive the message.

Then I did not have this problem in version 5.7.2. When I upgraded to version 5.12.1, I encountered this problem.
In version 5.7.2, the pubsub_manager.py emit function is only responsible for publish messages, and then handles _handle_emit in the _thread function, so that multiple workers can handle it correctly regardless of whether the host_id is duplicated.

However, in 5.12.1, the pubsub_manager.py emit function does something different. The emit function sends a message, then publishes the message. In the _thread function, the message with the same host_id is no longer processed.

I currently use lazy-apps=true in uwsgi to ensure that each worker has a different host_id, thus bypassing this problem.
However, I think the 5.7.2 version handles this problem better.
Looking forward to your reply.

[miguelgrinberg]

Multiple worker processes are not supported, and never were. Not sure how you were able to make things work in the past, but this was never a supported usage. If you need to use multiple workers, the way I have been always been suggesting is to start several single-worker processes, and then put a load balancer such as Nginx in front of them.

The difference in how emits are handled between the two versions is correct. When using a recommended deployment of multiple workers, the old method was inefficient, in that the clients that were in the same host that issued the emit had to wait for the emit message to go into the queue and back into the same host. This inefficiency has been removed in later versions, and hosts now process their own messages directly, without relying on the queue. The queue is only used to communicate the emit to the other hosts. Running multiple hosts with the same host_id is not really viable, in spite of you having found a loophole that made things work with the old versions.

[RobinHuang123]

Thank you very much for your reply.

I agree that the efficiency is higher in version 5.12.1, but it is more dependent on host_id.

However, in the uwsgi environment, it is generally preferred to use multiple workers.

In this case, if we delay the calculation of host_id, we can ensure that different workers have different host_ids. In this way, we can support multiple workers.

My rough solution is to use property to implement it without affecting other existing logic.

Solution 1:

def __init__(self, ...)
    self.__host_id = None

@property
def host_id(self):
        if self.__host_id is None:
              self.__host_id = uuid.uuid4().hex
        return self.__host_id

In this solution, in the case of multi-threading, self.__host_id may be repeatedly assigned in multiple threads.

Solution 2:

def __init__(self, ...)
       self.__host_id = uuid.uuid4().hex

@property
def host_id(self):
      return f'{self.__host_id}::{os.getpid()}'

This solution should support multiple workers and avoid the potential problems in Solution 1.

In other environments, users can also override ‘’def host_id“ as needed.

Finally, thank you again for your reply.

[miguelgrinberg]

I agree that the efficiency is higher in version 5.12.1, but it is more dependent on host_id.

The point of the host_id is to identify each host. Having the same host_id on all hosts would mean that a host_id is not necessary. As I said above, you've found that in your own particular configuration things work without the need of valid and unique host IDs. Try using callbacks, for example, and you'll realize your application is broken when used in this way, both in current and older releases.

However, in the uwsgi environment, it is generally preferred to use multiple workers.

Both uWSGI and Gunicorn support multiple workers, but they use a load balancer that is very limited. Their load balancers are incompatible with the long polling mechanism used by Socket.IO. Again, I understand that you've found a way to make things work in spite of the limitations, but this is not a general solution.

[RobinHuang123]

Yes, you are right. the callback depends on the host_id both in current and older releases.
I will consider starting several single-worker processes, and then put a load balancer such as Nginx in front of them.