W-16941297: SG timeout issue

[anandkarandikar]

Ticket

W-16941297

Description

Attempting to add a test piggybacking on existing SG timeout test and a flow demonstrating use of

mule-integration-tests/integration/src/test/resources/lazy-routes.xml

Lines 16 to 24 in b0be565

	<flow name="select-inside-scatter-gather">
	<scatter-gather>
	<route>
	<db:select config-ref="config">
	<db:sql>select * from sys.syscolumns</db:sql>
	</db:select>
	</route>
	</scatter-gather>
	</flow>

Alternatives considered

Derby Database

Tried using the existing derby database config, and use derby db in embedded mode. However, the derby db doesn't have a SLEEP equivalent function.

There's a potential solution where a Java method that invokes Thread.sleep() could be registered as a UDF (User Defined Function) but that requires a restart and also the classpath property modification. After a successful registration, there is a way to run the sql from java code as below:

String sleepSQL = "VALUES org.example.derby.SleepExample.sleep(2000)";
stmt.executeQuery(sleepSQL);

where org.example.derby.SleepExample.sleep is the java method that calls Thread.sleep.

Although in theory it looks very procedural but it may not work for the integration tests because there's seems to be a restart step for an embedded db that runs during the lifetime of the tests. After numerous tries, it felt very uneasy to go down this route.

H2 Database

Having H2 database for a test requires adding dependency in the pom for example:

<dependency>
      <groupId>com.h2database</groupId>
      <artifactId>h2</artifactId>
      <version>2.1.214</version> <!-- Use your preferred version -->
</dependency>

Using the Embedded H2 Database

DB Config in the mule flow

Make sure to configure the flow with the following db config H2_Database_Config and use it in the db:select

<db:config name="H2_Database_Config" doc:name="Database Config" >
	<db:generic-connection url="jdbc:h2:~/dummyDB" driverClassName="org.h2.Driver" user="sa" />
</db:config>

DB Alias for SLEEP

This is needed because like Derby DB, the H2 DB also doesn't have an inbuilt SLEEP function.

<db:execute-ddl doc:name="Execute DDL" config-ref="H2_Database_Config">
	<db:sql ><![CDATA[DROP ALIAS IF EXISTS SLEEP]]></db:sql>
</db:execute-ddl>

<db:execute-ddl doc:name="Execute DDL" config-ref="H2_Database_Config">
	<db:sql ><![CDATA[CREATE ALIAS SLEEP FOR "java.lang.Thread.sleep"]]></db:sql>
</db:execute-ddl>

Followed by the flowRunner invocation of the test flow that's reproduces the scenario

An oversimplified version.

<flow name="select-with-timeout-inside-scatter-gather">
        <scatter-gather timeout="${scatterGather.timeout}">
            <route>
                <db:select config-ref="config">
                    <db:sql>select sleep(10)</db:sql>
                </db:select>
            </route>
            <route>
                <set-payload value="apple"/>
            </route>
        </scatter-gather>
    </flow>

Verification step

TBD - working on this, a rough idea is to use an error-handler in the flow and then execute sql

SELECT EXECUTING_STATEMENT FROM INFORMATION_SCHEMA.SESSIONS

This is somewhat equivalent to running this in mysql

show full processlist;

[anandkarandikar]

Why 10s ?
Referring to the earlier flow "timeout", it seems that the following set-payload
<set-payload value="#[java!org::mule::tck::junit4::AbstractMuleContextTestCase::sleepFor(payload, 10000)]"/>

will timeout. So, select sleep(10) is just following the suite.

[sonarqube-as-a-service]

SonarQube Quality Gate

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication