W3C home > Mailing lists > Public > public-ws-addressing-tests@w3.org > February 2006

RE: Use of conversation in the 'observer' causing problems

From: Jonathan Marsh <jmarsh@microsoft.com>
Date: Fri, 10 Feb 2006 12:52:52 -0800
Message-ID: <37D0366A39A9044286B2783EB4C3C4E80192DCBF@RED-MSG-10.redmond.corp.microsoft.com>
To: "David Illsley" <david.illsley@uk.ibm.com>, <public-ws-addressing-tests@w3.org>
I added those lines, and while the precise reason is fuzzy now, I think
it was to try to hack around the difference between the values of the
@message attribute in the WS-I logs and the Microsoft logs.  So if
nothing has changed I suspect that the fix will not fix reds as much as
move them.  The fix you suggest is just part of the complete fix for



From: public-ws-addressing-tests-request@w3.org
[mailto:public-ws-addressing-tests-request@w3.org] On Behalf Of David
Sent: Wednesday, February 08, 2006 12:51 PM
To: public-ws-addressing-tests@w3.org
Subject: Re: Use of conversation in the 'observer' causing problems


Replying to myself.... a slippery slope. 
I've done a little digging and the specific change I'm proposing is in
<sch:rule context="log:message[@testcase='{$testcase}'][@message='1' and
(not(@conversation) or @conversation!='2')]/log:content"> 
context="log:message[@testcase='{$testcase}'][@conversation='2' or

By my estimate this will (accurately) turn about 8 reds green and I
can't see a downside... 

N.B. This is not a fix for the async cases but for ALL 2 way SOAP1.2
messages between Sun->IBM and IBM->Microsoft... and who knows which WS-I
files in the future. 


David Illsley
Web Services Development
IBM Hursley Park, SO21 2JN
+44 (0)1962 815049 (Int. 245049)

David Illsley/UK/IBM@IBMGB 
Sent by: public-ws-addressing-tests-request@w3.org 

08/02/2006 09:01 






Use of conversation in the 'observer' causing problems




In the Sun ->IBM and IBM->Microsoft columns, a bunch of tests are
failing (all 12xx where xx>=30) because 2 'conversations' were used to
capture the logs. 
I haven't had time to fully back track this to the source (the observer
is a bit of a black box for me) but I can see that the problem is being
caused by matches such as: 
<xsl:template match="log:message[@testcase='test1230'][@conversation='2'
or @message='2']/log:content" priority="3999" mode="M30"> 
in processor-xmlout.xsl This means that a message 1 in a conversation 2
is having the message 2 assertions run against it. 

I'm guessing these refrerences to conversationid were added to help with
the async case but I don't believe they are doing this at the moment. 
Since there is no way to predict the way that clients and servers will
behave with regards to keep-alive and conversations I propose that
references to the conversationid be removed from the observer and it be
based entirely on messageid (which is consistent with all the recent
proposals for the async case I've seen). 


David Illsley
Web Services Development
IBM Hursley Park, SO21 2JN
+44 (0)1962 815049 (Int. 245049)
Received on Friday, 10 February 2006 20:52:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:29:01 UTC