Re: RM Group Definitions

[Gordon van Huizen <gvanhuiz@progress.com>]

Marty,

So in your view, the RM grouping is tied to a transport path, not an
application (I agree with doing it this way). This implies, at least to
me, that the message service is demarking group boundaries for messages
streamed across each transport path, on behalf of the multiple
applications that are sharing that particular path at any given point in
time. It also implies that the groupings are not directly derived from
application-level message batching. Are we all in agreement on this?

-gvh-



mwsachs@us.ibm.com wrote:
> 
> Henry,
> 
> What we discussed in San Jose and what appears in the current RM draft
> specification includes multiplexing in the sense that a single RM group
> includes messages from any and all applications (e.g. TPAId and
> conversationId) that share a particular transport path.
> 
> Regards,
> Marty
> *************************************************************************************
> 
> Martin W. Sachs
> IBM T. J. Watson Research Center
> P. O. B. 704
> Yorktown Hts, NY 10598
> 914-784-7287;  IBM tie line 863-7287
> Notes address:  Martin W Sachs/Watson/IBM
> Internet address:  mwsachs @ us.ibm.com
> *************************************************************************************
> 
> Henry Lowe <hlowe@omg.org> on 08/30/2000 12:26:42 PM
> 
> To:   ebxml-transport@lists.ebxml.org
> cc:
> Subject:  Re: RM Group Definitions
> 
> Marty,
> 
> I would agree with your Group Size proposal.
> 
> However, unless I missed something, I don't think your
> second concern is a problem as it's based on multiplexing
> of the channel.  I don't think RM proposed multiplexing.
> 
> If I'm wrong and there is multiplexing, you are right and
> there is a BIG problem.  If this is a problem, the best
> way to deal with would be to eliminate the muxing (rather
> than try to reinvent all the mechanisms found in transport
> protocols to deal with it -- this is a hard problem).
> 
> Best regards,
> Henry
> --------------------------------
> At 11:20 AM 08/30/2000 -0400, mwsachs@us.ibm.com wrote:
> >Jim,
> >
> >Believe it or not, we may be in agreement.
> >
> >I want to very carefully distinguish between the group size and a series
> of
> >reliable messages sent by the application layer.
> >
> >The group size is fixed for a given transport path and all reliable
> >messages for all application processes (TPAs and conversations or
> >equivalent) using that path flow through that group.  No one process knows
> >anything about what it is sharing the transport path with, so no one
> >process can make the correct decision about the group size for all
> >processes sharing the path.  What is too large for one  may be too small
> >for another.
> >
> >On the other hand, any application process has to be able to specify that
> a
> >message, or a series of messages should be sent via reliable messaging.
> >There is no reason why the number of messages in the series needs to have
> >anything to do with the group size. See caveat below.
> >
> >My proposal, which I believe is in the comments to the reliable messaging
> >spec, is that the application individually flag each message as reliable
> or
> >not.  Alternatively, there can be "start reliable messaging" and "end
> >reliable messaging" primitives on the BP-TRP service interface.
> >
> >Caveat:  There is a possibility that a group is not full while no process
> >has any more reliable messages to send.  This would be a hang condition if
> >we don't deal with it.  Using "start reliable messaging" and "end reliable
> >messaging" primitives on the interface helps to solve this problem since
> if
> >no process has reliable messaging in effect, the reliable messaging
> >function could normally terminate the group even if it is not full.  I
> >believe there are also other cases for having to normally terminate an
> >incomplete group which I called out in the comments.  Note that having the
> >application process specify the group size does not solve this problem
> >because an application process can have various paths involving different
> >numbers of messages and it may not know at the time it issues the first
> >reliable message, which path it will follow.
> >
> >Caveat 2:  None of the above addresses my other concern, that a deadlock
> >will occur if all processes are waiting for responses to reliable messages
> >at a time when the group is not full.
> >
> >Regards,
> >Marty
> >
> >****************************************************************************
> 
> >*********
> >
> >Martin W. Sachs
> >IBM T. J. Watson Research Center
> >P. O. B. 704
> >Yorktown Hts, NY 10598
> >914-784-7287;  IBM tie line 863-7287
> >Notes address:  Martin W Sachs/Watson/IBM
> >Internet address:  mwsachs @ us.ibm.com
> >****************************************************************************
> 
> >*********
> >
> >
> >
> >Jim Hughes <jfh@fs.fujitsu.com> on 08/29/2000 04:37:31 AM
> >
> >To:   ebxml-transport@lists.ebxml.org
> >cc:
> >Subject:  Re: RM Group Definitions
> >
> >
> >
> >OK, if the upper layer is not supposed to establish the end of a sequence
> >of reliable messages, then we need to decide how the MSH will do this. Do
> >you have a particular algorithm to propose?
> >
> >(My personal favorite solution *is* to let the upper layer have an
> >opportunity to tell the MSH that a sequence of messages should be sent in
> a
> >reliable mode. To do this, we need to agree on the Message Service
> >Interface that would permit this... But if the group decides that,
> >architecturally, we cannot have this link, then we need a resolution for
> >solving this in the MSH.)
> >
> >Jim
> >
> >At 04:42 PM 8/28/2000 -0400, mwsachs@us.ibm.com wrote:
> >>Jim,
> >>
> >>Correct - the upper layer BP should not establish the group size.  Each
> >>process in the BP layer has a view only to itself.  With the BP processes
> >>requesting group size, the RM service would have to somehow resolve
> >>conflicts.  Using the largest requested group is one approach - but that
> >>would be larger than most processes want and therefore impair their
> >>latencies.  Note also that once the RM service is into resolving
> conflicts
> >>on group size, no BP process knows what the actual group size is anyway.
> >>
> >>The trivial case which you mention is probably not the best answer.  If
> >the
> >>RM service, on its own, can only set the group size to 1, we might as
> well
> >>simplify the definition and have only a group size of 1.  That would be
> >the
> >>worst case for the number of ACKs and the best case for message latency.
> >>
> >>Regards,
> >>Marty
> >
> >
> >
> >
begin:vcard 
n:Van Huizen;Gordon
tel;work:510-848-1988
x-mozilla-html:TRUE
url:http://www.sonicmq.com
org:Progress Software;XML and Internet Technology
adr:;;14 Oak Park;Bedford;MA;01730;
version:2.1
email;internet:gvh@progress.com
title:Director, Product Management
fn:Gordon Van Huizen
end:vcard