OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [wsrp] initCookie


> The particular scenario this area of the spec was designed to solve is:
>   A load-balanced Producer where:
>       - a cookie set on the first request is used for routing on all 
> subsequent requests
>       - the Producer does not want to do the synchronization necessary 
> to ensure that multiple parallel requests targeting portlets that are 
> within one portlet group (i.e. all will use a single shared session on 
> the Producer) all get routed to the same node in the cluster such that 
> the shared session can be managed reasonably.

Yes. With such a producer, if a consumer is making concurrent requests, 
it will have to invoke initCookie to get new cookies.

But my question is why should it be *required* for the consumer to 
invoke this operation? The consumer knows the situations during which it 
should be careful about session cookies. For instance, if a consumer is 
making requests sequentially, the producer can establish the session 
automatically.

Regards,

Subbu

> 
> 
> 	*Subbu Allamaraju <subbu@bea.com>*
> 
> 06/19/2003 11:57 AM
> 
> 	       
>         To:        WSRP <wsrp@lists.oasis-open.org>
>         cc:        
>         Subject:        Re: [wsrp] initCookie
> 
> 
> 
> 
> I'm not sure if it does. I'm probably dense on this, but I'm not
> convinced the wording helps justify this operation. Your suggested
> wording implies that this is a producer's requirement, but it seems to
> be a consumer's problem. IMO, the current wording places
> responsibilities inconsistently (more below).
> 
> There are two problems here:
> 
> (a) Consumer making multiple simulataneous requests.
> 
> (b) Producer requiring initCookie before any markup request is made.
> 
> The first problem is analogous to an HTTP client making multiple
> requests (say in a frameset). In this case, the requests won't be able
> to join in the same session the first time, and this will be corrected
> in subsequent requests (if cookies are used for session tracking). In
> WSRP, this is strictly a consumer's problem.
> 
> On the producer side, the producer can always establish/reestablish
> sessions as required and set the cookie (if it uses cookies) in the
> response. There is no need for a separate initCookie operation for this
> purpose. This is an unnecessary burden on the producer.
> 
> In order to resolve the current inconsistency, I suggest that the spec
> reflect the following (and the changes below):
> 
> (a) Rename requiresInitCookie to supportsInitCookie.
> 
> (b) If a consumer is making concurrent requests (or for whatever
> reasons), it may invoke the initCookie (if supportsInitCookie is true)
> before making concurrent markup requests.
> 
> (c) The producer may reestablish the session transperantly if it was
> found invalid during the course of a request. Right now it throws
> InvalidSession fault forcing the consumer to drop everything, call
> initCookie and reinvoke the operation. IMO, this is quite unnecessary.
> 
> (d) If the producer stores templates/user profile in the session and it
> reestablishes the session during a request, the producer would throw a
> MissingParameters fault (or some kind of a new fault
> MissingParametersStoredInSession fault), and the consumer could reinvoke
> the operation with the missing parameters. In this case there is no need
> to invoke to initCookie operation.
> 
> (e) If the consumer is making concurrent requests, it may get
> MissingParametersStoredInSession fault for all requests for that
> producer. At this point, consumer may invoke initCookie and retry.
> 
> IBO, unless I'm missing something else, these changes would shift the
> responsiblities to where they belong.
> 
> Regards,
> 
> Subbu
> 
> Rich Thompson wrote:
>  >
>  > Would it help if the first sentence of section 3.12 had the following
>  > appended?
>  >        ", especially in the context of potentially handling multiple
>  > simultaneous invocations from a Consumer."
>  >
>  > Rich Thompson
>  >
>  >
>  >                  *Subbu Allamaraju <subbu@bea.com>*
>  >
>  > 06/19/2003 08:52 AM
>  >
>  >                        
>  >         To:        WSRP <wsrp@lists.oasis-open.org>
>  >         cc:        
>  >         Subject:        [wsrp] initCookie
>  >
>  >
>  >
>  >
>  >
>  > I've a few questions on the reason behind the initCookie operation and
>  > the way it is specified.
>  >
>  > Per the spec, this operation is supposed to let the consumer *assist*
>  > the producer in establishing certain cookies that the producer *may*
>  > require for managing a load-balancing environment.
>  >
>  > However this reasoning is somewhat vague. In particular it does not
>  > explain why WSRP has this special requirement when most HTTP-based apps
>  > don't require such a process. In a sesne WSRP is going beyond HTTP and
>  > Cookie RFCs in requiring an extra operation to initialize a producer's
>  > environment.
>  >
>  > More importantly, the spec does not explain what prevents a producer
>  > from establishing the same cookies upon the *first request* from the
>  > consumer in a transperant fashion, and why it needs consumer's help.
>  >
>  > I'm looking for a clarification on this operation.
>  >
>  > Regards,
>  >
>  > Subbu
>  >
>  >
>  > You may leave a Technical Committee at any time by visiting
>  > 
> http://www.oasis-open.org/apps/org/workgroup/wsrp/members/leave_workgroup.php
>  >
>  >
> 
> 
> 
> You may leave a Technical Committee at any time by visiting 
> http://www.oasis-open.org/apps/org/workgroup/wsrp/members/leave_workgroup.php
> 
> 




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]