SM 9.41 web client constant pings?

[antz]

Hello,

on a SM 9.41 system (9.41 app, 9.41p1 web, 9.41p1 server) after I login to a web client, there is a constant 'ping' to the server like every 15 seconds. Customer network admins are not happy about this, they think it should not happen or at least not so often. What is this and how can it be modified?

[PLP]

Hello,

In the Web Client in the web.xml file you have a refresh message interval setup to 15 seconds

<!-- Number of milliseconds between message refresh check -->
<param-name>refreshMessagesInterval</param-name>
<param-value>15000</param-value>
</init-param>

Please try to setup to another value and restart the Web Client to check if the new value is take in account.

Best Regards

LPP

[dmitch]

Yes, you can change the heartbeat interval - and by this the interval for on screen message.

Looking at it from user's perspective: Often even 15 seconds is a long time to wait for an message - I'm already one click ahead.

So I think it is required to balance requirements here: So what exactly is the concern of the admin regarding a short periodic message every 15 seconds?

[HPRB]

Hello Antz,

This looks like heartbeatinterval which has default value of 15sec. You can check the sm.ini file for parameter heartbeatinterval, this param controls the client heartbeat frequency. If the server does not receive a heartbeat from the client within the time-out limit as defined by the sessiontimeout parameter, the server terminates the client. All unsaved data is lost and the client must establish a new connection. Pease check online help to get more information.

Hope this helps,

Rama

[antz]

Thank you, it looks like this is the cause (refreshMessagesInterval).

What messages is this trying to refresh from the server? The ToDo queue, the ToDo alerts or something else?

[PLP]

Hello,

All messages that need to be displayed to the end user in the web client.

Best Regards

LPP

[antz]

Can you give me an example?

[PLP]

Hello,

An internal is waiting or Interaction record updated when you do a save in an intercation or anything like that.

Best Regards

LPP

[antz]

when you do a save in an intercation

Doing a save the message is coming instantly not in 15 seconds or more with the adjusted setting.

[brettalanchristlieb · Accepted solution]

These are Service Manager heartbeats.

In Service Manager clients there are heartbeat mechanisms in place for every client connection that pings every 15 seconds by default. The heartbeat can be seen as the  <getMessages> items that appear in the sm.log when HTTP POST messages are sent from the browser if the "debughttp" parameter is enabled: 

e.g. service.do?name=getMessages&timestamp=1245783775554 

The heartbeat is implemented in two areas that are independent of one another and are not synchronized:

1) Between the browser and the app server hosting our Web Client.  This "heartbeat" does two things:

a) responsible for displaying Service Manager (SM) server messages that have been retrieved by the Web client to the user (e.g. 'ticket 123456 has been updated')

b) simulates activity between browser and Web Client so as not to prematurely timeout the user based on the web.xml <session-timeout> value. It is a common misconception that users will be timed out based on whatever the value of <session-timeout> in web.xml is. This is not true because the heartbeat simulates activity that prevents web.xml's <session-timeout> executing.

2) Between the application server hosting our web client and the Service Manager server. This heartbeat maintains the session established by the server to service the web client requests. This heartbeat simulates activity between Web Client and server so as not to prematurely timeout the user based on sm.ini's sessiontimeout value.

FIG.1 heartbeats implementation

       |                                   |                                      |
       |<----------- hb 1 ---------- >|<--------- hb 2 ---------------->|
       |                                   |                                      |
    browser               Web Client                                SM
    
    topaz.js          web.xml (refreshMessages/interval)    sessiontimeout
    tpzRefresh()    web.xml (<session-timeout>)             inactivity timer

                                                                                heartbeatinterval
                          

When a user exits their browser (by File>Exit or hitting X to close their browser application) so does not gracefully log out of the Web Client, the heartbeat between the browser and Web client is severed. However, the heartbeat is still alive between the Web Client and SM server. Since the browser has exited without gracefully logging out of SM, the Web Client will now wait for the value specified in <session-timeout> before sending SM server a request to end the user's session. Once the <session-timeout> value is reached, it causes the web client to timeout the user and begin clean up of it's allocated resources.

We can also rely on the SM server to identify that the user session is no longer active. We do this primarily by use of the inactivity timer RAD application.  Once the inactivity timer identifies that a user is idle for too long it kills their SM user session.  This action severs the heartbeat between SM and the Web Client in the following manner: The next time the web client (not the browser) sends the heartbeat, the SM server will respond with a “session no longer valid” message because SM has already cleaned up the user session on its side. This will cause the web client to begin clean up of its allocated resources(heartbeat/timer thread).

refreshMessages and refreshMessagesInterval in our web.xml controls the heartbeat behavior between the browser and web tier client.

[Malcolm Bell]

Here is a support article that explains this, in SM terms we call this a heartbeat.

There is a heartbeat between the browser and web tier and the SM application server, to confirm that a session still exists, is active, and can kill the web tier session when the user closes their browser. It can also disconnect users and kill the web tier session if timeouts or other administrative activities close their session. This conserves resources and licenses.

Hope that helps!

Malcolm