Jiri Danek created ARTEMIS-1330:

             Summary: [DISCUSS] Run JMS tests over many protocols (through 
different JMS client libraries)
                 Key: ARTEMIS-1330
                 URL: https://issues.apache.org/jira/browse/ARTEMIS-1330
             Project: ActiveMQ Artemis
          Issue Type: Test
          Components: AMQP, OpenWire
    Affects Versions: 2.3.0
            Reporter: Jiri Danek
            Priority: Minor

Currently, there are three sets of JMS tests in Apache ActiveMQ Artemis 
codebase (that I know of)


The first two are being run only through the Core JMS client, while the last 
one is being run through Qpid JMS client (with few exceptions).

It should be beneficial to be able to run all JMS tests through all three 
protocols that Artemis supports that have a JMS client, these being

* Core (artemis-jms-client),
* OpenWire (activemq-client), and
* AMQP (qpid-jms-client).

I made an attempt to convert some of the tests to a parametrized test with 
changeable connection factory. The way 
currently does it.

There are the following obstackes

* Some tests go beyond the JMS standardized APIs and cast the JMS object to 
specific implementations in their chosen library.
* Some tests require specific settings on the connection factory, these are not 
portable across different JMS clients. There will have to be branching 
depending on the specific factory currently in use, or something...
* OpenWire client supports JMS 1.1, while Core and AMQP clients are JMS 2.0, 
some tests will have to be skipped on OpenWire
* OpenWire client has different semantics of {{receiver.receiveNoWait()}} call; 
when there are no messages in prefetch cache, OpenWire returns null, while 
other clients do a round trip to server to check for new messages before giving 

There are some improvements which can be considered later, some of these are 
partially implemented in various places

* share broker between individual tests
* use random name or random suffix for created addresses and queues use suffix 
for queues/topics to ensure isolation
* have broker uberconfig for all tests, or group tests by config they need, so 
that reconfiguring broker is limited
* that also allows tests to run in parallel
* use random port for acceptor on broker, can run tests even more parallel, and 
mitigates environmentally caused failures

I intend to report the failures I found so far and I am reasonably certain they 
are actual failures. The rest I plan to note in comments here, one test per 

If you happen to have any comments and suggestions how to do this better, I'd 
be glad to hear them.

This message was sent by Atlassian JIRA

Reply via email to