← Prev in month ← Prev in thread
Next in thread → Next in month →

RE: [ws-rx-implement] deadlock situation

From
Stefan Batres <>
Date
2006-04-06T16:34:22+00:00
ID
Thread
RE: [ws-rx-implement] deadlock situation
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:] 

Sent: Friday, March 24, 2006 9:00
AM

To:


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
  <> 

  
03/24/2006
  08:32 AM 

  
   

    
    
Please respond
    to

    chamikara

    
   

  
  

  
  
  
   

    
    
To

    
    
    
 

    
   

   

    
    
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 

 

  
  
Chamikara Jayalath <> 

  
03/24/2006
  07:52 AM 

  
   

    
    
Please respond
    to

    chamikara

    
   

  
  

  
  
  
 

  
   

    
    
To

    
    
    

    

    
   

   

    
    
cc

    
    
    
 

    
   

   

    
    
Subject

    
    
    
[ws-rx-implement] deadlock situation

    
   

  
  
 

  
   

    
    
 

    
    
    
 

    
   

  
  

  
 

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
← Prev in month ← Prev in thread
Next in thread → Next in month →