[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: RM Group Definitions
I certainly am!
Chris
Gordon van Huizen wrote:
>
> 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
> > >
> > >
> > >
> > >
--
_/_/_/_/ _/ _/ _/ _/ Christopher Ferris - Enterprise Architect
_/ _/ _/ _/_/ _/ Phone: 781-442-3063 or x23063
_/_/_/_/ _/ _/ _/ _/ _/ Email: chris.ferris@East.Sun.COM
_/ _/ _/ _/ _/_/ Sun Microsystems, Mailstop: UBUR03-313
_/_/_/_/ _/_/_/ _/ _/ 1 Network Drive Burlington, MA 01803-0903
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC