OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx-implement message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [ws-rx-implement] deadlock situation



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 <chamikara@wso2.com>

03/24/2006 07:52 AM
Please respond to
chamikara

To
ws-rx-implement@lists.oasis-open.org
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







[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]