Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
2.2.2
-
None
Description
One common scenario is that a service crashes while processing a processCas request, and additional requests are left in the service request queue. UIMA AS allows timeout values to be set for service requests so that if a reply not received within the timeout period, an error is generated on the client and appropriate actions taken.
What happens to the queued service requests? If the service is restarted, it will attempt to process them and reply to the originating client. If a client receives a reply to a request that had timeout out, it will log and ignore it. If the client has gone away, the service will log and ignore the error when trying to reply. However, some requests may be expensive to process and it is desirable to avoid this work. Other requests may contain stale content that will cause problems for the new service to process.
In order to avoid these problems, when a timeout value is specified UIMA AS sets TimeToLive to the timeout period. A TimeToLive setting allows the JMS system to dispose of requests that cannot be delivered in time, normally transferring them to a "dead letter queue". AMQ 5.0 fully supports this mechanism, but given some blocking issues with AMQ 5.0, UIMA AS had to revert back to v4.1.1 for the first release.
Up until recently our experience was that TimeToLive was ignored in AMQ 4.1.1, but this is not the case. With a AMQ C++ consumer, expired messages will be removed from the queue and thrown away. With a 4.1.1 Java consumer running under some JRE versions (e.g. Sun 1.6_02 on Linux), expired messages will be ignored and left in the queue.
If this is not confusing enough, there is the AMQ definition of TimeToLive: it is based on the absolute time the message was created. Any clock skew between the producer and consumer machines will not be accounted for. For example, if a UIMA AS client is running on a machine whose clock is more than 60 seconds behind the machine running the UIMA AS service, a message request with a timeout of 60 seconds or less will expire before it is sent.
In the future UIMA AS may implement an option to not use TimeToLive at all. The workaround for now is to make sure the clocks on all client and service machines are synchronized.