yes :) 2012/9/10 Karl Wright <[email protected]>
> 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 > >> >
