Re: [wsrm] Discussion on Issues Rel 108 and 115

[Tony Graham <Tony.Graham@Sun.COM>]

Sunil Kunisetty <sunil.kunisetty@oracle.com> wrote at Sun, 15 Feb 2004 21:50:50 -0800:
...
>  Conceptual changes (major):
> 
>   1. Changes in persistence model:
>        1. We now end up persisting non-expired some faulty messages. Note
            that messages that caused PermanentProcessingFailures may
            or not be persisted in the first place.

I don't know why you'd persist a whole message instead of just the
message's identifier and its fault type.

>        2. Definition of MessageOrder and DuplicateElimination has to change
            (slightly) since we persist faulty messages also. So a
            duplicate message is deleted only if the earlier message
            was not faulted. Something similar has to be said for
            Message Ordering.

This applies only if you persist entire messages.

Do you also persist entire non-fault messages that have yet to be the
subject of a PollRequest message?

>  Conceptual changes (minor):
> 
>   1. Poll response will now be different than Callback and Response
>      reply pattern responses. So implementation logic to handle them
>      will have to be different.

Actually, I see reporting faults in a poll response as being more
similar to the Callback and Response cases than not reporting faults
could be.  So much so that I had trouble crediting that you couldn't
report faults in a poll response.

Where I stumble on not reporting faults in a poll response is that not
reporting faults makes a fault indistinguishable from a lost message,
with the result that the sending RMP will just keep resending the
faulty message until it reaches the maximum number of resends or the
message's expiry time.

>   2. Have to be mentioned that only non-expired message faults will
>      be sent back.

Tom has answered that in the affirmative.

>   3. Have to be mentioned that not all non-expired faulty message's
>      faults can be sent back as some messages can cause fatal errors
>      (those that cause PermanentProcessingFailures faults).

Is the same true for the Callback reply pattern?

> Problems with the proposed schema (minor, can be fixed):
...

>  While we can still address all the above either explicitly saying
>  so in the specification, it will have a big impact on the schema
>  and specification and will delay the public draft atleast by a
>  month. What concerns me more is why this issue is being raised so
>  late in the game, when we already decided not to have this fault
>  sending feature for polls long time back. I wish the issue was
>  raised at that time only.

Forgive me for taking a while to comprehend that faults were to be
indistinguishable from lost messages, but the issue could have come up
in the public review (and still may, depending on how Rel 108/115 is
resolved) and would still have to be resolved.

Regards,


Tony Graham
------------------------------------------------------------------------
Web Products, Technologies and Standards           Phone: +353 1 8199708
Sun Microsystems                                              x(70)19708
East Point Business Park, Dublin 3, Ireland