Mattermost, Inc.

[Solved] Submitting new message remains gray

Hello all,

I’m not sure how best to describe this. I upgraded to Mattermost 3.0, and when I hit enter, the post has the “spinner” to the right, but the spinner never resolves. If I reload, all is well. Obviously this seriously slows down the flow.

Edits and responses appear unaffected.

Any thoughts?

Hi @Tarek, is this occurring on every post? We did fix a similar issue in Mattermost v3.1 which is scheduled to release tomorrow (June 16th). Maybe you can try upgrading to that to see if it resolves your issue.

Please also make sure your WebSocket is connecting correctly. Without the WebSocket, Mattermost will not work correctly.

Thank you for this. I suspect that you’re right and the websockets are the problem. I am configured via apache, so I will look to see if I can find a proper guide for configuring with that. I will report back findings.

Hi @jwilander!

After several hours, I have the following update:

  • I have moved my MM to a secure SSL via Apache using this configuration, which works well.
  • I no longer get any websockets errors.
  • I upgraded to 3.1.0 yesterday
  • I am testing using both firefox and chromium on GNU/Linux

Despite this, I still get the “spinner”. Of note, the spinner only happens on new messages, not on replies.

Hmmm, can you check a few things for me to help debug?

  1. On Chrome, please open the Developer Console and go to the Network tab, filter by WS (websocket) then go the Frames tab
  • Looking to make sure that frames are coming through no problem
  • If it’s working correctly it should look something like this
  1. Can you check your Mattermost server logs for errors?
  2. Does refreshing the page have the posts stop pending?
  3. When you upgraded to v3.1.0 did you use a release candidate (RC)? If so which one?

You are correct that the problem seems to be from websockets.In the error log for apache, I see:

[Wed Jun 15 17:00:39.470705 2016] [proxy:warn] [pid 16801] [client x.x.x.x:57356] AH01144: No protocol handler was valid for the URL /api/v3/users/websocket. If you are using a DSO version of mod_proxy, make sure the proxy submodules are included in the configuration using LoadModule.

I’m not entirely sure what to do with this. Here’s my current apache SSL file, using let’s encrypt:

<VirtualHost x.x.x.x:443>
ServerName my.mattermost.org
SSLCertificateFile /etc/letsencrypt/live/my.mattermost.org/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/my.mattermost.org/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf

ProxyPreserveHost On
ProxyRequests Off

RewriteEngine On
RewriteCond %{REQUEST_URI} ^/api/v3/users/websocket [NC,OR]
RewriteCond %{HTTP:UPGRADE} ^WebSocket$ [NC,OR]
RewriteCond %{HTTP:CONNECTION} ^Upgrade$ [NC]
RewriteRule .* ws://127.0.0.1:8065%{REQUEST_URI} [P,QSA,L]
RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
RewriteRule .* http://127.0.0.1:8065%{REQUEST_URI} [P,QSA,L]
RequestHeader set X-Forwarded-Proto "https"

  <Location /api/v3/users/websocket>
    Require all granted
    ProxyPassReverse ws://127.0.0.1:8065/api/v3/users/websocket
    ProxyPassReverseCookieDomain 127.0.0.1 my.mattermost.org
  </Location>

  <Location />
    Require all granted
    ProxyPassReverse https://127.0.0.1:8065/
    ProxyPassReverseCookieDomain 127.0.0.1 my.mattermost.org
  </Location>
</VirtualHost>

OK, this has been resolved.

I resolved my issue using advice from this thread. In essence, It required the addition of the mod_proxy_wstunnel. In Jessie, I did it with:

sudo a2enmod proxy_wstunnel

The configuration is as above.

1 Like