Blazemeter / CitrixPlugin

A repository for the Citrix Plugin for JMeter
Apache License 2.0
11 stars 2 forks source link

Sample error SESSION_ERROR: The user session was not in the expected state. #76

Open Madeppa opened 4 months ago

Madeppa commented 4 months ago

Hi,

Some of the users fail to launch the ‘Citrix Application Launcher’ when number of users in the test is set to more than 15.

If I run the test with less than 15 users, then all users can initialize and complete the test without any issue. However, when number of users are increased to 25 then few users(3-4 users) fail to initialize or fail to launch the citrix client.

I am running the test in command mode.

The following did not resolve the issue. • Increasing user ramp-up period • Increasing delays in-between steps • Changed below setting in user properties. o bzm.citrix.client_factory.client_property.connect_timeout_ms=600000 o bzm.citrix.client_factory.client_property.logon_timeout_ms=600000 o bzm.citrix.client_factory.client_property.activeapp_timeout_ms=600000 o bzm.citrix.client_factory.client_property.icafile_timeout_ms=600000 o jmeterengine.threadstop.wait=600000

Error Details

ERROR c.b.j.c.s.CitrixBaseSampler: Sample error SESSION_ERROR com.blazemeter.jmeter.citrix.sampler.SamplerRunException: The user session was not in the expected state at com.blazemeter.jmeter.citrix.sampler.CitrixBaseSampler.handleClientAction(CitrixBaseSampler.java:162) ~[citrix-jmeter-0.7.6.jar:?] at com.blazemeter.jmeter.citrix.sampler.CitrixBaseSampler.sample(CitrixBaseSampler.java:268) [citrix-jmeter-0.7.6.jar:?] at org.apache.jmeter.threads.JMeterThread.doSampling(JMeterThread.java:651) [ApacheJMeter_core.jar:5.6.3] at org.apache.jmeter.threads.JMeterThread.executeSamplePackage(JMeterThread.java:570) [ApacheJMeter_core.jar:5.6.3] at org.apache.jmeter.threads.JMeterThread.processSampler(JMeterThread.java:501) [ApacheJMeter_core.jar:5.6.3] at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:268) [ApacheJMeter_core.jar:5.6.3] at java.base/java.lang.Thread.run(Thread.java:829) [?:?] Caused by: com.blazemeter.jmeter.citrix.client.CitrixClientException: The user session was not in the expected state at com.blazemeter.jmeter.citrix.client.windows.WinCitrixClient.startSession(WinCitrixClient.java:310) ~[citrix-jmeter-0.7.6.jar:?] at com.blazemeter.jmeter.citrix.client.AbstractCitrixClient.start(AbstractCitrixClient.java:390) ~[citrix-jmeter-0.7.6.jar:?] at com.blazemeter.jmeter.citrix.sampler.StartApplicationSampler.doClientAction(StartApplicationSampler.java:97) ~[citrix-jmeter-0.7.6.jar:?] at com.blazemeter.jmeter.citrix.sampler.CitrixBaseSampler.handleClientAction(CitrixBaseSampler.java:160) ~[citrix-jmeter-0.7.6.jar:?] ... 6 more

3dgiordano commented 4 months ago

Hi @Madeppa

The problem is Citrix Workspace, it does not support high concurrency per machine (level of connections and traffic sent per communication channel). And also it's possible from Citrix Server (exist a limit of sessions allowed per machine or per user) Some versions of Citrix Workspace, when they exceed 15 sessions, begin to have communication problems and begin to leave sessions hanging (either the client loses the connection or the Citrix server disconnects them).

The manual specifies that no more than 10 concurrent sessions per machine are recommended.

https://github.com/Blazemeter/CitrixPlugin/blob/master/MANUAL.md#configure-test-plan-for-load-simulation

In order to perform load simulations of hundreds or thousands of users, it must be scaled horizontally. We have carried out this type of tests with Citrix's Private Location solution provided by BlazeMeter, which allows the tests to be horizontally scaled. It requires building hundreds of machines in which around 15 concurrent sessions are generated in each one (although our recommendation if using more recent versions of workspace is not to exceed 10, given that the more modern the version, the more demanding the network is and the more fragile the load tests become)

When load testing is carried out, there are also errors that begin to occur in Citrix services that require adjustment and require administrator participation. It is part of the work of fine tuning the servers, but it requires understanding what is behind these errors on the part of the client when not being able to start a session (you have to go to the Citrix servers and a performance engineering with experience in Citrix and its administration must analyze).

For the session in incorrect state error, you must have access to the view of active sessions on the servers and be able to send them to close if they are in an incorrect state. Someone with administrative powers can do it.

For those who do not have access to these types of tools, you can also first run a test against all users and test in the first cycle which ones give an error and in the second cycle see if there is any account that still has that problem and with that exclude them. When our Citrix client detects a session in an invalid state, it sends the server to close the session and in many cases it manages to close that session from the client. That is why the cycle of 2 logins, in the first cycle it is about solving those who gave an error, and in the second cycle it is verified that they could be closed correctly. If in the second cycle that same account has problems again, it is something to report to the administrator (sometimes there are failures in the Windows server, creating corrupt user profiles that prevent using that user until an administrator sends to recreate that user's profile). .

There are many things to consider, but I just wanted to comment on the limitation that we have detected in Citrix Workspace and issues to consider on the part of the Citrix servers and their limit controls configured by the server (these are things to consider, try to adjust or try to find a way to avoid with an alternative path).

I hope this information will be useful.

Madeppa commented 4 months ago

Hi @3dgiordano,

Thank you for your reply!!!

Since Citrix generally does not allow the same user to simultaneously run the same application. So, we are triggering each user as a separate jmeter session from command line.

We created the test plan with below command for 25 users. However, the main jmeter citrix workflow script is ‘CreateOrderScript.jmx’ in ‘F:\Scripts’ folder.

F:\JMeter\bin\jmeter -n -t "F:\Scripts\CreateOrderScript.jmx" -JvUsers=${citrix_login_1} -l F:\Results\JTL\CreateOrder.jtl -j F:\Results\Logs\CreateOrder.log image image

Below is the actual script: image image

However, are launching the user as a separate individual jmeter session in command mode, it works fine for up to 15 users. After 15 users few of the users open a Citrix application as UI mode like in below screenshot. This user session is opened all the time in test and it won’t close automictically. Ultimately this user fails as a SESSION_ERROR. Somehow the jmeter plugin is not able to recognize this user and its making as fail. image

Appreciate your response.

3dgiordano commented 4 months ago

Hi @Madeppa

You have to diagnose the cause of those hung sessions. One of the possible causes of sessions remaining unclosed is that jmeter, by default, when the test execution finishes, waits very little time for the thread to be released correctly and performs a forced kill. (you can see in the logs the data from jmeter that mention the foced kill) That is what can cause client sessions not to be closed (that executions on taskbar). If the server does not have time to close the session and notify the client, the client is left hanging.

Try increasing the wait timeout for thread completion, in user.properties or jmeter.properties

jmeterengine.threadstop.wait=90000

In any case, what this should solve is waiting for the sessions to close correctly, which can help you leave the sessions in a better state if they were left hanging on the server due to some other type of disconnection.

Disconnection and sessions remaining in an invalid state when you exceed 15 is something that must be analyzed with a Citrix engineer, because it is something that Citrix makes the decision to not allow more sessions than it can handle.