[
https://issues.apache.org/jira/browse/UIMA-1120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eddie Epstein closed UIMA-1120.
-------------------------------
Resolution: Fixed
As Jerry said, defining a JVM parameter "NoTTL" will turn off the use of
timeToLive for remote service requests. A convenient way to set this parameter
is by adding -DNoTTL to the env parameter UIMA_JVM_OPTS before running
deployAsyncService and/or runRemoteAsyncAE, as needed.
The only problem reported with TTL is for C++ services started with
deployCppService: the service will quietly fail to receive requests when the
clock on the service machine is faster than the clock on the requesting machine
by more than the timeout value.
> 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
> 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.
