Re: [ws-rx] NEW ISSUE: Remove LastMessage

[Doug Davis <dug@us.ibm.com>]

Well, it all depends on how your queue
is implemented doesn't it?  I can easily envision an implementation
where the cost of having a queue would be zero (might have even implemented
one).  In fact any impl that doesn't have a cost that's pretty close
to zero, I would claim, might have issues  :-)
You're example shows why the its very
important for implementations to keep the cost of individual queues very
low - there could be lots of them.  There might be a bit of overhead
with maintaining an RM system in general but I would think that the cost
of each sequence (except perhaps the first one) should be quite small.
thanks,
-Doug


Anish Karmarkar <Anish.Karmarkar@oracle.com>
wrote on 12/01/2005 03:19:20 PM:

> Doug,
> 
> I don't know how big of an issue this is either and therefore wanted
to 
> tease out what sort of capabilities/optimization we would be removing
> with the removal of LM.
> 
> Here is one scenario/usecase:
> 
> WSRM is used to reliably deliver single invocations of WSDL operations
> (such as updateAccount). I.e., the Sequence consists only of one 
> message. There are several such invocations possible from multiple
> clients (with certain expected peak loads). In this case, the size
of 
> the empty queue would be > the single message that the queue would
hold.
> 
> -Anish
> --
> 
> Doug Davis wrote:
> > 
> > Anish,
> >  ok - I think I finally get it.  Don't know how big
of an issue this is. 
> >  Right now the RMD can experience
> > this same problem when it creates sequences that are never used
- which 
> > the inactivityTimeout
> > was supposed to help.  I guess this situation would be bad
for the RMD 
> > if two things were true:
> > 1) the queue was kept separate from the other metadata about
the 
> > sequence and could be deleted
> > w/o impacting the ability of the RMD to return the ACKs, and
> > 2) the size of an empty queue was a concern for the RMD
> > Dunno...
> > thanks
> > -Doug
> > 
> > 
> > Anish Karmarkar <Anish.Karmarkar@oracle.com> wrote on 11/30/2005
> > 09:50:20 PM:
> > 
> >  > Doug Davis wrote:
> >  >
> >  > <snipped for readability/>
> >  >
> >  > >  > 3) What I'm saying is the following
-
> >  > >  > When:
> >  > >  > a) an LM marker is present in the
last message, and
> >  > >  > b) the RMD receives all the messages
upto and including the 
> > message with
> >  > >  > the LM marker. I.e. all the messages
in the range [1, 
> > Seqno(LM-message)]
> >  > >  > then:
> >  > >  > at that point the RMD knows that it
has received all the 
> > messages in the
> >  > >  > sequence. In certain implementations
it can make the 
> > determination that
> >  > >  > it no longer needs the message store
(it still needs to be 
> > around to ack
> >  > >  > messages) -- assuming that the messages
have been successfully 
> > delivered
> >  > >  > to the AD. i.e., it can give up its
message store resource at 
> > this point
> >  > >  > but *not* terminate the Sequence.
> >  > >
> >  > > Why would it need to keep them around w/o the
LM marker?  Once a 
> > message
> >  > > has been delivered to the AD why would the RMD
need to keep it 
> > around at
> >  > > all - regardless of the LM marker?
> >  > >
> >  >
> >  > I'm talking about the message store being kept around,
not the messages.
> >  > Without the LM marker, the RMD does not know that
it doesn't need the
> >  > queue/store anymore.
> >  >
> >  > >  > Without the LM marker, it will never
know if it has received all the
> >  > >  > messages in the Sequence until it
receives the TerminateSequence 
> > message
> >  > >  > (which is unreliable).
> >  > >
> >  > > Under what situations would the RMD not deliver
a message to the AD 
> > when it
> >  > > has all of the messages from 1 to X and then
NOT clear up its store 
> > for
> >  > > those
> >  > > messages?  Once it has 1 it can deliver
it and erase it, once it 
> > did that
> >  > > it can do it for 2, then 3.... marking X as the
LM doesn't change that.
> >  > >
> >  >
> >  > This is a tangential issue and not relevant to the
LM marker issue.
> >  > But it is possible that the AD is intermittently disconnected,
in which
> >  > case the RMD may have all the messages but may not
be able to deliver
> >  > the messages till AD is connected again.
> >  >
> >  > I'm not talking about message clean up, but about
giving up the
> >  > store/connection/session/whatever.
> >  >
> >  >
> >  > >  > To take the previous example, there
are 3 messages in the sequence -
> >  > >  >
> >  > >  > scenario A: LM marker present in message
# 3, RMD has received 
> > all the
> >  > >  > messages (1, 2, 3) but not the TerminateSequence.
RMD knows that 
> > there
> >  > >  > will never ever be message number
4 (and beyond) and therefore 
> > does not
> >  > >  > need the message store (but still
needs to hang around to ack).
> >  > >
> >  > > Doesn't need it for 1,2 and 3 at all anyway since
there's nothing 
> > stopping
> >  > > it from deliverying all 3 to the AD and erasing
it from its store.
> >  > >
> >  >
> >  > Yes, but it cannot give up the store itself.
> >  >
> >  > >  > scenario B: LM marker is not present
in message # 3, RMD has 
> > received
> >  > >  > all the messages (1, 2, 3) but not
the TerminateSequence. RMD 
> > does not
> >  > >  > know that there won't be a message
number 4 (and beyond) and 
> > therefore
> >  > >  > may indeed need the message store
(say if 5 were to arrive 
> > before 4 and
> >  > >  > the DA was inOrder, it will have to
store 5 till it receives 4 
> > and then
> >  > >  > delivery both).
> >  > >
> >  > > But it can still deliver and erase 1, 2 and 3
- same as above.  LM 
> > doesn't
> >  > > change that.
> >  > >
> >  >
> >  > Correct for the messages themselves, but not for the
store related
> >  > resources.
> >  >
> >  > >  > So I think that the LM marker does
allow the RMD to free up certain
> >  > >  > (though not all) resources when it
has received all the messages 
> > in the
> >  > >  > sequence and before the TerminateSequence
message is received 
> > (this of
> >  > >  > course would depend on the implementation,
YMMV).
> >  > >  >
> >  > >  > Hope that makes sense.
> >  > >  >
> >  > >  > Thx.
> >  > >  >
> >  >
> >  > <snipped for readability/>
> >  >