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

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

 

________________________________

From: public-ws-addressing-tests-request@w3.org
[mailto:public-ws-addressing-tests-request@w3.org] On Behalf Of David
Illsley
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
mkschema.xsl: 
<sch:rule context="log:message[@testcase='{$testcase}'][@message='1' and
(not(@conversation) or @conversation!='2')]/log:content"> 
to 
<sch:rule
context="log:message[@testcase='{$testcase}'][@message='1']/log:content"
> 
and 
<sch:rule
context="log:message[@testcase='{$testcase}'][@conversation='2' or
@message='2']/log:content"> 
to 
<sch:rule
context="log:message[@testcase='{$testcase}'][@message='2']/log:content"
> 

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 

David Illsley
Web Services Development
IBM Hursley Park, SO21 2JN
+44 (0)1962 815049 (Int. 245049)
david.illsley@uk.ibm.com 



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

08/02/2006 09:01 

To

<public-ws-addressing-tests@w3.org> 

cc

 

Subject

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 

David Illsley
Web Services Development
IBM Hursley Park, SO21 2JN
+44 (0)1962 815049 (Int. 245049)
david.illsley@uk.ibm.com