[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp] initCookie
True for creating the cookie for the first time but not true for reestablishing the cookie after it has timed out. -Mike- Subbu Allamaraju wrote: > In the scenario being discussed, the producer does not have to > anticipate how the consumer is implemented. > > If initCookie is called and if the producer has already set a cookie > for that consumer (during a usual markup operation), the producer > would simply return. Else, it would create a new cookie. > > In fact, you brought the point I was trying to make. This is a > consumer's problem and not the producer's. > > Subbu > > Michael Freedman wrote: > >> By requiring it the producer doesn't have to anticipate how the >> consumer is implemented. I.e. as a requirement the producer codes >> itself in a single way -- if its not a requirement the producer must >> code itself to establish/reestablish cookies in both mechanisms. >> -Mike- >> >> Subbu Allamaraju wrote: >> >>>> 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 >>> >>> >> >> >> >> 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]