Client response issues with Citrix

[mmsantiago]

Good day everyone! We are having an issue that I hope someone can assist with. We currently use TM1 version 9.0 SP3 (9.0.3.173) on a Windows 2003 server. For some time we were experiencing periods where the server would basically freeze. Upon investigation it appears that there is a problem that causes the TM1 server to not receive the client response in some cases, whereby the client's thread continues to hold up the resource lock on the TM1 server. To get around this problem, we instituted the "ReceiveProgressResponseTimeoutSecs" parameter to terminate the client connection if the server did not detect the client application's response within a specified time. This worked brilliantly.

Recently, however, we began having some of our WAN users sign in to TM1 via Citrix due to response time issues. This has worked wonderfully with one exception. The parameter we instituted above, does not appear to work in the Citrix environment. In fact, I found the issue stated in our help files that in some particular situations, such as TM1 clients under a Citrix environment, the response from the client application never arrives back at the TM1 server. This causes the server to wait for an infinite amount of time, resulting in a system lockup since the client thread is never released. Because they are logged in through Citrix, having them disconnect or close Excel does not appear to release it and we are forced to recycle the server.

So my question is, is this issue with Citrix related to the version of TM1 we are running? If so, does anyone know in what version this problem has been corrected (or if it has been corrected at all)? If not, is there a workaround? I plan to look through the version docs to see if I can find it, but wanted to put it to the community as well.

Appreciate any information! Thanks

[Steve Vincent]

Michelle, i think you may have misinterpreted the help file. We have a very similar setup here and this is pasted form our help docs;

ReceiveProgress ResponseTimeoutSecs Optional

When the TM1 server is performing lengthy operations for a client, periodic "progress" messages are sent to the TM1 client application. The client responds to these messages with an indication of whether the user has pressed the Cancel button, in which case the lengthy operation is terminated. These responses are generated automatically by the network code in the client application; there is no user interaction involved. After sending the progress message the server waits for a response from the client application. As the server is waiting, the client’s thread will continue to hold resource locks on the TM1 server, preventing other users from making other server requests which require the same resource locks.

In some particular situations, most notably running TM1 clients under a Citrix environment, the response from the client application never arrives back at the TM1 server, causing the server to wait for an infinite amount of time. This results in a system lockup, because the client’s thread holds resource locks that are never released.

The ReceiveProgressResponseTimeoutSecs parameter lets you configure your server to detect this situation and to sever the client connection, releasing the resources. When the parameter is set to a valid interval (in seconds) in the server's Tm1s.cfg file, the server process will terminate the client connection, releasing any resource locks, if the server does not detect the client application’s response within the specified interval.

For example, if ReceiveProgressResponseTimeoutSecs=20 and the client application does not respond to the progress message sent from the server within 20 seconds, the client connection is terminated. Again, no user action is required to generate this response. The response is automatically generated by the client application, so that if the response does not arrive within 20 seconds, it is an indication that there is something seriously wrong with the client or the underlying networking.ReceiveProgressResponseTimeoutSecs is an optional Tm1s.cfg parameter.

If the parameter is not present in the Tm1s.cfg file, processes are not terminated when a client does not respond to a progress message from the TM1 server.

What its saying is under normal circumstances a lengthy request from a client should continue responding to the server to tell it it's still alive. The nature of Citrix connections might not always allow the request / response to complete and so hangs the server. By setting this paramter, you are telling the server to kill any connections that have not responded X seconds after it's request. If your Citrix users are still causing the server to hang, then either the option is mistyped / being ignored for whatever reason, or the value is too high. We have ours set to 20 (20 seconds) and have never had an issue with it.

Of course it might be another config option that just doesn't work, but as i said we've been using it and never had an issue like you describe.

[mmsantiago]

Thanks for the response Steve. We also have our setting at 20 seconds and this works perfectly on the direct client/server side. Unfortunately it still does not seem to work through Citrix. I don't believe there should be a difference in the setup, since we are using the same config file regardless of client connection, so I just don't understand why it would hang in Citrix. Unless it is a different problem altogether, but I thought I would address the most obvious first...especially given TM1TOP shows the same results that we used to get on the client before putting in the paramter.

Anyway, thanks. I guess I will keep looking

[v_chuk]

Hi Michelle,

We use the same version of TM1, and I have seen the exact same thing happen to us as well, when clients are on Citrix. We have had to re-cycle the server a few times in the last few months due to this issue. Not sure if you were able to identify an workaround.

I would greatly appreciate any insight you may have on this issue. Thanks!

Venu

[Steve Vincent]

Ours is also exactly the same version, so if that config is set and ours isn't being a problem, then i would start looking at the Citrix setup as a possible cause. If it helps we're using Citrix version 9.100.36280 (128-bit SSL) and the server is a Win 2003 box.

[Ajay]

We no longer have this issue as we now schedule a nightly reboot of the Citrix server at the same time as the reboot of the TM1 server.

Also make sure that settings in Citrix Program Neighborhood on the client PC are set to "TCP/IP+HTTP" and not just "TCP/IP". This caused me hellish issues until I found it.

BTW we are on 9.0 SP3 U7

HTH

Ajay

[Martin Ingram]

Ajay - what's the significance of the 'TCP/IP' vs 'TCP/IP + Http' setting?

My current client has the same setup as described above - haven't seen any issues so far, but would like to know as much as possible in the event that a problem arises!

[Ajay]

Hi Martin,

Not sure what the technical significance is, but I noticed certain users having issues when trying to connect to TM1 and then launch cubes (views). When I investigated this I noticed that their configuration had been set to "TCP/IP". I was not having any issues and so when I checked my settings - they were set to "TCP/IP + HTTP" - I changed the setting and started to get issues.

The documentation suggests this network protocal especially where members of farms change or where users change connection type (ie. latop users in differing locations)

Unless a Citrix expert amongst us knows, my rule of thumb is to always use "TCP/IP + HTTP".

Regards
Ajay