camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <>
Subject Re: Newbie: Mapping JMS Camel / Spring to POJO, ActiveMQ Queues
Date Tue, 20 Jan 2009 07:11:17 GMT
2009/1/20 Matvey <>:
> I need to configure Camel DSL / routes in such a way that on of my old
> classes gets objects from JMS queue and sends objects to another JMS queue.
> I can use Camel API to do that, but it seems like in such a case I almost do
> not use Camel:
> CamelContext context = new DefaultCamelContext();
>        context.addComponent("activemq",
> ActiveMQComponent.activeMQComponent("tcp://localhost:61616"));
>        context.start();
>        Endpoint endpoint =
> context.getEndpoint("activemq:test.queue?concurrentConsumers=2");
>        PollingConsumer consumer = endpoint.createPollingConsumer();
> It is still not clear for me how should I do that in a "Camel way", using
> Spring, annotations and mapping.

public class MyConsumer {

  public void myConsumeMethod(String payload) {... }


>  Also one more important question: we have 1000 messages in a queue, POJO
> class gets a message, as it mapped for this queue (analog of onMessage()
> method), I need some time to process this message (sure there are multiple
> threads), and sometimes I can not process this message immediately, so I
> have 2 options: 1. to wait (either with Thread.sleep() or waiting for an
> event) or 2. put this message back to queue. The question is - may I just
> wait (case 1) or it's necessary to throw an exception  and return this
> message back to queue?

You can just wait if you like. I guess it depends; are there other
messages you could be getting on with processing - or do you have to
wait for some external resource before processing any more messages?

If you can't process any messages at all; just wait. If you just can't
handle that message right now but its likely you can process others,
you could always send a copy of the message to the back of the queue
and consume the current message - though only do this if a small
subset of the messages cannot be processed. i.e. if no messages can be
processed you are far better just waiting rather than spinning your
system as fast as it'll go (consuming & sending messages non stop to
no avail :)


Open Source Integration

View raw message