activemq-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ARTEMIS-1507) ActiveMQConnectionTimedOutException is thrown even though no timeout expired
Date Tue, 07 Nov 2017 07:49:00 GMT

    [ https://issues.apache.org/jira/browse/ARTEMIS-1507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16241640#comment-16241640
] 

ASF GitHub Bot commented on ARTEMIS-1507:
-----------------------------------------

GitHub user dudaerich opened a pull request:

    https://github.com/apache/activemq-artemis/pull/1649

    ARTEMIS-1507 ActiveMQConnectionTimedOutException is thrown even though no timeout expired

    When the execution of code jumps out of the while cycle,
    it should check whether the blocking-call-timeout expired or not.
    If no, ActiveMQUnBlockedException should be thrown
    instead of ActiveMQConnectionTimedOutException.

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/dudaerich/activemq-artemis ARTEMIS-1507

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/activemq-artemis/pull/1649.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #1649
    
----
commit 5f8cef98659eff02d33f89105b53eabf9996379a
Author: Erich Duda <dudaerich@gmail.com>
Date:   2017-11-03T14:29:57Z

    ARTEMIS-1507 ActiveMQConnectionTimedOutException is thrown even though no timeout expired
    
    When the execution of code jumps out of the while cycle,
    it should check whether the blocking-call-timeout expired or not.
    If no, ActiveMQUnBlockedException should be thrown
    instead of ActiveMQConnectionTimedOutException.

----


> ActiveMQConnectionTimedOutException is thrown even though no timeout expired
> ----------------------------------------------------------------------------
>
>                 Key: ARTEMIS-1507
>                 URL: https://issues.apache.org/jira/browse/ARTEMIS-1507
>             Project: ActiveMQ Artemis
>          Issue Type: Bug
>          Components: Broker
>    Affects Versions: 2.3.0
>            Reporter: Erich Duda
>
> This issue was hit in test {{MultiThreadRandomReattachTest}}. There are several client's
threads doing some work, while connection fail is simulated. The test expects that all threads
finish without exceptions.
> This issue causes that some client's threads sometime fail with an exception {{AMQ119014:
Timed out after waiting 30,000 ms for response when sending packet XXX}}.
> As you can see in the following test output, the {{ActiveMQConnectionTimedOutException}}
is thrown even though the test ran only few milliseconds, so the 30 seconds timeout cannot
expire.
> There is an issue in {{ChannelImpl::sendBlocking}} method.
> {code:java}
> while (!closed && (response == null || (response.getType() != PacketImpl.EXCEPTION
&& response.getType() != expectedPacket)) && toWait > 0) {
>    try {
>       sendCondition.await(toWait, TimeUnit.MILLISECONDS);
>    } catch (InterruptedException e) {
>       throw new ActiveMQInterruptedException(e);
>    }
>    if (response != null && response.getType() != PacketImpl.EXCEPTION &&
response.getType() != expectedPacket) {
>       ActiveMQClientLogger.LOGGER.packetOutOfOrder(response, new Exception("trace"));
>    }
>    if (closed) {
>       break;
>    }
>    final long now = System.currentTimeMillis();
>    toWait -= now - start;
>    start = now;
> }
> if (response == null) {
>    throw ActiveMQClientMessageBundle.BUNDLE.timedOutSendingPacket(connection.getBlockingCallTimeout(),
packet.getType());
> }
> {code}
> bq. When waiting upon a Condition, a "spurious wakeup" is permitted to occur, in general,
as a concession to the underlying platform semantics. This has little practical impact on
most application programs as a Condition should always be waited upon in a loop, testing the
state predicate that is being waited for. An implementation is free to remove the possibility
of spurious wakeups but it is recommended that applications programmers always assume that
they can occur and so always wait in a loop. \[1\]
> \[1\] https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/locks/Condition.html
> As it is stated in the JDK API documentation, the {{sendCondition.await}} can "spuriously
wakes up" so in the body of while cycle it should be checked the state of conditions to which
the thread waits.
> If the thread wakes up and the channel is closed, the thread jumps out from the while
cycle, but after the cycle there is no check if the timeout expired or not. The first check
is whether response is null or not. In this case the response is null so the timed out exception
is thrown.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Mime
View raw message