I see. It's not a session that is expiring, it's the SOAP message. You are right, the SOAP header is only set once with a hardcoded 24 hours expiration time. I'll try to solve that.
Re-adding the SOAP header for each request would harm the thread-safety. So that's not a good idea. Creating new a port object for each request is expensive and therefore also not a good solution. A simple but ugly solution would be to increase the expiration time from 24 hours to 100 years. That should be enough time for everyone. The fact that the port objects cannot be used by any other user is not a big deal. A session is already tied to a specific user and there is no method to change the credentials after the session has been created. - Florian -----Original Message----- From: Aaron Korver [mailto:[email protected]] Sent: Donnerstag, 24. Juni 2010 22:49 To: [email protected] Subject: RE: Relationship between Cache and Session I think I found the problem here. I don't think this is an Alfresco problem. In the org.apache.chemistry.opencmis.client.bindings.spi.webservices.PortProvider.java class the ports are initialized and placed into a Map. When they get initialized in the initPortObject(String portKey) method, the SOAP and HTTP headers are added to them. This is the ONLY time that I can see they are added. So even though the expiration is set for 24 hours, won't this still expire and then cause a SOAP message expiration error? On top of that, since these are cached with the SOAP WS-Security headers, you can't ever make different requests with a different user (and the same session). I think if the SOAP headers were re-added on every request, instead of cached with the Ports, that it would fix this problem. Has anyone kept a Session around for longer than 24 hours? Or am I the first to try? Thanks, Aaron Korver ---------- Forwarded message ---------- From: David Caruana <[email protected]> To: [email protected] Date: Tue, 22 Jun 2010 10:35:15 +0100 Subject: Re: Relationship between Cache and Session > What you are experiencing here looks like an Alfresco bug. It does seem like a bug - thank you for bringing to our attention. Dave On 22 Jun 2010, at 09:45, Florian Müller wrote: > Hi Aaron, > > From the CMIS specification point of view there are no sessions. Clients and servers are server are stateless. Therefore, server sessions cannot expire because there aren't any. If a repository maintains a session behind the scenes, it has to make sure that either this session never expires or the session is transparently renewed. > What you are experiencing here looks like an Alfresco bug. > > As Stephan already pointed out, OpenCMIS sessions can live for a very long time. A session is tied to a user because repositories might return different repository infos and type definitions for each user. A repository might also change the language of names, display names and other properties based the on the user that is logged in. Also, the whole permission checking has to be done on the server on a per user basis. User A shouldn't see an object that user B fetched an minute ago and still is in the cache. Therefore, this data is cached inside the session and must be tied to the user. There are no user independent stable objects in CMIS. > > > Cheers, > > Florian > > > -----Original Message----- > From: Klevenz, Stephan [mailto:[email protected]] > Sent: Dienstag, 22. Juni 2010 09:59 > To: [email protected] > Subject: RE: Relationship between Cache and Session > > Hi Aron, > > In theory there is no assumption about the lifetime of the session. It can be short, that means opening a session for each request, it can be bound to a HTTP session or it should also be possible to serialize the session and keep it for a very long time. Finally the session lifetime is controlled by the calling application. > Actually the session consists of the bound repository, the cached items and the user credentials. > > Because of the stateless behavior of the SOAP/REST communication user credentials are always passed to the protocol layer. A user session timeout at the backend should be independent of that. > > Regards, > Stephan > > BTW, the use case for a request based session are composite applications that consist of independent parts assembled together. The request based session avoids that each part has to open its own session. > > -----Original Message----- > From: Aaron Korver [mailto:[email protected] ] > Sent: Montag, 21. Juni 2010 23:39 > To: [email protected] > Subject: Relationship between Cache and Session > > Hello again Chemistry devs, > I have an observation and a question for ya'll. Looking at the > PersistantSessionImpl class, there is a Cache object in there. This would > imply to me then that each session has its own cache. And looking at the > constructor for the PersistantSessionImpl shows that this is true, since > CacheImpl.newInstance() is called. > > The session seems to also be highly dependent upon the logon token for the > user. I haven't tracked this down yet, but what I'm seeing is that a > session is created, and can be used for about 5-10 min. After this amount > of time has elapsed, the SOAP logon token is no longer valid and I get an > exception back from the Alfresco CMIS implementation. I apologize for not > having the exact stack trace at the moment, I can get it upon request > though. > > This would seem to indicate that the appropriate pattern would be to create > a new session per request? Since long running sessions look like they time > out. I'm also thinking that this is correct since each session is tied to a > specific user. > > If the assumption of short lived Sessions is correct, then I fail to see an > advantage of using a Cache, since each Session will be a fresh instance. If > the cache was decoupled from the Session then this would be advantageous for > some types of stable objects (repositories, folders, etc). > > If my assumption is incorrect, and Sessions are assumed to be long lived > objects, how does one update the timestamp on the Session to prevent the > SOAP login from expiring? Or maybe this is a problem that is specific to > Alfresco and I'm barking up the wrong tree? :-) > > Thanks for your input, > Aaron Korver
