[
https://issues.apache.org/jira/browse/PROTON-223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13574003#comment-13574003
]
Ken Giusti commented on PROTON-223:
-----------------------------------
>From the mailing list:
Rather than propose specific tests, I'd like to take a step back
and propose that we start by creating a proton-based traffic generator
tool.
I'd like to see us create something along the lines of
qpid-cpp-benchmark/qpid-send/qpid-receive, but derivied from proton.
For those unfamiliar with qpid-cpp-benchmark, et al. This is a tool
that can be used to generate message loads and various traffic
patterns for testing the broker. It consists of a control program,
and a set of clients that generate/consume message flows and output
performance metrics. The clients are created, configured and
controlled by the control program. There are a ton of options that
can be used to configure the traffic patterns, including scaling the
number of clients during the test run.
Running a system test involves setting up the broker(s), then using
the tool to generate a traffic pattern against the broker under test.
The broker configuration and traffic flow characteristics are dictated
by the goals of the test. At the end of the test, the clients report
their performance metrics back to the control program which presents
them as the results of the test.
We can evolve this approach to better match proton's vision of a
distributed messaging world. This would require us to replace the
exising 0.10 based test clients with proton-based clients -
specifically based on messenger. For extra coverage, we implement
these clients in all the languages supported by messenger. These
clients would support an identical managment interface to the control
program. That way we could easily swap client implementations for any
given test. Eg. run a test with Java message producers and PHP based
consumers, repeat with C consumers and Ruby producers, etc.
Unlike the 0.10 clients, the proton clients would support the option
of listening for incoming connections - taa daa - point-to-point cross
language system tests!
And, of course, it would be possible for the clients to be useable
stand-alone - without the control program.
This traffic generator wouldn't be involved in setting up the
system(s) under test, at least not in the short term. This could
change as we develop our stable of proton-based products. For now,
assume each test is setup/configured prior to running the traffic
generator. Ideally, the traffic generator would accept "scripts" that
would describe the traffic flow for a given test.
> Need system-level and soak tests to exercise Proton.
> ----------------------------------------------------
>
> Key: PROTON-223
> URL: https://issues.apache.org/jira/browse/PROTON-223
> Project: Qpid Proton
> Issue Type: Test
> Components: proton-c, proton-j
> Reporter: Ken Giusti
> Labels: performance, system-tests,, testing,
>
> The existing system tests for QPID are, naturally, tests of a
> broker-centric model. Since AMQP 1.0 allows for messaging models that
> go beyond the simple broker-based approach, we need a system test bed
> that can do the same. This would include support for testing
> peer-to-peer patterns, as well as testing distributed messaging
> systems yet to be defined.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
