qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Rudyy (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (QPID-7222) Python test qpid_tests.broker_0_10.message.MessageTests.test_release_order fails sporadically against java broker
Date Thu, 21 Apr 2016 13:27:25 GMT

     [ https://issues.apache.org/jira/browse/QPID-7222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Alex Rudyy updated QPID-7222:
-----------------------------
    Description: 
The test failure like the one below occurs occasionally on jenkins job [Qpid-Python-Java-Test|https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-Python-Java-Test/]:

{noformat}
qpid_tests.broker_0_10.message.MessageTests.test_release_order (from (TEST-python_pre1.0.xml))
Failing for the past 1 build (Since Failed#1002 )
Took 0.11 sec.
Stacktrace

Error during test:  Traceback (most recent call last):
    File "/home/jenkins/jenkins-slave/workspace/Qpid-Python-Java-Test/site-packages/bin/qpid-python-test",
line 340, in run
      phase()
    File "/home/jenkins/jenkins-slave/workspace/Qpid-Python-Java-Test/site-packages/lib/python2.7/site-packages/qpid_tests/broker_0_10/message.py",
line 1028, in test_release_order
      self.assertEquals("message-%d" % (i), msg.body)
    File "/usr/lib/python2.7/unittest/case.py", line 511, in assertEqual
      assertion_func(first, second, msg=msg)
    File "/usr/lib/python2.7/unittest/case.py", line 504, in _baseAssertEqual
      raise self.failureException(msg)
  AssertionError: 'message-8' != 'message-2'
{noformat}

Python test MessageTests.test_release_order tests that released messages are delivered in
correct order.

The test makes the following assumptions:
1) the expected 10 messages are pre-fetched immediately and released messages are not re-delivered
to the first consumer which previously releases them.
2) all released messages are delivered to the second consumer

The 0-10 spec for the message.release states the following:
{quote}
When acquired messages are released, they become available for acquisition by any subscriber.
{quote}

{quote}
Acquired messages that have been released MAY subsequently be delivered out of order. Implementations
SHOULD ensure that released messages keep their position with respect to undelivered messages
of the
same priority.
{quote}

It seems that  test assumptions are not exactly correct, for example, when less then 10 messages
are pre-fetched , it is possible that broker can try to re-deliver  previously  released message
after receiving accept/released commands for pre-fetched messages. That is what happens when
test fails with java broker. It seems that only 7 messages have been pre-fetched by the client.
After receiving  accept/release commands for those prefetched messages, the broker starts
re-delivery of released messages causing test to fail.

In order to fix the test, the following can be done:
# change the test to receive all 10 messages before sending release/accept
# send release/accept after receiving of 10 messages
# close first consumer. It is required, as credit is restored on accept and there is a chance
that message can be redelivered to first consumer instead of second one.
# receive released messages with second consumer after closing first consumer

  was:
The test failure like the one below occurs occasionally on jenkins job [Qpid-Python-Java-Test|https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-Python-Java-Test/]:

{noformat}
qpid_tests.broker_0_10.message.MessageTests.test_release_order (from (TEST-python_pre1.0.xml))
Failing for the past 1 build (Since Failed#1002 )
Took 0.11 sec.
Stacktrace

Error during test:  Traceback (most recent call last):
    File "/home/jenkins/jenkins-slave/workspace/Qpid-Python-Java-Test/site-packages/bin/qpid-python-test",
line 340, in run
      phase()
    File "/home/jenkins/jenkins-slave/workspace/Qpid-Python-Java-Test/site-packages/lib/python2.7/site-packages/qpid_tests/broker_0_10/message.py",
line 1028, in test_release_order
      self.assertEquals("message-%d" % (i), msg.body)
    File "/usr/lib/python2.7/unittest/case.py", line 511, in assertEqual
      assertion_func(first, second, msg=msg)
    File "/usr/lib/python2.7/unittest/case.py", line 504, in _baseAssertEqual
      raise self.failureException(msg)
  AssertionError: 'message-8' != 'message-2'
{noformat}

Python test MessageTests.test_release_order tests that released messages are delivered in
correct order.

The test makes the following assumptions:
1) the expected 10 messages are pre-fetched immediately and released messages are not re-delivered
to the first consumer which previously releases them.
2) all released messages are delivered to the second consumer

The 0-10 spec for the message.release states the following:
{quote}
When acquired messages are released, they become available for acquisition by any subscriber.
{quote}

{quote}
Acquired messages that have been released MAY subsequently be delivered out of order. Implementations
SHOULD ensure that released messages keep their position with respect to undelivered messages
of the
same priority.
{quote}

It seems that  test assumptions are not exactly correct, for example, when less then 10 messages
are pre-fetched , it is possible that broker can try to re-deliver  previously  released message
after receiving accept/released commands for pre-fetched messages. That is what happens when
test fails with java broker. It seems that only 7 messages have been pre-fetched by the client.
After receiving  accept/release commands for those prefetched messages, the broker starts
re-delivery of released messages causing test to fail.

In order to fix the test, the following can be done:
# change the client to receive all 10 messages before sending release/accept
# send release/accept after receiving of 10 messages
# close first consumer. It is required, as credit is restored on accept and there is a chance
that message can be redelivered to first consumer instead of second one.
# receive released messages with second consumer after closing first consumer


> Python test qpid_tests.broker_0_10.message.MessageTests.test_release_order fails sporadically
against java broker
> -----------------------------------------------------------------------------------------------------------------
>
>                 Key: QPID-7222
>                 URL: https://issues.apache.org/jira/browse/QPID-7222
>             Project: Qpid
>          Issue Type: Bug
>          Components: Python Test Suite
>            Reporter: Alex Rudyy
>
> The test failure like the one below occurs occasionally on jenkins job [Qpid-Python-Java-Test|https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-Python-Java-Test/]:
> {noformat}
> qpid_tests.broker_0_10.message.MessageTests.test_release_order (from (TEST-python_pre1.0.xml))
> Failing for the past 1 build (Since Failed#1002 )
> Took 0.11 sec.
> Stacktrace
> Error during test:  Traceback (most recent call last):
>     File "/home/jenkins/jenkins-slave/workspace/Qpid-Python-Java-Test/site-packages/bin/qpid-python-test",
line 340, in run
>       phase()
>     File "/home/jenkins/jenkins-slave/workspace/Qpid-Python-Java-Test/site-packages/lib/python2.7/site-packages/qpid_tests/broker_0_10/message.py",
line 1028, in test_release_order
>       self.assertEquals("message-%d" % (i), msg.body)
>     File "/usr/lib/python2.7/unittest/case.py", line 511, in assertEqual
>       assertion_func(first, second, msg=msg)
>     File "/usr/lib/python2.7/unittest/case.py", line 504, in _baseAssertEqual
>       raise self.failureException(msg)
>   AssertionError: 'message-8' != 'message-2'
> {noformat}
> Python test MessageTests.test_release_order tests that released messages are delivered
in correct order.
> The test makes the following assumptions:
> 1) the expected 10 messages are pre-fetched immediately and released messages are not
re-delivered to the first consumer which previously releases them.
> 2) all released messages are delivered to the second consumer
> The 0-10 spec for the message.release states the following:
> {quote}
> When acquired messages are released, they become available for acquisition by any subscriber.
> {quote}
> {quote}
> Acquired messages that have been released MAY subsequently be delivered out of order.
Implementations SHOULD ensure that released messages keep their position with respect to undelivered
messages of the
> same priority.
> {quote}
> It seems that  test assumptions are not exactly correct, for example, when less then
10 messages are pre-fetched , it is possible that broker can try to re-deliver  previously
 released message after receiving accept/released commands for pre-fetched messages. That
is what happens when test fails with java broker. It seems that only 7 messages have been
pre-fetched by the client. After receiving  accept/release commands for those prefetched messages,
the broker starts re-delivery of released messages causing test to fail.
> In order to fix the test, the following can be done:
> # change the test to receive all 10 messages before sending release/accept
> # send release/accept after receiving of 10 messages
> # close first consumer. It is required, as credit is restored on accept and there is
a chance that message can be redelivered to first consumer instead of second one.
> # receive released messages with second consumer after closing first consumer



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org


Mime
View raw message