Highlighted
Established Member..
Established Member..
360 views

SM 9.41 web client constant pings?

Jump to solution

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?

0 Likes
1 Solution

Accepted Solutions
Highlighted
Micro Focus Expert
Micro Focus Expert

Re: SM 9.41 web client constant pings?

Jump to 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.

View solution in original post

10 Replies
Highlighted
Super Contributor.
Super Contributor.

Re: SM 9.41 web client constant pings?

Jump to solution

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

Global Support Delivery Software Support Expert

If you find that this or any other post resolves your issue, please be sure to mark it as an accepted solution.
If you are satisfied with anyone’s response please remember to give them a KUDOS by clicking on the STAR at the bottom left of the post and show your appreciation.
Highlighted
Micro Focus Expert
Micro Focus Expert

Re: SM 9.41 web client constant pings?

Jump to solution

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?

0 Likes
Highlighted
Absent Member.. Absent Member..
Absent Member..

Re: SM 9.41 web client constant pings?

Jump to solution

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

0 Likes
Highlighted
Established Member..
Established Member..

Re: SM 9.41 web client constant pings?

Jump to solution

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?

0 Likes
Highlighted
Super Contributor.
Super Contributor.

Re: SM 9.41 web client constant pings?

Jump to solution

Hello,

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

 

Best Regards

LPP

Global Support Delivery Software Support Expert

If you find that this or any other post resolves your issue, please be sure to mark it as an accepted solution.
If you are satisfied with anyone’s response please remember to give them a KUDOS by clicking on the STAR at the bottom left of the post and show your appreciation.
0 Likes
Highlighted
Established Member..
Established Member..

Re: SM 9.41 web client constant pings?

Jump to solution

Can you give me an example?

0 Likes
Highlighted
Super Contributor.
Super Contributor.

Re: SM 9.41 web client constant pings?

Jump to solution

Hello,

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

Best Regards

LPP

Global Support Delivery Software Support Expert

If you find that this or any other post resolves your issue, please be sure to mark it as an accepted solution.
If you are satisfied with anyone’s response please remember to give them a KUDOS by clicking on the STAR at the bottom left of the post and show your appreciation.
0 Likes
Highlighted
Established Member..
Established Member..

Re: SM 9.41 web client constant pings?

Jump to solution

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.

0 Likes
Highlighted
Micro Focus Expert
Micro Focus Expert

Re: SM 9.41 web client constant pings?

Jump to 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.

View solution in original post

Highlighted
Outstanding Contributor.. Outstanding Contributor..
Outstanding Contributor..

Re: SM 9.41 web client constant pings?

Jump to solution

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

 

The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.