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 >
