UIMA-AS Testing Utilities

A brief guide to the utilities for helping to construct uima-as test cases

Last updated: October, 2013

Test cases run lots of asynchronous parts. The main flow is to have a test case set things up, and then set up 1 or more monitor threads that will await various latch countdowns (EXCEPTION, CPC, PROCESS). The monitor threads are "joined" back in the main thread. There's an extra semiphore that is used to delay sending the first CAS until all monitor threads have started up.

CASes in the system are assigned Cas Ref Ids, which are UUIDs.

There are 2 support / utility classes, with this inheritance:
BaseTestSupport -> ActiveMQSupport -> TestCase

ActiveMQSupport

Starting / stopping broker(s)

BrokerConnectors

BaseTestSupport

Inherits from ActiveMQSupport

deployService(asyncEngine - to hold ref, deploydescriptorPath) returns UUID string uses SystemProp: BrokerURL or tcp://localhost:8118, sets defaultBrokerURL

addxceptionToIgnore, ignoreException

initialize(asyncEngine, appCtx) calls initialize on engine after adding statusCallbackListener of listener which is set to a new instance of UimaAsTestCallbackListener, a subclass of this class

buildContext(top-level-svc-broker-uri, top-level-queue-name, [timeout default 0]) returns appCtx map sets CasPoolSize to 4, ReplyWindow to 15

isMetaRequest(Message)

spinMonitorThread(ctrlSemaphore, howMany, kind) returns thread that will wait for howMany count-downs; returned threads are typically joined. Kind/latches: cpcLatch, exceptionCountLatch, processCountLatch

waitUntilInitialized() signalled by callback, set up for one use per test instantiation initializeMonitor, initialized

waitOnMonitor(Semaphore) used to wait until all monitor threads are spun

runTestWithMultipleThreads(svc-deploy-descr, q-name, how-many-CASes=per-thread, how-many-threads, timeout, getmeta-timeout, [fail-on-timeout]) engine = new asyncEngine deploy into engine, initialize engine if fail-on-timeout, set timer task to undeploy in 5 seconds spin up runner threads and have them send CASes, one at a time wait till all CASes received, then wait till CPC done

runCrTest(engine, howMany) Run using collection reader set engine from the passed-in engine The engine needs to be set up with a collection reader and the standard listeners to count down the PROCESS_LATCH

runTest(2)(appCtx, engine, brokerUri, q-name, howMany, latchKind, is-async-send) sets engine if latchKind is EXCEPTION_LATCH, use 1 thread for running client, else use 2 - one for client, and one for CPC if runTest, send all CASes at once (up to pool limit) up to howMany. If runTest2, send each CAS 1 at a time, and wait until it is complete including CPC. After howMany CASes, send CPC and wait for completion.

sendCAS(engine, howMany, isAsync) Gets CAS from casPool, sets doc txt, calls sendCas or SendAndReceiveCAS

spinShutdownThread(asyncEngine, when, [springContainerIds, stop_now or quiesce]) after specified delay, tops either the async engine, or the deployed things. Used to test recovery from svcs dying

UimaTestCallbackListener

onBeforeProcessCAS writes logmsg to sysout

onBeforeMessageSend writes Received ... notivication with CAS [casRefId] sets casSent to casRefId)

onUimaAsServiceExit logs msg with cause

entityProcessComplete might have performance metrics or not... verifies (on exception) receivedExpectedParentReferenceId For successful test, gets processTraceEvents, checks duration is what's expected expectedProcessTime For perform metrics: add per-component-performance-metrics to sysout log

isProcessTimeout

initializationComplete

collectionProcessComplete

SimpleCallbackListener

extends UimaTestCallbackListener, overrides entityProcessComplete with a much simpler check/report