Re: LoanBroker ESB test failing...

[ARGCRP-CARLSON, TRAVIS]

Ross,
I actually found 3 problems with the LoanBroker-ESB:

1. The OpenEJB config was wrong for the test case (I had just
copy/pasted it from the live config)

2. There was some code disabled in org.mule.impl.MuleSession which was
causing a regression in the LoanBroker (the
"CreditProfileXmlToCreditProfile" transformer was not getting applied)

3. There is a race condition which causes the unit test to _sometimes_
fail.

#1 and #2 were fixed outright.

As a workaround for #3, I added a minimal log4j.properties to the
loanbroker-esb and this makes the test pass, at least in my environment.

For a definite solution, I guess I'll have to finish reading the JCIP
book. :-(

Travis


-----Original Message-----
From: "Andrew Perepelytsya" <aperepel@...>
Sent: Mon, September 4, 2006 22:31
Subject: Re: LoanBroker ESB test failing...

I think this is a problem with m2 and surefire, which results in EJB not
deployed in the container under /local/CreditAgency.

At the same time it doesn't fail if run directly by Mule. Though I
didn't do more thorough testing to confirm all paths. I was thinking of
excluding the test in the short run until we resolve the issue (it could
be just a classloader policy switch for the test run).

Andrew

On 9/4/06, Ross Mason <ross@...> wrote:

>
> Hi,
>
> org.mule.samples.loanbroker.esb.LoanBrokerESBTestCase is failing, is
> this supposed to work or is it my environment? Cheers,
>
> Ross Mason
> MuleSource
>
> Malta Tel:       [phone]
> UK Tel:           [phone]
> US Tel:           [phone]
> Skype:            rossjmason

Esta comunicacion es confidencial y puede contener informacion cuya divulgacion este restringida por la ley o en virtud de obligaciones de confidencialidad asumidas por acuerdos escritos. Si usted no es su destinatario, por favor advierta que cualquier divulgacion, distribucion o copia de esta comunicacion le esta estrictamente prohibida. Si usted recibio este mail por error, agradeceremos tenga a bien informar esa circunstancia al remitente mediante comunicacion a la direccion de e-mail o al numero telefonico : (5411) 5170-0000, y le solicitamos asimismo que por favor proceda a borrarlo de su computadora. Por favor no copie ni use la informacion contenida en este mail para ningun proposito y no divulgue su contenido a ninguna otra persona.


This communication is confidential and may contain information that is exempt from disclosure by law or pursuant to confidentiality obligations assumed by written agreement. If you are not the intended recipient, please note that any dissemination, distribution, or copying of this communication is strictly prohibited. If you receive this e-mail in error, please notify the sender immediately at the electronic mail address or phone number : (5411) 5170-0000  and delete the information from your computer. Please do not copy or use it for any purpose nor disclose its contents to any other person.

 


---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Holger Hoffstätte-2]

ARGCRP-CARLSON, TRAVIS wrote:
> 3. There is a race condition which causes the unit test to _sometimes_
> fail.
>
> #1 and #2 were fixed outright.
>
> As a workaround for #3, I added a minimal log4j.properties to the
> loanbroker-esb and this makes the test pass, at least in my environment.

I assume you know this but that's not a workaround since it "may" simply
fail differently on different machines, so we might as well make it
official and keep it as reminder. Steph's greenmail extensions worked
great as well until I removed all logging..

How does this race manifest itself? I suspect that it is in fact not a
race in the traditional sense but simply yet another symptom of multiple
threads using the same receiver/dispatcher at the same time, which is just
a consequence of the way they are currently managed; see
http://jira.symphonysoft.com/browse/MULE-966 and
AbstractConnector.getDispatcher(UMOImmutableEndpoint) and similarly for
getReceiver(UMOComponent, UMOEndpoint). A simple "fix" would be to have a
KeyedObjectPool that manages things by endpoint key and only hands out a
new dispatcher/receiver when the old one has been returned. I do not know
(suspect) if this is a good idea since it means that only one request or
dispatch for a given connector's endpoint can run at the same time. One
other alternative approach would be to keep the currently used
ConcurrentMap + synchronized retrieval on endpoint (which is an
appropriate design, scales nicely and has minimal overhead) and simply put
a pool into the map, so that each endpoint key maps to several
receivers/dispatchers "standing in line".
The existing Dispatcher/Receiver factory could be wrapped as PoolFactory
which would take care of lifecycle control like
handout/return/creation/cleanup.

Unfortunately the current commons-pool StackedObjectPool implementation is
less than efficient in many ways, but that's a topic for another day..

> For a definite solution, I guess I'll have to finish reading the JCIP
> book. :-(

Do that, and have a cup of tea:
http://www.rider.edu/~suler/zenstory/teacombat.html

:-)
Holger

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[ARGCRP-CARLSON, TRAVIS]

> How does this race manifest itself?

It fails on the following line:

    public void testSingleLoanRequest() throws Exception {
        MuleClient client = new MuleClient();
        Customer c = new Customer("Ross Mason", 1234);
        CustomerQuoteRequest request = new CustomerQuoteRequest(c,
100000, 48);
        UMOMessage result = client.send("vm://loan.broker.requests",
request, null);
        assertNotNull(result);
        assertFalse(result.getPayload() instanceof NullPayload);
>>>>>>> assertTrue(result.getPayload() instanceof LoanQuote);
        LoanQuote quote = (LoanQuote)result.getPayload();
        assertTrue(quote.getInterestRate() > 0);
    }

Investigating further, I found that the sporadic failure is due to a
LoanQuoteRequest being returned instead of a LoanQuote.  I added a
PayloadTypeFilter to the config files and am no longer able to reproduce
the failure.  

By studying the config, I can't figure out why a LoanQuoteRequest would
get placed in the "LoanQuotes" queue (jms://esb.loan.quotes), but the
filter is harmless at any rate.

Let me know if anyone has any more insight into this.

Travis


Esta comunicacion es confidencial y puede contener informacion cuya divulgacion este restringida por la ley o en virtud de obligaciones de confidencialidad asumidas por acuerdos escritos. Si usted no es su destinatario, por favor advierta que cualquier divulgacion, distribucion o copia de esta comunicacion le esta estrictamente prohibida. Si usted recibio este mail por error, agradeceremos tenga a bien informar esa circunstancia al remitente mediante comunicacion a la direccion de e-mail o al numero telefonico : (5411) 5170-0000, y le solicitamos asimismo que por favor proceda a borrarlo de su computadora. Por favor no copie ni use la informacion contenida en este mail para ningun proposito y no divulgue su contenido a ninguna otra persona.


This communication is confidential and may contain information that is exempt from disclosure by law or pursuant to confidentiality obligations assumed by written agreement. If you are not the intended recipient, please note that any dissemination, distribution, or copying of this communication is strictly prohibited. If you receive this e-mail in error, please notify the sender immediately at the electronic mail address or phone number : (5411) 5170-0000  and delete the information from your computer. Please do not copy or use it for any purpose nor disclose its contents to any other person.

 


---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email