{"id":4411,"date":"2010-05-21T06:04:58","date_gmt":"2010-05-21T10:04:58","guid":{"rendered":"http:\/\/www.ezrasf.com\/wplog\/?p=4411"},"modified":"2010-05-20T17:16:01","modified_gmt":"2010-05-20T21:16:01","slug":"chat-connection-resets","status":"publish","type":"post","link":"https:\/\/www.ezrasf.com\/wplog\/2010\/05\/21\/chat-connection-resets\/","title":{"rendered":"Chat Connection Resets"},"content":{"rendered":"

Sorry, this was originally supposed to be published a few weeks ago. I’m just getting around to posting it. – Ezra<\/em><\/p>\n

Tests after applet patch in development reported chat failures. Chat uses an applet, so I was concerned and investigated the problem. The usual culprits were not affected.<\/p>\n

    \n
  1. setEnv.sh had\u00c2\u00a0WEBCT_CONFIG_OPTIONS set to start chat on correct nodes.<\/li>\n
  2. customconfig\/ChatServer-config.xml had SSL key in correct location.<\/li>\n
  3. SSL key was the correct key.<\/li>\n
  4. SocketServer logs were not rolling every minute.<\/li>\n<\/ol>\n

    So chat looked correctly setup on our end.<\/p>\n

    On the web server nodes where chat runs, I changed directory into the logs directory. Now that I looked in SocketServer logs for a web node running chat, I noticed some lines had “user” in them. I guessed the value after user was the id in the person table\u00c2\u00a0for the user who experienced the error. It was easy enough to look for that id in the database and confirm my guess.<\/p>\n

    This first grep of SocketServer log isolates the sixth item between colons teases which is that person id. The second grep reports the whole line including the time stamp.<\/p>\n

    grep “[0-9]-user” SocketServer.??????????.log | awk -F\\: ‘{print $6}’ | sort | uniq
    \ngrep “[0-9]-user” SocketServer.??????????.log<\/p><\/blockquote>\n

    With the results of the first grep just above, replace the numbers in bold with a comma delimited list.In the database I looked for these ids with this SQL. Substitute your own id numbers in bold. They turned out to be the id numbers for users experiencing the problems. I recognized the accounts as people who had been testing.<\/p>\n

    \n
    select lc.name, p.webct_id, p.id from person p, learning_context lc<\/div>\n
    where p.learning_context_id = lc.id\u00c2\u00a0and p.id in (99999,999999<\/strong>)<\/div>\n
    order by lc.name, p.webct_id<\/div>\n
    \/<\/div>\n<\/blockquote>\n
    Since I was researching just on one environment and a development one at that, I was curious<\/div>\n
    about the two kinds of errors:<\/div>\n
    \n
      \n
    1. Connection reset<\/li>\n
    2. Session aborted by remote peer.<\/li>\n<\/ol>\n<\/div>\n

      It looked like in production still had some of the same errors. The one session I profiled appeared to show the errors in chat start about 2 hours after the last action by the user in the webserver.log. This is the time the TCP profile cuts off the chat.<\/p>\n

      The cause of these more frequently on development in chat turned out to chat having a 5 minute profile instead of the correct 2 hour one. Now everything is consistently having this problem when users let their sessions expire.<\/p>\n

      Hopefully they are just leaving their windows open on personal computers and not public spaces.<\/p>\n","protected":false},"excerpt":{"rendered":"

      Sorry, this was originally supposed to be published a few weeks ago. I’m just getting around to posting it. – Ezra Tests after applet patch in development reported chat failures. Chat uses an applet, so I was concerned and investigated the problem. The usual culprits were not affected. setEnv.sh had\u00c2\u00a0WEBCT_CONFIG_OPTIONS set to start chat on […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"activitypub_content_warning":"","activitypub_content_visibility":"","activitypub_max_image_attachments":4,"activitypub_interaction_policy_quote":"anyone","activitypub_status":"","footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":false,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2}},"categories":[22],"tags":[],"class_list":["post-4411","post","type-post","status-publish","format-standard","hentry","category-bbvista"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/p1rUBW-199","jetpack-related-posts":[],"jetpack_likes_enabled":true,"_links":{"self":[{"href":"https:\/\/www.ezrasf.com\/wplog\/wp-json\/wp\/v2\/posts\/4411","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.ezrasf.com\/wplog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.ezrasf.com\/wplog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.ezrasf.com\/wplog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.ezrasf.com\/wplog\/wp-json\/wp\/v2\/comments?post=4411"}],"version-history":[{"count":0,"href":"https:\/\/www.ezrasf.com\/wplog\/wp-json\/wp\/v2\/posts\/4411\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.ezrasf.com\/wplog\/wp-json\/wp\/v2\/media?parent=4411"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.ezrasf.com\/wplog\/wp-json\/wp\/v2\/categories?post=4411"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.ezrasf.com\/wplog\/wp-json\/wp\/v2\/tags?post=4411"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}