The ReplyTo == none would also be
appropriate if there is an out-of-band fault handling mechanism, e.g. a dead
letter queue that enables the apps to deal with faults.
--Stefan
From: Doug Davis
[mailto:dug@us.ibm.com]
Sent: Friday, March 24, 2006 9:00
AM
To:
ws-rx-implement@lists.oasis-open.org
Subject: Re: [ws-rx-implement]
deadlock situation
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
Chamikara Jayalath
<chamikara@wso2.com>
03/24/2006
08:32 AM
Please respond
to
chamikara
|
|
To
|
ws-rx-implement@lists.oasis-open.org
|
cc
|
|
Subject
|
Re: [ws-rx-implement] deadlock situation
|
|
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