Removal of InVM support [was: Ideas to rationalise the Java test profiles]

[Robbie Gemmell <ro...@gmail.com>]

In the interests of full disclosure I think its worth drawing more
attention to one of the consequences of the work Keith and I are
undertaking, which is the removal of InVM support from the Java
broker/client.

The work we are doing was originally intended as a base point to add
support for InVM using the 0-10 protocol in order to significantly
speed up testing of that code path, as the InVM support has always
been hardcoded to use 0-8, and the 30-40min test runs for 0-10 are a
productivity killer. InVM support is implemented in the broker/client
via a feature of Mina, and it has become clear that the threading
model used by the 0-10 client implementation really isn't compatible
with the model used by Mina and would lead to deadlocks in real world
use (which I believe is one of several reasons it didn't use Mina
already). As such, it doesn't seem worth pursuing since it would at
best be useful only for testing, but what is the point of testing a
system in a way that differs from how anyone will use it?

That follows on to another point: the current InVM support is a
considerable hack into the broker and the client to a lesser extent,
and is done in a way really only intended for systesting. The Mina
code path used during these tests is quite different than the TCP path
used during regular use, and so again it is actually testing the
system in a non representative fashion. We have also seen evidence
over the years to suggest it isn't entirely safe to use either, and we
carry quite a lot of forked Mina code to make it work even to the
extent that it does now. In updating the IO layer to clean it up from
the horrible tangle it currently is, we would have to do work to bring
the existing InVM support with us, and based on the previous comments
I don't believe this is worthwhile. Removing it now strikes me as the
most appropriate course of action, and would go another step towards
the eventual removal of our current hard dependency on Mina for much
of the Java code base.

Instead of InVM, what we have done is enable the ability to easily run
the client and broker in the same JVM whilst using TCP, which nets us
the test time reduction we were originally looking for (due to lack of
starting the JVM hundreds of times), whilst also testing the exact
code paths used when running a client and standalone broker (which
will continue to be tested, but mostly only via CI and not by
developers due to the extended time involved).

We could possibly look towards restoring functionality later to avoid
use of TCP, but it seems to me that for now the best way to proceed is
as outlined above.

Thoughts?

On 4 July 2011 11:44, Keith Wall <ke...@gmail.com> wrote:
> Robbie and I are presently working on QPID-2811 and QPID-2815.  These Jiras
> will rationalise the transport mechanism in Qpid and to allow client/broker
> to be tested together within the same JVM regardless of transport.
>
> It seems to me that now is a good time to review the test-profiles.  I see
> the following problems:
>
> 1) 'default' profile being 0-8 makes little sense as most of the project's
> development focus is on 0-10, and with the removal of the old .NET client,
> we have no client that defaults to 0-8.
> 2) The time taken to run some test profiles is excessive and this is a
> disincentive to developer good practice.  For instance, running java-0.10 on
> my machine takes 30mins.  This is harming productivity.
>
> Current profiles:
>
> default.testprofile  - tests 0-8 using in-VM, broker/client share JVM,
> Memory Message Store
> java.testprofile - tests 0-9-1, using tcp, separate JVMs, Memory Message
> Store
> java-derby.testprofile - tests 0-9-1, using tcp, separate JVMs, Derby
> Message Store
>
> java.0.10.testprofile   - tests 0-10, using tcp, separate JVMs,, Memory
> Message Store
> java-derby.0.10.testprofile -- tests 0-10, using tcp, separate JVMs, Derby
> Message Store
>
> My proposal:
>
> Four profiles intended for regular developer use.  These profiles will
> exploit the feature for client/broker to share the same VM.  This saves the
> overhead of each testcase spawning a new broker as a separate process, and
> brings the length of time to run the profile down considerably, assisting
> developer productivity.
>
> (mms=memory message store, dby = Apache Derby)
>
> java-mms.0-10
> java-dby.0-10
>
> java-mms.0-9-1
> java-dby.0-9-1
>
> Running client/broker in separate JVMs remains valuable, but is probably not
> something most developers will want to do most of the time (because of the
> time overhead).    The intention would be we'd schedule these to run on CI
> (using Jenkin's matrix feature) and let Jenkins do the heavy lifting.
>
> java-mms-spawn.0-10
> java-dby-spawn.0-10
>
> java-mms-spawn.0-9-1
> java-dby-spawn.0-9-1
>
> The idea of the default testprofile would disappear and it would become an
> error to run -Dprofile=default.   If the developer omits -Dprofile from the
> Ant command line, the system will run java-mms.0-10, which I think will be
> useful fallback to most developers.
>
> I think we also need a "Java Test Howto" page on the website, explaining the
> purposes behind the profiles, the differences between system and non-system
> tests and giving advice on appropriate use of both.
>
> Any thoughts?
>
> Keith.
>

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org