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

[Sunil Kunisetty <Sunil.Kunisetty@oracle.com>]

Tony Graham wrote:

> 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.

 That's what I meant though it wasn't explicit. As of now, we don't even persist the
 meta information of the message for faulty messages. So that's the difference.

 Btw, we not only need to persist the id and the fault type, but also the expiry time
 and if the vendor is supporting sending the fault detail string or fault exception,
 he may have to persist that too.


>
> >        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.
>

 No it applies even if we persist the meta information. See my response to Tom's concern
 in the coming mail for details.

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

 Couple of things:
 - We have to persist the entire messages that are being buffered in the message order
   case.
 - While the spec. doesn't prohibit persisting the entire messages for non buffered messages,
   it used to have a clause that recommends only persisting the meta information. However,
   I believe we even removed that recommendation clause. So it is upto the vendor to persist
   the entire message or just the meta information for non-buffered (delivered) messages.


>
> >  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.

 I understand that there is a small segment of use cases that will be left
 over if we don't support sending faults with Poll, however, the
 complications of implementing seems to have out weighed the
 benefits, atleast in my opinion.
   - One can always use Callback or Response pattern in the retry
      to get the fault back. So the only case that will be left over is the
      one way sender behind the firewall.
   - The solution still can't solve the problem 100% as expired message's faults
     and those that cause fatal errors won't be reported.




>
> 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?

 No, it's not. For Callback and Response reply pattern, they will get a
 InvalidExpiryTime fault back.

>
>
> > 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.

 I understand, but my concern is this seems to be a trend. People are
 not reading mails and not doing homework and bringing up issues
 in the con. call that are thoroughly discussed in the mails. Again,
 I'm not saying this is the case here, but that seems to be trend of late.
 My worry is that we are already couple of months behind our original
 schedule and this will further derail it.


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