Want to build your own 24/7 FAQ knowledge base?
LibraryH3lp subscriptions include unlimited independent internal or public-facing knowledge bases.


Search the LibraryH3lp Knowledge Base

 

Why did I get disconnected in the webclient for staffing?!

4584 views   |   Last updated on Jan 28, 2022    webclient

 

The webclient for staffing does not have any automatic time-outs other than the user-configurable auto-logout settings

The webclient stays in constant communication with LibraryH3lp's server to make sure that the user is connected and able to respond to chats. When the webclient cannot reach the server, it sets the user to "busy" status, so that they won't be offered any brand new chats, and it tries to reconnect automatically.  If the webclient is unable to auto-reconnect within a couple of minutes, it gives up and alerts the user that it has become disconnected, so that they can login again.

As an initial step, it never hurts to clear cache and specifically LibraryH3lp cookies

If staffing from home or other location where the router is available, try power cycling the router if disconnects are otherwise not explained.

Common causes of webclient disconnects:

  • Safari. Safari throttles network connections to tabs that are minimized, and this will eventually result in a disconnect from LibraryH3lp servers. It also seems to suspend the network if the tab is not kept on top as the active tab.  If staffing in Safari, it is best to keep the webclient open in its own, non-minimized window.
  • Chrome might throttle the network to the webclient if there are a lot of tabs/windows open and the webclient is not detected as an active one. If this is happening, running the webclient in its own, non-minimized window is a good idea, or running it in its own InCognito window.
  • Using a mobile device (tablet, iPad, phone) to staff in the webclient. The device saves battery by throttling the network connection to web browser pages that are not active, so the user will get disconnected if the webclient is not on top, or becomes idle or locked.  When using a mobile device, it is better to use an XMPP app.
  • Poor network conditions. Examples: overloaded local network or ISP, dropped packets, low connectivity over wireless, oversubscribed wireless networks, and upstream problems.  
  • Computers going to sleep because of idle time. Because of browser sandboxing, this problem may manifest as the webclient appearing to be signed in when it really is not. The computer's idle process will not always communicate the closed state of the connection back to the browser. See sections below labeled "Power and Sleep Settings for PCs" and "...for Macs" for more info.
  • Switching between networks while signed in. Example: taking a laptop out of its dock to switch from a wired to a wireless network. You must sign out and back in when changing networks.
  • Signing into the admin dashboard in the same browser as a different user. This will work, but it may disrupt chat management functionality like send file, access to the integrated Activity page, access to the integrated profiles page, etc.
  • Proxy servers. A proxy server will even drop a connection in the middle of active chats. They have several problems:
    1. They don't respect the long-running connections to our server, causing the disconnects.
    2. They cache responses, which interferes with the reconnection attempts.
    3. Depending on configuration, they may also limit the number of simultaneous connections to any particular host across the network. This may cause the problem to appear only once a particular critical mass of people is signed in and/or chatting all at once, as can happen when bringing a service up live, following a successful testing period with fewer numbers of simultaneous logins.
  • Note that we are NOT concerned with proxy servers such as EZProxy. That is a different animal and does not impact chat. We are concerned with proxy servers used internally, often to boost performance on large networks.

Suggestions for users of proxy servers:

The proxy server problem often can be solved completely by increasing proxy read timeout and/or increasing the number of allowed connections to a site.

In addition to webclient disconnects, sometimes proxy servers will lead to dropped messages. It is much better to use https chat boxes with proxy servers. All generated code from the admin dashboard's chat snippet management page uses https by default. To change it by hand in older code, simply change http to https on all URLs and JavaScript calls.


Power and Sleep Settings for PCs

For Windows users, there are a couple of places to go looking for settings related to idle time and sleep/hibernate.  One is in Power & Sleep -- this shows both a summary of when to sleep and hibernate (turn off) when on battery versus plugged in, AND on some computers, it also shows a setting related to what to do about the network when the PC is asleep and on battery:

power and sleep settings network connection screenshot

The other place is in Control Panel > Hardware and Sound > Power Options.  Here you can set up power plans or change an existing power plan -- default is "Balanced".  This mostly duplicates the above Power &: Sleep but has a different user interface and a way to fine-tune some things.

power options screenshot


 

Power and Sleep Settings for Macs

The two main areas are the Energy Saver and Screensaver, both in System Preferences.

In Energy Saver, note that there are separate settings for when on battery power versus using a power adapter.

Make sure to have "Prevent computer from sleeping automatically when the display is off" checked.  Also set "Turn display off after..." to Never.

In Desktop and Screen Saver, set "Start after" to Never.

 

If the above proves insufficient, you might try the built-in Caffeinate tool in a terminal window; please read the man page for more information.  Or, you can try installing a utility that prevents the Mac from sleeping, such as Caffeine.

 

Locally-installed clients are more robust

Despite all our efforts to make the webclient as reliable as possible, it will not work well for everyone. Locally-installed clients (those installed directly on a computer rather than only running through the web browser) will always be more robust than a browser-based client because they tie into your operating system directly whereas browser-based clients are sandboxed from the operating system by the browser. You may have to use one of these.

FAQ URL:

More Help

Search By Topic

Share this FAQ