Reputation: 23
Actioncable subscribe leads to this error in production:
/home/[app]/.rbenv/versions/jruby-9.4.1.0/lib/ruby/gems/shared/gems/actioncable-6.1.6.1/lib/action_cable/connection/stream_event_loop.rb:74
ArgumentError: mode not supported for this object: r
register at org/nio4r/Selector.java:122
It's working in development, and also locally in production. But, as I figured out, production on a external server has stricter requirements: 'identified_by :current_user' is necessary there.
As I don't think "importmaps" does help, I simply added the actioncable.js javascript file which would be imported with the extra additionally importmaps and attached it like a normal js file. This also works in development and locally in production, hence I assume the problem to be independent of that.
The last logfile entry is created at the end of:
application_cable/connect.rb
But in development the next log entry is: Registered connection (Z2lkOi8vcmVjbHVlL1VzZXIvMQ)
And in development I also can see, that module ApplicationCable class Channel gets called. But it doesn't in production.
Locally redis-cli monitor reports:
1741170206.642863 [1 127.0.0.1:60792] "select" "1"
1741170206.645384 [1 127.0.0.1:60792] "client" "setname" "ActionCable-PID-205601"
1741170206.646141 [1 127.0.0.1:60792] "subscribe" "_action_cable_internal"
1741170206.647203 [1 127.0.0.1:60792] "subscribe" "[app]_development:action_cable/Z2lkOi8vcmVjbHVlL1VzZXIvMw"
1741170206.648451 [1 127.0.0.1:60792] "subscribe" "[app]_development:messages_channel_3"
in production the last the final subscription is missing:
1741168655.771025 [1 127.0.0.1:34326] "SELECT" "1"
1741168655.771083 [1 127.0.0.1:34326] "CLIENT" "SETNAME" "ActionCable-PID-20413"
1741168655.772064 [1 127.0.0.1:34326] "subscribe" "_action_cable_internal"
1741168655.772582 [1 127.0.0.1:34326] "subscribe" "[app]_production:action_cable/Z2lkOi8vcmVjbHVlL1VzZXIvMQ
Next MessagesChannel def subscribed never gets called. What is 'object :r' ?
Anybody any clue? Thanks!
Upvotes: 1
Views: 57
Reputation: 23
it's a bug.
But the situation causing it can be avoided by using tcp instead of unix for upstream:
config/puma.rb
bind "unix://#{shared_dir}/sockets/puma.sock"
has to be
bind "tcp://0.0.0.0:9292"
nginx/conf/nginx.conf
upstream app {
server unix:///var/www/reclue/shared/sockets/puma.sock fail_timeout=0;
}
has to be
upstream app {
server 0.0.0.0:9292;
}
all problems of instability, like they are described in several discussions, disappear. In addition this proves that importmaps is not making anything better. So avoid making things more complicated and simply import js-files directly.
Upvotes: 0