Hi Doug,
Paul and I had a chat on a possible solution for this. We thought of
going for the following. (thought of sending it to the list for knowing
the ideas of you and other implementors :-) ).
I think you are right in saying that RMD should wait till the AD
returns before sending the ack. My concern was a long duration web
service call (which may invoke other web services etc.) so we thought
of making RMD configurable. The users will be able to say weather the
RMD should block or not before sending an ack (default will be block).
Also blocking will happen only for a given number of seconds and if the
AD does not return by that time a standalone ack will be sent.
On the client side there will be a MaxTimeToGetAck parameter. If the
ack does not return by that time. An empty body ack request will be
sent.
Chamikara
Doug Davis wrote:
I don't think you can assume that
the
RMD can send back SeqAcks before its done blocking either. One option
is that if the RMS is really worried about this situation it could set
the wsa:FaultTo and wsa:ReplyTo to WSA's "none" - but this is
only if it really wants (and knows) its a true fire-n-forgot model.
-Doug
Hi Doug,
Hmm, does this solve the actual problem. Suppose there are five
threads.
Four for sending application messages and one for sending sequence
acks.
The First message get lost. And the four threads which operate on
application
messages send the messages 2,3,4 and 5 and since get blocked by the
RMD.
After some time RMS send a sequence ack with which it can know that the
above messages got delivered. Now should the RMS timeout the blocking
threads.
If that is done the RMD will never be able to deliver the possible
fault,
for which it was blocking all these threads.
All these scenarios occur only if FaultTo is anonymous. So I believe
this
is something that should be seperately taken into consideration just
like
the anonymous ReplyTo scenario. One method may be to RECOMMEND the RMD
to send the sequenceAcks without waiting for any application level
faults
which could have been easily delivered if faultTo was not anonymous.
Chamikara
Even if we go for the
Doug Davis wrote:
In the interop, if I'm remembering correctly, you only had one thread
running
on the RMS side and that
was part of the problem as well. It doesn't seem entirely correct
for the RMS to assume that all connections
between the RMS and RMD will immediate be closed. As you stated,
the problem can occur with any
number of threads if the number is less than the number of messages
being
sent. However, in general
I would think that its a bad idea for the RMS to use up its entire
thread/connection
pool on connections
that could block. Shouldn't it reserve some of them for less
problematic
operations like SeqAcks?
-Doug
Hi All,
As it was observerd in the interop a deadlock situation could occur in
a
situation where the RMD tries to do in-order delivering and and the RMS
sends the messages out of order. Even though it was stated that this can
be omitted by asking the RMS to send the messages in-order, this does
not seem to be a general solution.
The RMS may send the first message first. But suppose this does not get
delivered to the RMD. Now should the RMS re-send the first message or
should it send the second message. If the RMD does not implement the
in-order delivering the second case would work fine. But if RMD does
implement in-order delivering this would result in a deadlock. It seems
like we cannot take a desicion wothout knowing the implementation
details of RMD.
Increasing the number of threads in the RMS also does not solve the
problem since we could develop a scenario that include more number of
messages which would result in the same situation.
It seems like we need a more precise solution for this. Comments ?
Chamikara
|