Comments on: Guaranteed Delivery in Spring Integration

By: Mark Fisher

Mark Fisher — Wed, 02 Dec 2009 14:32:23 +0000

Wilfred,

I would be very interested to see the results of some crude performance tests between your Kaha-only channel, and Spring Integration’s new JMS-backed channel using ActiveMQ. That would be a great way to measure the “freaking amounts of cycles”

Whatever performance difference exists could be considered in the trade-off, but on the other side, there are additional benefits of the “full” ActiveMQ solution (queue management/monitoring via JMX, the ability to *share* a channel within a load-balancing/failover strategy, transactions with redelivery, etc).

Regards,
Mark

By: Wilfred springer

Wilfred springer — Mon, 30 Nov 2009 20:43:43 +0000

Basically cutting out abstractions and making things a little bit more understandable. Nobody likes the JMS APIs, but we still accept it in between everything we do. If I can do with less, then I’d prefer to do so.

Another argument is performance. It turns out that we loose a freaking amount of cycles nowadays with piles of pointless abstractions.

And then of course, I didn’t invent ActiveMQ. But to my defense I will say that I didn’t invent Kaha and I didn’t invent Spring Integration either. In fact, I didn’t invent anything at all, so this could never have been the not invented here syndrome manifesting itself.

By: Age Mooy

Age Mooy — Mon, 30 Nov 2009 09:57:55 +0000

Why would you not use a standardized API implemented by the same backend you’re talking to now ? Not invented here ?

By: Wilfred Springer

Wilfred Springer — Mon, 30 Nov 2009 09:39:17 +0000

I haven’t tried yet.

By: Erik Rozendaal

Erik Rozendaal — Mon, 30 Nov 2009 09:32:03 +0000

So how much faster is the KahaChannel compared to the JMS one?

By: Mark Fisher

Mark Fisher — Fri, 27 Nov 2009 19:20:01 +0000

Nice post! We should be able to support a custom “queue” strategy within Spring Integration such that namespace support would be available with something like a “ref” attribute or inner-bean defined within a queue element. On one hand, with the introduction of MessageStore in 2.0, we will have a persistence option (via a DataSource-backed implementation), but that does not provide queue characteristics inherently. On the other hand, we could simply delegate to any java.util.BlockingQueue reference, but that defines more methods than we really need.

As in your example, all that is really needed is something to support “addLast” and “removeFirst”, and *timeouts* for each if supported by the underlying implementation. These could be mapped directly to our channel’s send and receive calls or we could provide something like a BlockingQueueAdapter that does implement BlockingQueue but then delegates to such a strategy interface. In any case, my goal would be to not only support this with a single strategy hook but also to provide one or more persistent options out of the box within the 2.0 timeframe.

Regards,
Mark

By: jos

jos — Fri, 27 Nov 2009 10:57:41 +0000

JBI NMR is not systematically backed by a persistent message store : NMR is used to manage communication Exchanges between endpoints and support patterns (in-out, in-only, …) and sync or async communication, the exchange end state tells the initiator if it was successful or not.
NMR can be persistent (slow) or SEDA based (fast but not persistent). In this case safe endpoints must deal with persistency and retry (such as with JMS endpoint for instance) to manage exchange failures.
Regards