The problem is that this variable is not shared between workers. And connected users in the one worker are not visible in another.

Ok, thats, easy, use a database for IPC, store all the messages in a database, then all the workers can get messages from this database (or service)

Then it doesn't matter which worker the clients are connected to, they all get messages from database

This is arranged by poling, see https://metacpan.org/pod/Mojolicious::Guides::Cookbook#Timers

So something like this (maybe with more smaller events ->on and what not)

use Mojo::IOLoop;
my $clients = {};
my $lasttime = time;
Mojo::IOLoop->recurring(
    1 => sub {
        if ( my( $newMessages, $time ) = GetNewFromDb($lasttime) ) {
            $lasttime = $time;
            for my $msg (@$newMessages) {
                MsgToClients( $msg, $clients );
            }
        }
    },
);
websocket '/echo' => sub {
    ...
    $self->receive_message(
        sub {
            my ($self, $msg) = @_;
  
            MsgToDb( $self, $msg ); 
## NO ##    MsgToClients( $self, $msg , $clients ); ## NO
        },
    );
    ...
};
sub GetNewFromDb {
    my( $lasttime ) = @_;
    ...
    my $time = eval { $last_message->{time} };
    return $messages, $time;
}
[download]

instead of $lasttime being time based, might be better to use last_insert_id of some sort from the database or some such .... details :)

update: found the converstation

http://irclog.perlgeek.de/mojo/2013-06-26#i_7255079

20:15     ghandi     Hi There! I've been playing around with the Mojo 
+WebSocket Chat-Example from https://github.com/kraih/mojo/wiki/Writi&
+#8203;ng-websocket-chat-using-Mojolicious-Lite
20:15         And now i'm wondering: Do i realy need to keep track of 
+the clients myself in %clients? Wouldn't it be cooler to just use a c
+ustom event that i emit on a new incoming message?
20:16     gtodd     hmm
20:17         define "cooler" :-)
20:17         Anyway maybe you could answer questions about Mojo on St
+ackoverflow and become famous :)
20:17         there's one up there about websockets ...
20:17         for me cooler would be "faster"
20:18     ghandi     cooler like more slick 'n sexy. Like let the Even
+t-System take care of the Client-Management since it already knows ab
+out the connections
20:18     gtodd     POE could be sexy but Mojo-POE I don't know
20:20     sri     ghandi: no, in fact, that example is not very good t
+o begin with
20:20         doesn't scale past one process
20:20     gtodd     ghandi: what you just described seems too easy or 
+obvious
20:21         oops hehe  I agree with sri
20:21     sri     it's a minimal example, anything serious needs a bac
+kend like redis pub/sub
20:21     gtodd     ghandi: btw. I meant too obvious or easy because i
+t makes sense to me and I am usually wrong :-)
20:22     ghandi     so in my case: I'm thinking about some live-intar
+action page, where multiple people whatch the page while a single per
+son sends in some updates. For this i need a dedicated "collaboration
+"-Server to which mojo talks?
20:26     btyler     like sri said, redis with pub/sub is precisely th
+at 'middle person' that multiple mojo processes can talk to
20:27     ghandi     But don't i loose then the event-driven part of t
+he Websockets? The client then has to poll the app which then will lo
+okup on redis?
20:28     sri     i think Mojo::Redis is actually battle tested now wi
+th wirc using pub/sub too
20:30         batman: Mojo::JSON uses render_json in the example
20:30         Drossel joined #mojo
20:31     bek     ghandi: /quit
20:33     ghandi     sri: Mojo::Redis looks interesting. So just to ge
+t something right: The Mojo-Event-System is Process-Based, right? Whi
+ch means: Client A on $PID 1 can't talk to Client B on $PID 2?
20:34     sri     that's how everything in perl works
20:35     ghandi     Ok, thanks ;)
[download]

So there is the context, use Mojo::Redis - Asynchronous Redis client for Mojolicious. somehow

Redis - Perl binding for Redis database

Redis is an open-source, networked, in-memory, key-value data store with optional durability. It is written in ANSI C. The name Redis means REmote DIctionary Server The Publish/Subscribe feature is fully implemented, so a client of a slave may SUBSCRIBE to a channel and receive a full feed of messages PUBLISHed to the master,