A-Stack Runtime Error Message
Below are the list of critical runtime error messages that must be looked for in a deployed A-Stack environment.
| Error Type | Message | Grep String | Description |
|---|---|---|---|
| ERROR | %s is used for %s more than %s msec", this, time, maxAllocTime | " is used for " | One of the TQL to SQL Mapped query is taking more than 6000 millisecond (default max time) to return. Slow DB responses will severely degrade the performance of the runtime and may result in backed up queues, and client connection time outs. Revisit modeling, check for Database performance. |
| ERROR | %s save error[%s]: %s.%s.%s:%s=%s cn, exc.getSQLState(), aInstance, aAttribute, strOrder(aOrder) | " save error " | Error while Saving TQL Model. |
| ERROR | %s update error[%s]: %s.%s.%s:%s=%s cn, exc.getSQLState(), aInstance, aAttribute, strOrder(aOrder) | " update error" | Error while Updating TQL Model Attribute |
| ERROR | %s create error[%s]: %s.%s.%s cn, exc.getSQLState(), aInstance, aAttribute, strOrder(aOrder) | " create error" | Error while Creating TQL Model Attribute |
| ERROR | %s delete value error[%s]: %s.%s.%s Parameters are: cn, exc.getSQLState(), aInstance, aAttribute, strOrder(aOrder) | " delete value error" | Error while Deleting TQL Model Attribute |
| ERROR | Network peer connect failed for:\n%s | "Network peer connect" | Peer connection has failed. Check for error and resolve it. Peers will try reconnect indefinitely. |
| ERROR | Peer message not sent:\n%s | "Peer message not sent" | Peer is not able to send message across to one of connected peer in cluster. |
| ERROR | error("Memory alarm %s: %.4f: channel(%s/%.4f) closed: %s", alarmCount, alarm, strFacetTitle(facet), importance, String.valueOf(chl)); | "Memory alarm " | Based on the Alarm value set, the Channel will reject incoming requests. |
| ERROR | Response lost: %s\n'%s'", server, strMessage(msg, maxPrintLength) | "Response lost" | Clients may have timed out and the response was not sent to client. This is indicative of busy or loaded (burst) of connections on a transport (Http) |
| WARN | %s Forbidden: No facet ID\n'%s'\n", String.valueOf(chl), NettyUtils.strMessage(msg, maxPrintLength) | "No facet ID" | Some external client is trying to access the EndPoint this is not available. Make sure we don't get lot of these messages in bunch - may be due to Spamming or some application has hard wire the Facet Id. Facet Ids are meant to be dynamic in nature with timeouts. |
| WARN | ModifyPipeline: AutoClosed(%s): %s", timeout, pipeline | "MofiyPipeline: AutoClosed" | Some Protocol Handler has auto closed after number of attempts |
| WARN | "%s: Maximum queue size (%d) reached: %d", getName(), defMaxQueueSize, size Example: TestFacet: Maximum queue size (1000) reached: 1000. Maximum queue size. Maximum queue size is configured via sff.max.queue.size parameter | " Maximum queue size " | This is usually indicative that the server is busy and the processing is more time than the new items to process. Look for NullChannleCount value, This will be higher as well. |
| WARN | Network peer %s at %s is not available", qname, p_key | " Network peer " | When cluster node is unable to connect to one of the peer. |
| WARN | Connection refused:%s Example: SffTcpClient:855 IO error in SffNetworkFacet:wsNotificationCluster-3130539813663882016:ws>NioClientSocketChannel[id: 0x156d1566]; Caused by: java.net.ConnectException: Connection refused: /199.199.199.169:8082 | " IO error " | Connection exception while connecting to a peer. |
Error Handling in Applications
Error handling is critical aspect of developing applications in any programming language. Error handling is a mechanism where applications can notify error conditions to end users. A-Stack is a collection of number of atomic domain languages, the error handling varies based on language the application is using. Error handling in A-Stack can be classified into three broad categories -
- Error handling in NewFacetInstances
- Error handling as part of process code in non-workflow definition language.
- Error handling in Workflow Definition Language
Trapping Errors in NewFacetInstances
A-Stack provides <OnError> event as part of Facet life-cycle which can be used
Trapping Errors in Queries
All TQL exceptions are caught by the TQL facet itself and reported in query/attribute status. TQL exceptions are not passed to error handler and instead we should check the status instead. In the example below we check for Find status value and make changes to the response.
Step to Check for Find Status is:
<If Condition="$Response.Message.Value.Find/Status eq 'Error'"> </If>
<Query>
<Find Format="Version">
<VendorInfo1>
<vendorId>
<NE>
</NE>
</vendorId>
</VendorInfo1>
</Find>
<If Condition="$Response.Message.Value.Find/Status eq 'Error'">
<Then>
<AddResponseData>
<Key>
Message.Value.Error.Message
</Key>
<Value>
[:$Response.Message.Value.Find.Error:]
</Value>
</AddResponseData>
<AddResponseData>
<Key>
Message.Value.Error.Code
</Key>
<Value>
1002
</Value>
</AddResponseData>
<SetResponseData>
<Key>
Message.Value.Find
</Key>
<Value>
</Value>
</SetResponseData>
</Then>
</If>
</Query>
Response will be as below:
<Error>
<Message>TQL Find failed: java.lang.IllegalArgumentException: {[3:6,8:19]} Target data model not found: VendorInfo1</Message>
<Code>1002</Code>
</Error>
<Find/>