[
https://issues.apache.org/jira/browse/UIMA-3437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13826649#comment-13826649
]
Marshall Schor commented on UIMA-3437:
--------------------------------------
I think this path is caused by the test case setup - it deploys a service, then
undeploys it without sending anything. The "listener" code in the Spring JMS
DefaultMessageListenerContainer implementation has what appears to be a small
initialization bug. When the listener throws an exception (lost the connection
- or something like that, which I was able to see was happening), it examines
an private instance variable, lastMessageSucceeded. This is not initialized,
so it has the initial value "false". This causes the exception handler to
think it's in "recovery" mode, it has a piece of code:
{code}
if (!this.lastMessageSucceeded) {
// We failed more than once in a row - sleep for recovery interval
// even before first recovery attempt.
sleepInbetweenRecoveryAttempts();
}
{code}
which causes the 30 second delay.. One possible fix would be for the UIMA-AS
stop methods to set the recovery interval to 0 or something small (right now
it's 30 seconds), when it's stopping things.
> make the uima-as extended tests go faster
> -----------------------------------------
>
> Key: UIMA-3437
> URL: https://issues.apache.org/jira/browse/UIMA-3437
> Project: UIMA
> Issue Type: Improvement
> Components: Async Scaleout
> Affects Versions: 2.4.2AS
> Reporter: Marshall Schor
> Assignee: Jerry Cwiklik
> Priority: Minor
>
> The extended tests spend a lot of time waiting for timeouts. Find these and
> reduce the timeouts where feasible to make the tests run faster. An example:
> When a service is "undeployed", that process tweaks some code path where the
> Spring JMS code detects a failed communication (in the listener, I think),
> and goes into a retry. This shouldn't be happening.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
