Mailing-List: contact users-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@camel.apache.org
Received-SPF: pass (nike.apache.org: domain of christian.mueller@gmail.com
 designates 209.85.214.171 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAMqGX50W9iBhaTthS=mpFN83CuUXz4pHHtAiV-Ag=FM=k=NX4A@mail.gmail.com>
References: 
 <CAMqGX50W9iBhaTthS=mpFN83CuUXz4pHHtAiV-Ag=FM=k=NX4A@mail.gmail.com>
Date: Thu, 6 Jun 2013 22:58:43 +0200
Message-ID: 
 <CALvzYd9aOCrbGnRJPsUNTxXnx=H-0rMojdRpntvzFTCpj9rw=w@mail.gmail.com>
Subject: Re: Transactional test assertions timing issue
From: =?ISO-8859-1?Q?Christian_M=FCller?= <christian.mueller@gmail.com>
To: users@camel.apache.org
Content-Type: multipart/alternative; boundary=047d7b4724f469a8a004de8294c6

--047d7b4724f469a8a004de8294c6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

If you have to do it by yourself (as we have to do it some time), you could
do it in this way (template is an instance of Springs JDBCTemplate):

private void assertDatabaseCount(int count) throws InterruptedException {
    long timeout =3D System.currentTimeMillis() + 10000;

    while (timeout > System.currentTimeMillis() &&
template.queryForInt("SELECT COUNT(*) FROM FOO_TABLE") < count) {
        Thread.sleep(200);
    }

    assertEquals(count, statisticMock.size());
}

Best,

Christian M=FCller
-----------------

Software Integration Specialist

Apache Camel committer: https://camel.apache.org/team
V.P. Apache Camel: https://www.apache.org/foundation/
Apache Member: https://www.apache.org/foundation/members.html

https://www.linkedin.com/pub/christian-mueller/11/551/642


On Tue, Jun 4, 2013 at 5:31 PM, Alex Sherwin <alex.sherwin@gmail.com> wrote=
:

> When unit (integration) testing a transacted route, such as (pseudo):
>
> <route>
>   <from uri=3D"activemq:some queue"/>
>   <transacted/>
>   <camel:process ref=3D"someBeanProcessor"/>
> </route>
>
> Where "someBeanProcessor" does some DB work and participates in a JTA
> transaction with the JMS message on this route
>
> The problem is, what is a reliable way to apply an assertion on the work
> that "someBeanProcessor" has done in the DB?  I've tried both of the
> following:
>
> 1. Add <to: uri=3D"log:some.logger.success?level=3DDEBUG"/>, get a MockEn=
dpoint
> ref and use an expected message count of 1, and wait on
> mock.assertIsSatisified()
>
> 2. Use a NotifyBuilder on the route and use whenComplete(1), and wait on
> builder.matchesMockWaitTime()
>
> Both have the same result, where my test code is told about the success
> before the JTA transaction has finished comitting, so when the test threa=
d
> performs a SQL select, it is doing so too early since the JTA tx of the
> route hasn't actually completed.
>
> This scenario works OK if the end result is something like <to
> uri=3D"activemq:out queue"/> and I use a MockEndpoint on the JMS output U=
RI,
> which makes sense since it'd be waiting on the TX to commit here; but wha=
t
> about routes where this isn't an option?
>
> Do I just need to suck it up and use Thread.sleep(..) on the test thread?
>
> Thanks,
>
> --
> Alexander Sherwin
>

--047d7b4724f469a8a004de8294c6--