Forum Discussion
NimbostratusA customer of mine is having issues accessing his server once its placed behind the F5. Here is his scenario.
QlikSense/ISmart Load Balancer Issue:
I Smart is .Net web application. QlikSense (QS) is an analytics tool that allows for integration into .Net applications. There is a mechanism called web ticketing within QlikSense that allows for a user to request access to the QlikSense servers without having an AD acct or any local account. See the following link for more information (https://community.qlik.com/blogs/qlikviewdesignblog/2014/12/08/tickets-in-qlik-sense), but during this process, a user sends a request to QS and if valid, the user will receive a ticket (sample - qlikticket=abc123_asdf). That ticket then sent back from IIS to the QS server to be absorbed and then allows the user access to view QS data. There are 6 servers that make up a QlikSense environment and 3 types of servers (engine, reload, proxy - 2 each). The ones are question is the proxy servers. The proxy server is the gateway into Qlik and the only server that is exposed to .Net. We have originally been sending these ticket request directly to the proxy server (ex. usserver1), but this requires users to have a host file entry for that server. When we send request directly, there are no issues. A qlik ticket is received and the user can view the data, etc. When we use the dns entry which has a load balancer sitting in from of the two proxy servers (ex: ismartqlik.com), there are issues seen in the form of:
- Lost Packets?
- Not able to receive a ticket.
- Not able to view QlikSense data due to no ticket being issues.
While troubleshooting, we have tried the following:
- Opening up ports to allow traffic through.
- Enabled persistence or sticky sessions such that you dont jump between the two proxy servers once a request is initiated.
1 Reply
- Kevin_Stewart
Employee
Most application issues behind a load balancer involve some form of "misinterpretation" of data. If an application works when accessed directly, but fails in different ways behind a proxy, there's a very good chance that the content the client receives may include incorrect URLs. By itself, a web-based application will generally respond to HTTP requests with some amount of HTML content. Inside that HTTP response is HTTP headers and content. In either case there may exist URLs that the application expects the client to follow. For example, a web page may have document object references (images, stylesheets, javascripts, etc.) that the client has to go get. In some cases the server, not understanding that it's behind a proxy, sends references to these objects as absolute URLs. For example, let's say you have a virtual server you're accessing as but locally the server is If the server sends the HTML page and includes absolute URLs to these objects as:
src="http://server1.localdomain.local/images/my-cat.png"the client won't (shouldn't) be able to access that URL. In this case the image won't be displayed. Unfortunately this isn't always easy to troubleshoot, but at the very least you'd need to inspect the HTTP traffic from the client's perspective. In short, if you can install Fiddler or HTTPWatch and then inspect the HTTP requests and responses to the browser, you'll very likely find that some of the URLs presented to the client are not correct. The good news is that this is usually pretty straight forward to fix, but you first have t understand where and how it's breaking.
While troubleshooting, we have tried the following:
- Opening up ports to allow traffic through.
- Enabled persistence or sticky sessions such that you dont jump between the two proxy servers once a request is initiated.
If ports were an issue you'd probably see no content at all. If persistence was an issue, the problem would probably manifest inconsistently.
