Troubleshooting

Logs

Logs from the test server are written to the file located at $HOME/utilihive/server/flow-server.log on your computer. The server automatically logs several info-level entries related to the creation and removal of flows, as well as errors and warnings.

In most cases, you won’t need to look at this file directly, because the SDK will include all relevant logs in the test report whenever a functional test fails. For example, if a restApi processor points to an OpenAPI resource that does not exist, the IntelliJ terminal will print several server logs that include the following entry:

[1.1] 2021-08-25T10:49:44.750 ERROR [MetercloudFlowServerSystem-akka.actor.default-dispatcher-35] [f:simple-rest-4e7647] FlowSourceActor: Transient exception during initialization of source endpoint for flow 'simple-rest-4e7647' for owner 'exampleOwner' ClientIllegalStateException: API 'OpenAPIv3:my-api-spec:latest' was not found for flow 'simple-rest-4e7647' and ownerId 'exampleOwner'

Note how the log references the flow’s test ID, simple-rest-4e7647. This is important when you are running concurrent tests against similar flows, because the logs will become intertwined. You can verify which flow belongs to which test by checking the assigned ID in the following log:

[1.1] 2021-08-25T10:42:30.163136 Starting test 'E01SimpleRestFlowTest > E01 GIVEN deployed echo flow WHEN sending a value THEN the value is echoed back' [id: 4e7647].

In this example, [id: 4e7647] matches simple-rest-4e7647.

If you are having trouble pinpointing a log when a full test suite is executed, it might be easier to run a single test to cut down on the number of IDs that show up.

Handoff Logging

Logs can be a great way to trace the processing of messages through collaborating flows. In the following example, the distribution-api flow is seen delivering a message, followed by two handoff flows that deliver the same message:

[1.1] 2021-08-25T12:10:30.008 INFO [MetercloudFlowServerSystem-akka.actor.default-dispatcher-26] [f:distribution-api-2dd99c] FlowSourceActor: Delivering message with messageId: '082c71a6-c170-459a-8c2c-55e2197bcbae' and principal: testUser. [msg: REST POST http://localhost:8070/exampleOwner/rs/distribution-api-2dd99c/echo]

[1.1] 2021-08-25T12:10:30.011 INFO [MetercloudFlowServerSystem-akka.actor.default-dispatcher-22] [f:distribution-target-1-2dd99c-handoff] FlowSourceActor: Delivering message with messageId: '082c71a6-c170-459a-8c2c-55e2197bcbae' and principal: testUser. [msg: REST POST http://localhost:8070/exampleOwner/rs/distribution-api-2dd99c/echo]

[1.1] 2021-08-25T12:10:30.012 INFO [MetercloudFlowServerSystem-akka.actor.default-dispatcher-22] [f:distribution-target-2-2dd99c-handoff] FlowSourceActor: Delivering message with messageId: '082c71a6-c170-459a-8c2c-55e2197bcbae' and principal: testUser. [msg: REST POST http://localhost:8070/exampleOwner/rs/distribution-api-2dd99c/echo]

Server Shutdown

The test server automatically shuts down after a certain period of inactivity. In the rare event that the server becomes stuck and/or isn’t shutting down on its own, you can manually stop it using the following methods, based on your OS:

macOS / Linux

Make a POST request to the server’s /shutdown endpoint. Using curl, that process would look like the following:

curl -X POST http://localhost:8071/actuator/shutdown

If the server still won’t shut down, you can forcefully stop the underlying Java process by first finding the PID of the server and then stopping that PID with the following commands:

jps | grep server.jar
kill -9 <PID of server.jar>

Windows

Close the command line window called "flow-server run.bat." If the window asks, "Terminate batch job (Y/N)?" then answer y and press Enter.

If it seems like the server is still running, you can forcefully stop the underlying Java process by first finding the PID of the server and then stopping that PID with the following commands:

jps | findstr "server.jar"
taskkill /F /PID <PID of server.jar>