Hi Gilbert,
Please see my comments below.
Thanks,
-Jaliya
----- Original Message -----
From: "Gilbert Pilz" <[EMAIL PROTECTED]>
To: <[email protected]>
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?
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.
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.
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.
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.
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.
--
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]
