RTE E GetPreference DOS attack detected! occurs frequently in logs

The error

RTE E GetPreference DOS attack detected! Session will be terminated.

occurs very frequent for one servlet only (horizontal scaled system).


sm.cfg: sm -httpPort:13091 -httpsPort:13092 -sslConnector:1 -ssl:0

The message occurs more than 4000 times within 5 hours:

RTE E GetPreference DOS attack detected! Session will be terminated.

Check when the servlet was started by searching for string Initializing ProtocolHandler :

6361(  6361) 03/01/2019 15:16:09 Initializing ProtocolHandler [“http-nio-13091”]
6361(  6361) 03/01/2019 15:16:09 Initializing ProtocolHandler [“http-nio-13092”]


6361(  6361) 03/01/2019 15:16:09 Failed to initialize end point associated with ProtocolHandler [“http-nio-13092”]
java.net.BindException: Address already in use
at sun.nio.ch.Net.bind0(Native Method)
at sun.nio.ch.Net.bind(Net.java:433)
at sun.nio.ch.Net.bind(Net.java:425)
at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
at org.apache.tomcat.util.net.NioEndpoint.bind(NioEndpoint.java:350)
at org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:810)
at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:476)
at org.apache.coyote.http11.AbstractHttp11JsseProtocol.init(AbstractHttp11JsseProtocol.java:120)
at org.apache.catalina.connector.Connector.initInternal(Connector.java:960)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:102)
at org.apache.catalina.core.StandardService.initInternal(StandardService.java:568)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:102)
at org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:871)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:102)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:135)
at org.apache.catalina.startup.Tomcat.start(Tomcat.java:347)
at com.hp.ov.sm.tomcat.EmbeddedTomcat.main(EmbeddedTomcat.java:421)
6361(  6361) 03/01/2019 15:16:09 Failed to initialize connector [Connector[HTTP/1.1-13092]]
This error tells us that the httpPort:13092 did NOT successfully start. It means only the plain HTTP (httpPort) started successfully.
It means that any client attempting to connect will not be able to because you have enabled TLS/SSL and TSO in SM.

The Cause of this issue is because 

java.net.BindException: The address is already in use

This indicates that on a previous shutdown of this servlet, the port 13091 did not shutdown properly.

To find out the time of shutdown of a servlet, search for the string
Stopping ProtocolHandler

You might need to monitor the sm_<pid>_stdouterr.log files for additional clues.

The https port (in our example 13092) is not free and still bound to some process(es) at the time the servlet was started up.

Why does the “DOS attack” error come up?

When SM load balancer forwards a request to this servlet, it does so first to httpPort to exchange the GetPreference SOAP message, then it will automatically switch to httpsPort.
This switch over to https did not occur in 10 seconds as the httpsPort did not start at all!

To Fix this issue


Before you start a servlet you need to check that no processes are bound to the ports anymore.

1) Check the server (linux in our example) for any processes still bound to this https port.

2) Stop that processes.

3) Start the servlet

4) Check log file for message

Initializing ProtocolHandler

In our example this message should come up for both ports, http and https :

Initializing ProtocolHandler [“http-nio-13091”]
Initializing ProtocolHandler [“http-nio-13092”]

You should not see these messages:

Failed to initialize end point associated with ProtocolHandler [“http-nio-13092”]
java.net.BindException: Address already in use

For future monitoring:

Monitor the logs on startup to ensure no messages of below type occur to prevent this type of issue:

Failed to initialize end point associated with ProtocolHandler

If you see those types of error strings, you must immediately shut down this servlet,  check to make sure all bound ports are unbound, then start up the servlet again.


Marquee not displayed in IE

Marquee in format sc.manage.ToDo.g is displayed in windows client and in web client with Firefox. But IE does not display the marquee (banner) .


Steps to reproduce:

A) Prepare login form to add a simple marquee field

1. command fd
2. format sc.manage.ToDo.g
3. Design
4. add a field of type Marquee
5. Save the format

B) Test with different browsers

1. login to Web Client with Firefox – the marquee is displayed
2. login to Web Client with IE – the maruqee is not displayed

The problem is a setting in IE options:

IE Internet Options
Play animations in webpages* = true
Restart browser before testing again.

This solution is described here:
https://stackoverflow.com/questions/10527528/marquee-is-not-showing-in-internet-explorer :

As several people have observed that the marquee text works on IE, I suspect that this is about a setting on the IE you are using. At least if I go to Internet settings, Advanced settings, under Multimedia there is a checkbox for allowing animations. Apparently marquee is counted as animation in this sense, since when I checked the checkbox off (it is on by default) and restarted IE, the marquee text is not there (not even as static text).


Worker machine error referring to “dockerd”

In general, the worker machines are working correctly, but they are presenting the following error
dockerd: time=”2019-01-29T22:29:32.451238492-05:00″ level=warning msg=”containerd:
unable  to save 008f4389030eea47e9b8a306cfca1f2fa3a45689336b967f02291aef8422ab42:f0e52fe2e76259219fe1c8d8831bc2503e0e4a94aa088a2e4dbd6941801bd055 starttime: read /proc/22054/stat: no such process”.

This problem will occur once a pod is restarted/delete/create and there were pending actions by dockerd script while the pod is terminating any pending processes will be terminated and if the actions completed prior the processes are killed to close all pending references could potentially try to complete an action into a process that no longer exist and will fail with the warning message. Since this is a warning and NOT an error message it’s important to monitor if pods are constantly restarting because restart should occur occasionally and not in a consistent basis.

Display ALM tray icon after stopping installation of patch 1 for ALM 12.6

To restore the ALM tray icon:

  1. Cut and paste the conf folder from C:\ProgramData\Micro Focus\ALM to C:\ProgramData\HP\ALM.
  2. Edit <ALM Installation folder>\scripts\RunALMTrayIcon.bat. Modify the following:

    set InstallLocation=<ALM Installation folder>

    set TrayMain=com.hp.alm.platform.trayicon.ALMTrayIconMain

  3. Run the bat file.

Run time error “Server Error in ‘LoadTest’ Application.” when we click on test

Run time error “Server Error in ‘LoadTest’ Application.” is observed when we click on scenario both in My Performance Center and DesktoClient version 12.56 .

The full error message is:

Server Error in ‘/LoadTest’ Application.

Runtime Error
Description: An application error occurred on the server. The current custom error settings for this application prevent the details of the application error from being viewed remotely (for security reasons). It could, however, be viewed by browsers running on the local server machine.

Details: To enable the details of this specific error message to be viewable on remote machines, please create a <customErrors> tag within a “web.config” configuration file located in the root directory of the current web application. This <customErrors> tag should then have its “mode” attribute set to “Off”.

<!– Web.Config Configuration File –>

<customErrors mode=”Off”/>
image text
The test can be edited but in the summary tab the error message appears.

The issue is observed when analysis template and/or resource monitors which were deleted from the project are used it the problematic test.

To overcome the issue the missing analysis template and/or resource monitors should be removed from the test.

1. If the test is using a deleted analysis template the options are in the test to choose another analysis template or the default analysis template by following the steps below:

Click on a problematic test
Click on Edit test button
In test window select Advanced-> Analysis Template Options
In the Analysis Template Options select:
Use default Analysis Template
Click on OK
Save the test

2. If the test is using a deleted monitor the missing monitor need to be removed from to test or substituted it with an existing monitor.

To delete a Monitor please follow the steps below:

Click on Associated Monitors tab
Select the missing Monitor
Click on Remove Selected
To add an existing monitor

Click on Associated Monitors tab
Select “Add Monitor Profile” or “Add Monitor OFW”
Select the Monitor from Select Monitors part of the screen.

Tests fail due to low resolution using Lab Service (SSE) with auto-login feature

Automated tests failing, usually due to object not found in application under test

The ALM Lab Service, using the auto-login functionality, will establish a remote session on the host machine.

The native resolution of the session is determined by the video drivers used on the physical machine or virtual machine.

In some cases this causes a lower than normal screen resolution such as 800×600 which causes UFT to not locate the objects on the screen of the application under test.

To fix this upgrade and/or configure new video drivers on the physical box or VM which support the screen resolution established when the automated test was recorded using UFT.

Make sure the native resolution provided by the video drivers supports the same resolution when the test was recorded.

To set the resolution use: https://social.msdn.microsoft.com/Forums/azure/en-US/1c215514-aeef-41d9-b47b-5c838a0bf83f/how-to-change-the-vm-default-screen-resolution?forum=WAVirtualMachinesforWindows

The Docker image names which are displayed by default in Performance Center Administration (under Orchestration) are misspelled

In the Docker Images tab in Orchestration, the predefined image names below are misspelled, and the images do not actually exist until they have been pulled from Docker hub into the local orchestrator.
1. performancetesting/load_generator_linux:12.60
2. performancetesting/load_generator_win:12.60

To fix this issue
1. Delete the default images, and then create new images as follows:

For a Dockerized Linux 12.60 Load Generator image:
1. Image Name: performancetesting/load_generator_linux
2. Image Type: UNIX (not Linux as in predefined image)
3. Purpose: Load Generator
4. Image Tag: 12.60

For a Dockerized Windows 12.60 Load Generator image:
1. Image Name: performancetesting/load_generator_windows
2. Image Type: Windows
3. Purpose: Load Generator
4. Image Tag: 12.60

2. Pull the images from your Orchestrator node (Swarm/Kubernetes). For example:

Docker pull performance testing/load_generator_windows:12.60