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

WS-I monitor timing problem - and proposed fix.

From: David Illsley <david.illsley@uk.ibm.com>
Date: Sun, 5 Mar 2006 13:55:25 +0000
To: <public-ws-addressing-tests@w3.org>
Message-ID: <OF7E4C8C36.764EB57D-ON80257128.004A9DED-80257128.004C75CD@uk.ibm.com>
Our solution to the async problems we had assumes that the WS-I log file 
entries are always in the correct time-based order. This is technically 
correct (per the WS-I monitor specification) but doesn't work quite as we 

The HTTP request/response connections appear in the log file in time based 
order of when the connection was closed.

This works fine for all implementations which for 1150,1250 etc 
immediately 202 and return... but a couple of implementations wait until 
the non-anonymous response has been delivered and then 200.This means that 
the 'request' HTTP connection closes after the 'response' connection and 
hence ends up second in the log file. This means that the entries are 
incorrectly numbered and the wrong assertions are applied to each entry.

It's not quite as simple as re-sorting the entries on timestamp as that 
would give an ordering of request1, request2, response2, response1.
My proposed solution is to sort the request entries by timestamp and 
simply slot the associated response entries in after them.

Here is my undoubtedly improvable solution which does appear to fix the 
problem (2 red boxes -> green and more accurate failures for a few others) 
without introducing new ones:

Add the following XSLT to the ws-i processing path immediately after 

<xsl:stylesheet version="1.0" 
        <xsl:output method="xml" indent="yes"/>
        <xsl:template match="l:log">
                                <xsl:sort select="@timestamp"/>
                                <xsl:copy-of select="current()"/>


David Illsley
Web Services Development
MP127, IBM Hursley Park, SO21 2JN
+44 (0)1962 815049 (Int. 245049)
Received on Sunday, 5 March 2006 13:55:28 UTC

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