releaseSessions support

[claprun]

As you may (or not) know, Portal doesn't send individual Portlet Session IDs as results of WSRP invocations. Portal deals with the Portlet Sessions internally on a user-basis and WSRP consumers don't need to manage them. This is possible because WSRP consumers are required to send back any cookies that were set by producers.

This raises a couple of interesting questions regarding how to support releaseSessions.

1. Since consumers will not have any session IDs to work with, they shouldn't call releaseSessions. However, what should happen if they do?
Several options:
i) Validate the parameters and make sure that they conform to the WSRP spec and provide a null implementation of releaseSessions?
ii) Send an error condition since it shouldn't have been called (OperationFaultException)?

2. Another issue pertains to freeing up resources. Though it's not required for consumers to call releaseSessions, this allows for producers to clean up any associated state. We cannot currently do that.

A possible solution to both issue would be to send the current user session id (which is carried over by the cookie) as the single session id returned on WSRP invocations. This way, consumers would have a session id to work with and our producer could know when a given consumer notifies us that it's not interested in the data associated with the session anymore. This, however, would be a kind of perversion of the spec and I am not quite sure what the implications would be on the consumer side: seeing one session id multiple times in different contexts might be confusing, if not downright wrong, I need to check on that.

What do people think?

[julien1]

with the actual design :

- if they call release session, we should react with a null operation internally and at the protocol level according to how the wsrp spec says to react (as you said, OperationFaultException would be an option to signal to the consumer that it is doing an error).

- about resource management, today as no explicit session invalidation is performed, that will be done by the servlet layer that will garbage the expired sessions.

For now, we don't even have that at the portal level and it would be a feature to add in the later releases of the project. Actually the only thing we have now on an explicit user logout is to trash the portlet sessions for security reasons which is similar.

So the current mechanism is not broken and we should wait until we implement it in a better way at the portal level or we have feedback from the field that this feature would provide a mesureable value added.

[claprun]

- if they call release session, we should react with a null operation internally and at the protocol level according to how the wsrp spec says to react (as you said, OperationFaultException would be an option to signal to the consumer that it is doing an error).

The spec doesn't really cover this aspect since the spec expects Portlet session IDs to be available, which is why I was asking. OperationFaultException has the semantics that something went wrong during the processing of the operation so I was not too keen on using that but there really is no other option if we want to notify the consumer that the operation shouldn't have been called. Hopefully, existing consumers can deal with not having Portlet sessions appropriately! :)

[julien1]

What about making it configurable at the service level :

<on-release-session>throw_fault</on-release-session>
<on-release-session>ignore</on-release-session>

?

[claprun]

What about making it configurable at the service level :
<on-release-session>throw_fault</on-release-session>
<on-release-session>ignore</on-release-session>
?

I'm not sure there's a need for that though it certainly can be done. I'm interpreting the spec as: throw a MissingParametersFault if there is no sessionIDs in the releaseSessions request (though the spec actually doesn't say that much) so I am assuming that consumers won't call the method if they don't have session ids. That was my first option and the one that's currently implemented, i.e. when releaseSessions is called, we check that the parameters are valid. If they are (which normally can't happen), we don't do anything. Otherwise, we throw the appropriate exception (InvalidRegistration, AccessDenied or MissingParameters). That's some processing for not much return though it's more semantically correct than just failing on OperationFailed.

[claprun]

That said, throwing OperationFailedFault is definitely easier :)

[claprun]

I'm going to implement the OperationFailedFault solution without configuration for now. If people (and yes, that include people interested in using our WSRP implementation ^_^) think a different solution is better, please let us know (though we cannot promise we will implement it ^_^).

[julien1]

you should probably document the behavior of the session in our dev docs later.

[mwringe]

I'm going to implement the OperationFailedFault solution without configuration for now. If people (and yes, that include people interested in using our WSRP implementation ^_^) think a different solution is better, please let us know (though we cannot promise we will implement it ^_^).

Do you mean that releaseSession will always fail with an OperationFailedFault? or that it will remain as before except that it will fail with an OperationFailedFault instead of being silent?
(ie can it still fail with an invalid registration and missing parameters fault)

[claprun]

"mwringe" wrote:
Do you mean that releaseSession will always fail with an OperationFailedFault? or that it will remain as before except that it will fail with an OperationFailedFault instead of being silent?
(ie can it still fail with an invalid registration and missing parameters fault)

It will fail without attempting to validate the parameters. There isn't much value in validating parameters for a method that shouldn't be called but there is processing time associated with it (validating a registration is not free for example).