I was really impressed and thought how to make it run on DataPower. There is no "sleep" or "delay" function among the DataPower extension functions for XSLT/XQuery/JSONiq besides the <dp:url-open> timeout trick (for development purposes only!). So I looked at GatewayScript and remembered my previous posting on GatewayScript timers, and this posting shows how to do sleepsort based on GatewayScript timers, but some tricks are needed.

The first problem that needed to be solved was how to pass an argument to a (anonymous) timeout function -- that was solved easily via some googleing, just pass arg1 [, arg2, ...] after the timeout value (in milliseconds) in setTimeout().

Next problem specifically to setTimeout solution for sleepsort was how to output the result [by session.output.write()] after the last timeout has fired. My first solution was to setup an additional timeout longer than all values to be sorted, but without knowing the maximum value that was difficult, and not nice.

The next idea was better, making use of the fact that only the last session.output.write() wins in sending the response back, just define two timeouts for each number to be sorted:

timeout at x millisecond for number x, and timeout function appending x to result array when timeout fires

timeout at x+1 millisecond writing the (current) result to session.output

OK, now we have 2N timeouts for sorting N numbers, but the final result gets written last and therefore returned.

Of course there is the problem that sorting might not be correct if too many numbers get sorted and race condifions between timeouts might occur. Interestingly sorting 20000 numbers works always fine in GatewayScript(!).

I did pipeing the output of sleepsort.js into sleepsort.check.js in order to find occurences of incorrect sortings:

Now the XC10 URL Opener can be "misused" (for development, see previous posting on this) to provide sub-second latencies.And you do not have to possess a XC10 for doing so ;-)

So how is it done?First we have to define a "XC10 Grid" -- lets name it "delay".Lets fill in 300 (milliseconds) for Timeout, Grid Name "g", User "u" and Password "p",Then create a new "Collective" named "c", switch to "Members" tab, and add a new member with "Actual Host" as "1.2.3.4".Clicking two times "Apply" we are done on the configuration side.

Now a 300ms delay can be simply achieved by this "xc10:" <dp:url-open> call, see InfoCenter on format:

Doing some measurements with stylesheet xc10.xsl listed further below shows that timing is pretty accurate.Of course we have to measure "inside" the stylesheet -- we could do by "stylesheet profiling" and <dp:region>.Here the simpler approach based on "dp:time-value()" is used.As can be seen here we see 16ms-23ms for 10ms configured (this is minimal value), 106ms-114ms for 100ms configured and 308ms-310ms for 300ms configured in "delay" XC10 grid object:

<EDIT>Just learned this from a colleague:"I have seen some environments where this trick does not work, because even for unreachable addresses on the network, their networking equipment responds immediately failing the request"</EDIT>

During development sometimes the real backend service a DataPower service should connect to might not be available.

In this case we could set variable var://service/mpgw/skip-backside to 1 for a Multi-Protocol Gateway service.This makes the MPGW service a loopback service and we could provide dummy backend response data.

The difference to connecting to a real backend is just the latency -- no real backend has 0 latency.

While there is no specific DataPower command to add latency to a service or stylesheet (like Unix "sleep" command)we can use a simple workaround I learned from a colleague yesterday.Just try to open a network connection to a non-existent IP address with <dp:url-open ...> and specify the timeout you are interested in: