I may got that wrong, but the message means that the same DOMAIN\USERNAME is trying to access from a different session, tab, browser, computer... and since the user has a valid license assigned, the last user prevails and removes the license from the other sessions.
This can be tricky. With two computers may be obvious: although you are logged on as the same user, QlikView will only lease the license to one. And that one is the last user to connect to the Server, which will cause likely a "Connecion Lost" message in the first computer.
But that may happen as well with different versions (for example, two tabs in the same browser against the same server) but with the same user.
Hope that helps.
Hi Miguel, I think you didn't understand completely. All of my clients are coming from the same computer. I'm jusing JMeter, a single instance of it, all from the same client computer. The client computer is not the same computer as the server, but that's pretty normal.
For Gary and others. I'm not using DMS, and since I'm stress testing a production system, I'd like to not mess with the server settings, but using basic authentication would be better than switching to DMS completely.
As for two broswers on the same client connecting to the same QVW. I'm amazed, it used to work in previous versions (I can hear the theme music for the 'way back machine' in the background, sorry), but I just tested it and you're right, in AJAX it allows 2 different browsers, but they both carry the same selections. If you select in one, then switch to the other and change sheets, the 2nd will switch to the 1st's selections.
On the other hand, in the Plug-in, you can have 2 completely separate browswers (on the same client computer) browsing the same QVW completely independent, so it's not a license issue, just a AJAX issue.
Since JMeter is using AJAX type calls, I imagine I'll have to use the basic authentication method as Gary mentioned above.
Looks like I have it working. Thanks for the ideas! I had to go into the Web Server (in the QVS Managment Console) and chose the Header authentication, and I cleared out the custom\ value. Then, went into the QVGeneratorand marked that as header. I had to copy the header parm from the QVS Managment Console (near where you check for header authentication) back to the QVGenerator. Then things worked well for testing... On to the next issue.
I've run into the same issue and solved it Gary's way. It all *sort of* makes sense. You are simulating multiple users, therefore each "user" must have it's own state. With the current Ajax session recovery setup, any window on the same client machine with the same userid reuses the session. So some voodoo has to be done to get a unique session for each "user". The voodoo is making it look like each new "user" comes from a different client machine. What follows is the rule violation -- same named user on different machines.
A side effect of this is that you don't get the expected test anyways. The state for a given set of interactions is not predictable.
What we are seeing is a working licensing system, which needs to be handled appropriately when using the script tool.
I suspect the user that is running the tool recieves a Named CAL. Every virtual user started by the tool will use the same authenticated user name. Named CAL:s only accept one active session per document. As you are simulating multiple users coming from the same authenticated user name the virtual user will play tug-of-war with the CAL (killing each other's sessions). The same behaviour should be seen if you access the same application from two different web browsers with the same authenticated user.
It can be solved by simulating different users, using header authentication. If these users do not exist within the AD, then DMS mode is needed. Make sure that the different users will recieve Named CAL:s.
If you have enough session CAL:s, this will work as well if you disable automatic assignment of Named CALs.
Try this out and please post how it went.
I agree with what Miguel and Sebastian said about "works as designed". The way that I have gotten around this is to enable Basic Authentication on your web server. It's posisble to do it with QVWS, but I have only done it with IIS. Then you create X number of local Windows user accounts on your QlikView Server, which will be authenticated with NTFS rather than DMS. These are fed into JMeter using a text file with the user names and passwords. There are also some instruction included with the script gen tool that explain how to configure the tool to use Basic Auth. Hope this helps.