Thanks for the quick reply Onno,
but I've tried that way because I saw that I cannot call more than once the same method in one session (for example the 'OpenDoc' method).
I thought that create a session for each request could be a way...
Maybe I am wrong, and there is another way to do that.
Your request to the QRS api is most likely missing certificates to authenticate it and it is missing the XRF key.
This article will help you connect, https://help.qlik.com/sense/2.0/en-us/developer/Subsystems/RepositoryServiceAPI/Content/RepositoryServiceAPI/RepositoryS…
However I don't think this will help you a great deal. To better understand the issue do you mind sharing some details around the app? Purpose, where it runs etc
For example if your app is purely for server side operations you can instead connect directly to the engine to avoid the 5 connection limit.
If you are connecting over the proxy do make sure you are closing the websocket connection after you are done, this should free up a spot among the 5 connections in the pool. I.e ws.close() and not getting rid of the session.
Your app should not really have to connect to multiple times to the engine, instead have a global connection that you keep open and re-use whenever a user requests a resource from QIX.
If you need user specific context I would heavily suggest you look into moving the communication layer away from the server and onto the client instead.
I'm a colleague of Simone.
We are very happy you gave a so quick and effective response since it is hard to find support on this topic that is extremely important to us.
As you suggested, with the XRF key we have been able to succeed with the session delete, but this doesn't solve our issue.
In the server_License_repository.txt log file we found 5 instances of "License.Repository.Repository.Core.Resource.RequestAccessTypeResource", with SessionCount starting from 1 up to 5 and then we receive "No available access type" at request number 6.
We are connecting from our Java Application (running on JBOSS) that is a multi user application, so the user context is important but we can't connect at the client layer, since we need our application to interact with Sense objects via Qlik API.
We use JAVA tyrus client for the websocket communication and to close the session we invoke the Session.close() method:
// open the connection
session = clientManager.connectToServer(clientEndpointConfig, serverURI);
// close the connection
Do you suggest in our case that it is a better approach to connect directly to the engine instead of going through the proxy?
We do not know how to reuse a global connection that we could keep open and re-use whenever a user requests a resource, since in our tests we found that in the same connection only one OpenDoc method can be invoked (it is not possible to open another app without opening a new session).
Maybe we are not using the right method to close the websocket connection, do you have any experience or examples on connecting using Java libraries?
Ah that gives me a better overview of the issue. Let me get back to you as I'm out right now.
Also feel free to reach out directly to me at email@example.com as it seems time is an issue and we might save some
Sent from my Windows Phone
I haven't implemented something similar in JBOSS but we have a few successful implementations together with Jetty.
Most likely you are not authenticating the user and when you open a connection you are opening it as a single user/service account and then you will be limited to 5 connections. You should be able to determine this by inspecting the first frame that is being sent over the socket which will contain a OnAuthenticationInformation message that will tell you who you are authenticated as. This first frame should ideally contain the username of the user you are authenticating. You would want separate sessions anyway as it will share selection state.
Otherwise the limit is working as intended, it is there to prevent people from essentially just putting a proxy in front of the engine and serve up Qlik sessions to an unlimited amount of users while only consuming a single token.
So the process should go something like this,
1. Authenticate the user somehow, tickets/headers etc
2. Once authenticated a Set-Cookie response will be issued when requesting a resource from behind the QPS (for example if you have a ticket you can open a socket with ?qlikTicket=<ticket> and it will consume the ticket and send back a session cookie in the upgrade response.
3. Make sure the session cookie is part of the request that opens the socket, performs the handshake.
3.5 For Tyrus this means you need supply your own configuration class. http://chariotsolutions.com/blog/post/form-based-login-for-java-websocket-client/ Should help you with that
4. This will associate the session with the correct user.
You clarified the process flow very well and we found our mistake.
Instead of reusing the session cookie for subsequent websocket sesssions we did a new user authentication each time, and this caused the issue.
We need to close websocket sessions and open new ones when we want to load a new Qlik document (since it is not possible to open more than a document per session as far as we understand how Qlik works), but reusing the same session cookies for subsequent websocket sessions solved our problem.
Thanks a lot for your support.