[ https://issues.apache.org/jira/browse/UIMA-1120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jerry Cwiklik closed UIMA-1120. ------------------------------- Resolution: Fixed Fix Version/s: 2.3AS Modified Uima AS client code to check for system property NoTTL and disable use of TTL if the property is set. Modified README to document how to disable TTL. > UIMA AS use of TimeToLive can lead to service request failures. > --------------------------------------------------------------- > > Key: UIMA-1120 > URL: https://issues.apache.org/jira/browse/UIMA-1120 > Project: UIMA > Issue Type: Bug > Components: Async Scaleout > Affects Versions: 2.2.2 > Reporter: Eddie Epstein > Assignee: Jerry Cwiklik > Fix For: 2.3AS > > Attachments: uimaj-as-activemq-UIMA-1120-patch-Release-2-2-2.txt, > uimaj-as-activemq-UIMA-1120-patch.txt > > > 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. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.