Hi Jim,

Thanks for the patch. Wrt your questions:

- Lost message. There are two ways to think about this depending on how we 
decide to continue to handle routing and correlation. The options for this 
are, ideally: (1) continue to use routing tables, which can lead to issues 
like the one raised by your question, and (2) replace routing tables by a 
'stack' of addresses carried by a message. One simplistic way of dealing 
with a lost message in option one is to time out table entries at some 
point, but this may only may an option that does not require routing 
tables that need to be persisted more appealing.
The second option is in essence what you had proposed at some earlier 
point, and it has the advantage of not requiring maintenance of routing 
tables at each 'node' of the routing tree (i.e, each composite reference 
between the originating atomic component and any given remote boundary or 
composite service). One way to handle lost messages in this option is to 
enact a light-weight end-to-end reliability protocol for messages over 
multiple hops, where the fact that a message has been sent is persisted at 
the point of origin and it is not deleted until it has been acknowledged.

- Durable routing tables. The short answer is that we may not need to do 
this if we opt for light-weight end-to-end reliability.

- Message ids. Yes, we should come up with a more robust way of uniquely 
identifying messages, perhaps using UUIDs or some other such scheme. 
Millisecond timestamp-based ids is only an initial try at it.
.            .           .          .         .        .       .      .  . 
   .   .  . .
Ignacio Silva-Lepe
[EMAIL PROTECTED]
Phone: (914) 784 7003  Fax:   (914) 784 6807



Jim Marino <[EMAIL PROTECTED]> 
09/11/2006 02:48 AM

To
Ignacio Silva-Lepe/Watson/[EMAIL PROTECTED]
cc

Subject
committed patch






Hi Ignacio,

I committed the patch over the weekend. I had a couple of questions 
about the routing tables and wanted to get your thoughts on how these 
scenarios would be handled:

- A message is "lost" during an invocation after several hops. How 
will the mapping tables cleaned up?
- When we need to make the routing tables durable (probably at remote 
boundaries), what do you think is the best way to do that?
- Do you think we should make message ids more unique than one per 
millisecond?

I'm going to be online sporadically this week so if you can post 
small patches as you proceed it will help me post them quicker. Also, 
we can probably catch up through email and phone at some point if 
needed.


Thanks,
Jim


Reply via email to