Responses with "gp>" . . > -----Original Message----- > From: Jaliya Ekanayake [mailto:[EMAIL PROTECTED] > Sent: Tuesday, September 05, 2006 6:52 PM > To: Gilbert Pilz; sandesha-dev@ws.apache.org > Subject: Re: Sandesha 1.0; SandeshaContext.endSequence() and > active, offered sequences > > Hi Gilbert, > > Please see my comments below. > > Thanks, > -Jaliya > > > ----- Original Message ----- > From: "Gilbert Pilz" <[EMAIL PROTECTED]> > To: <sandesha-dev@ws.apache.org> > Sent: Tuesday, September 05, 2006 4:01 PM > Subject: Sandesha 1.0; SandeshaContext.endSequence() and > active, offered sequences > > > Hello Sandesha-istas! > > I was working on some interop testing between Sandesha 1.0 > and WebLogic Server 9.2 in which a Sandesha 1.0 client > engages in a request-response exchange with a WLS 9.2 server. > Everything works fine up until the point that the client > calls SandeshaContext.endSequence(). At this point the client > has terminated the outbound sequence via a > wsrm:TerminateSequence message but the inbound sequence > (established via an offer during the initial > CreateSequence/CreateSequenceResponse handshake) is still > active. The Sandesha 1.0 client blocks in endSequence() until > the inactivity timeout for that sequence is reached and an > exception is thrown. > >> > The exception is thrown only when the inbound sequence is not > completed within the InactivityTimeout right?
gp> Correct, but imagine if the InactivityTimeout were set for gp> 48 hours or some such. From the standpoint of a user the gp> client would "never" exit . . > Although I can understand that there may be reasons that the > client would want to block until the offered sequence is > terminated, I don't think it is reasonable to expect that > terminating an outbound sequence will necessarily result in > the server automatically terminating the inbound sequence. > > >> > When the client offer a sequence then it knows that there are > some responses that it is expecting from the server. So, > terminating outbound sequence does not mean that the inbound > sequence will also terminate. However for the client to > terminate gracefully (after getting all the responses) the > inbound sequence should also terminate with the proper > TerminateSequence. At least it should get the required number > of responses. gp> In the test I am running the client has received the "proper" gp> number of responses (1) and it has gracefully terminated gp> the outbound sequence. It is blocking on a TerminateSequence gp> for the inbound sequence which it will never get because, gp> unlike the Sandesha server, WebLogic does not treat termination gp> of the inbound (from its perspective) sequence as a signal gp> to terminate the corresponding offered, outbound sequence. > I agree with you that if the InactivityTimeout is a large > value then may be we need a way to inform Sandesha client > only to wait X number of milliseconds (where > X<InactivityTimeout), but in order for client to complete it > has to wait till it receive the required number of responses. gp> I'm not sure how the Sandesha layer can be expected to gp> know, a priori, what the "required" number of responses gp> is. To stretch a point, I could define an asynchronous gp> in-out-out-out service in which a single request message gp> was followed by N response messages. How would the client gp> know when the server was done sending responses? Obviously gp> it could wait until the InactivityTimeout period has lapsed gp> but we've already covered why this isn't always workable . . > The other possibility to completely de-couple the client and > the client side listener that is waiting for the inbound > messages(responses) is to host the client itself in a > container (e.g. client itself can be a servlet or jsp) then > we can have a separate servlet or jsp which handle the repose > part of the client's requests and use that servlet or jsp's > url as the replyTo url. gp> This is, in essence, what WebLogic does but I think the core gp> problem still remains, however; what do you do when the thing gp> that "contains" an RMD for an active sequence needs to clean gp> up (stop, exit, shutdown) but is unwilling to block for the gp> InactivityTimeout? I think sending a SequenceTerminated gp> fault to the RMS should at least be an option. > I couldn't find any language in the 200502 specs that > mandates such a linkage between the inbound and outbound sequences. > > >> > This is because these two sequences are considered completely > independent and only the client need to relate them find the > responses. gp> That was my understanding as well. > I think the application should be allowed to select from > three possible behaviors for endSequence(): > > 1) block waiting for all active inbound sequences to be > terminated (current behavior) > > 2) send a SequenceTerminated fault to all active inbound sequences > > 3) simply clean up the sequence > > What do people think? > > >> > Since the suggestions are an extensions to the current > implementation it would be great if you could submit a patch. > Then we can get this functionality in Sandesha. I'll give this a shot and post my patch to this list. > -- > Gilbert Pilz > Sr. Principal Technologist > Office of the CTO > BEA Systems, Inc. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
