Ok, I understand - so the maximum number of connections you actually need are 2, not 20. ;-)
Karl On Mon, Sep 10, 2012 at 8:36 AM, Maciej Liżewski <[email protected]> wrote: > OK. will try to explain: > > there is only one HttpClient for Connector instance. But it has tohandle > multiple request. During login process it has to handle 2 connections > (first try to login and if the server returns TokenRequired answer - second > connection but the first may not be disconnected that time). So I had to > increase setMaxTotalConnections, because oryginally there was a limit > setMaxTotalConnections(1), > which caused deadlocks in situations described earlier. I think there could > be "unlimited" option as well. > > As there is only one instance of HttpClient per Connector instance per > session - there are not so many "login" requests - in fact only one per > session when the HttpClient is instantiated and is maintained until > Connector::disconnect() is called (which kills HttpClient instance). > > When session expires there is no 40x response unfortunately, but there is > error message in payload: > > <?xml version="1.0"?> > <api><error info="You need read permission to use this module" > code="readapidenied"/></api> > > it could be used to handle "session expired" situation, but should be > checked on every API request... > > > 2012/9/10 Karl Wright (JIRA) <[email protected]> > >> >> [ >> https://issues.apache.org/jira/browse/CONNECTORS-518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13451863#comment-13451863] >> >> Karl Wright commented on CONNECTORS-518: >> ---------------------------------------- >> >> I've had a look at the login functionality. Since you are keeping hold of >> an HttpClient instance for the entire lifetime of a session, cookies should >> stick to that instance. This should be OK. However, each individual >> HttpClient instance will need to log in itself, so you will have a lot of >> logins - but perhaps that is OK too. >> >> I am puzzled, however, why you have the following: >> >> {code} >> connectionManager.getParams().setMaxTotalConnections(20); >> {code} >> >> Since this is local to the connection instance, there should need to be >> one connection per instance, so it seems to me that you can leave this at 1 >> and be fine. If you set up a global pool in Commons HttpClient 3.x, it >> segregates cookies only by server name, and there may be different >> credentials depending on which connection was in play, so we cannot use a >> global pool even if we wanted to. >> >> So I think the only other thing we need to fix is explicit support for >> session timeout. Am I correct in assuming that you get back a 401 error >> when session has timed out on a document fetch? Is there anything in the >> payload which would indicate session timeout instead of general >> inaccessibility? >> >> >> > Wiki Connector support for API authorization and security tokens >> > ---------------------------------------------------------------- >> > >> > Key: CONNECTORS-518 >> > URL: >> https://issues.apache.org/jira/browse/CONNECTORS-518 >> > Project: ManifoldCF >> > Issue Type: Improvement >> > Components: Wiki connector >> > Affects Versions: ManifoldCF 0.6 >> > Reporter: Maciej Lizewski >> > Assignee: Karl Wright >> > Fix For: ManifoldCF next >> > >> > Attachments: WikiConnector.java, wiki.zip >> > >> > >> > Wiki connector does not support API with restricted access (there is >> "login" method in API: https://www.mediawiki.org/wiki/API:Login) >> > There is no "security" tab for forced authorization tokens or any other >> security implemented. There should be at least forced tokens tab or tokens >> assigned to wiki namespaces (second would be better) >> >> -- >> This message is automatically generated by JIRA. >> If you think it was sent incorrectly, please contact your JIRA >> administrators >> For more information on JIRA, see: http://www.atlassian.com/software/jira >>
