RE: [wsrp] initCookie

["Kropp, Alan" <Alan.Kropp@vignette.com>]

As I recall, this (i.e., make initial getMarkup call, block, and then continue) was considered and rejected as leaving things too loosely defined, for a scenario as common as the Consumer having to deal with http load balancing Producers.  The separate init operation offers cleaner semantics, and a hook for doing other sorts of initialization someday, beyond just http cookies.

 

Alan

 

 

 

 

 

 

-----Original Message-----
From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: Thursday, June 19, 2003 10:26 AM
To: WSRP
Subject: Re: [wsrp] initCookie

It sounds like another way to express what you are saying is "Why use an extra operation rather than just requiring the Consumer to wait for the return of the first getMarkup() before invoking the others in parallel?"

If so, I remember discussing this as an option, but don't remember why we decided on the separate operation. Does anyone else remember?

Rich Thompson

Subbu Allamaraju <subbu@bea.com> 06/19/2003 01:13 PM

To:        WSRP <wsrp@lists.oasis-open.org>         cc:                 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
>
>



You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/wsrp/members/leave_workgroup.php