[CAMEL-2935] Broken failure reporting via DefaultProucerTemplate.asyncCallback and Synchronization.onFailure

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 2.3.0
• Fix Version/s: 2.4.0
• Component/s: camel-core
• Assignee: Claus Ibsen
• Reporter: Martin Krasser
• Created: 10/Jul/10 10:01
• Updated: 24/Apr/11 09:57
• Resolved: 10/Jul/10 20:56

Description

The recent change in ProducerCache.send

ProducerCache.java

    public void send(Endpoint endpoint, Exchange exchange) {
        try {
            sendExchange(endpoint, null, null, exchange);
            // RECENT CHANGE HERE:
            // ensure that CamelExecutionException is always thrown
            if (exchange.getException() != null) {
                exchange.setException(wrapCamelExecutionException(exchange, exchange.getException()));
            }
        } catch (Exception e) {
            throw wrapCamelExecutionException(exchange, e);
        }
    }

that throws a CamelExecutionException if exchange.getException is not null, makes it impossible for DefaultProducerTemplate.asyncCallback to report failures (other than fault messages) asynchronously via Synchronization.onFailure

DefaultProducerTemplate.java

    public Future<Exchange> asyncCallback(final Endpoint endpoint, final Exchange exchange, final Synchronization onCompletion) {
        Callable<Exchange> task = new Callable<Exchange>() {
            public Exchange call() throws Exception {

                // FIXME: exception is thrown in Camel 2.4 where a normal return with answer.getException != null was done in Camel 2.3
                Exchange answer = send(endpoint, exchange);

                if (answer.isFailed()) {
                    onCompletion.onFailure(answer);
                } else {
                    // ...
                }
                return answer;
            }
        };
        // ...
    }

This was working in Camel 2.3 (but unfortunately there wasn't any test case for it). I attached a patch for DefaultProducerTemplateAsyncTest that demonstrates the problem. I didn't commit a fix yet because I'm unsure at the moment about the best way to fix that. Of course I tried a naive fix in the DefaultProducerTemplate.asyncCallback methods which causes the test (in the patch) to pass but I'd like to hear other opinions before I continue.