Return-Path: X-Original-To: apmail-camel-users-archive@www.apache.org Delivered-To: apmail-camel-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 075247E1C for ; Tue, 4 Oct 2011 15:01:02 +0000 (UTC) Received: (qmail 82282 invoked by uid 500); 4 Oct 2011 15:01:01 -0000 Delivered-To: apmail-camel-users-archive@camel.apache.org Received: (qmail 82153 invoked by uid 500); 4 Oct 2011 15:01:01 -0000 Mailing-List: contact users-help@camel.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@camel.apache.org Delivered-To: mailing list users@camel.apache.org Received: (qmail 82145 invoked by uid 99); 4 Oct 2011 15:01:01 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 04 Oct 2011 15:01:01 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [194.35.219.98] (HELO gwstu.uhi.ac.uk) (194.35.219.98) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 04 Oct 2011 15:00:54 +0000 Received: from sgarbh.smo.uhi.ac.uk ([194.35.194.47]) by gwstu.uhi.ac.uk with ESMTP; Tue, 04 Oct 2011 16:00:26 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) Subject: Re: Messages being lost from route From: Alistair Young In-Reply-To: Date: Tue, 4 Oct 2011 16:00:22 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <54EBF0F7-DF0B-4F35-A8DF-492A4EC3F3D5@uhi.ac.uk> References: <9AD77318-DEAD-47EE-9DF7-24FFA1880F55@uhi.ac.uk> <4E830031.8000604@gmx.de>

<604DFC8A-1B55-4AEC-ABFE-EC7A83504BC4@uhi.ac.uk> <798A4122-3646-466B-BA2F-4C820482FF42@uhi.ac.uk> <40B98271-4B20-48D0-A802-9B84B266F2F5@uhi.ac.uk> <50D55850-93E2-4C56-A49D-E9DE65603E89@uhi.ac.uk> <9E59767C-DF3D-44D8-8DE6-B80885AC05C2@uhi.ac.uk> <5BCF4F1E-2C31-46AF-8CD6-AD931E8AB2D3@uhi.ac.uk> <9948B430-D561-4D0E-8BC1-C569F5D84578@uhi.ac.uk> <4B784524-DFC0-44EB -A53F-62CEA113DE8B@uhi.ac.uk> <44BCDEA3-F0D5-42DF-B88D-30FBBF7BB308@uhi.ac.uk>

<53666AD0-36D3-43E9-8019-DCA51C4653F7@uhi.ac.uk> To: users@camel.apache.org X-Mailer: Apple Mail (2.1084) X-Virus-Checked: Checked by ClamAV on apache.org I think camel + tomcat is a non starter. The same config works perfectly = in activemq 5.5.0 standalone with camel. Used embedded in a webapp in = tomcat 6, only the first message makes it through the route. The rest = vanish. Alistair --=20 mov eax,1 mov ebx,0 int 80h On 4 Oct 2011, at 08:43, Alistair Young wrote: > why would adding this: >=20 > >=20 > to this: >=20 > org.apache.activemq.camel.component.ActiveMQComponent >=20 > cause the broker to stop working? There are no transacted routes. The = faster the messages come in, the more disappear. I have a very simple = config that is guaranteed to lose 99/100 messages if the broker is = transacted. >=20 > Is there anything special the client has to do? Surely not though, as = there are no transacted routes. >=20 > Alistair >=20 > --=20 > mov eax,1 > mov ebx,0 > int 80h >=20 >=20 >=20 >=20 > On 2 Oct 2011, at 09:43, Alistair Young wrote: >=20 >> eventually found the problem. >>=20 >> if transactions are enabled nothing works. Only the first message = gets through the route, the rest disappear. The problems start by adding = transacted and transactionManager to the ActiveMQComponent as per: >>=20 >> http://camel.apache.org/transactional-client.html >>=20 >> so I'm not sure how to go about fixing it. Would you have any = pointers please? >>=20 >> >> >> = >> >>=20 >> >> >> >>=20 >> >> >> >>=20 >> >> >> >> >> >>=20 >> thanks, >>=20 >> Alistair >>=20 >> -------------- >> mov eax,1 >> mov ebx,0 >> int 80 >>=20 >> On 30 Sep 2011, at 13:35, Alistair Young wrote: >>=20 >>> thanks Tim, that would be very helpful of you. I was about to dive = into the camel source to see why the route wouldn't accept anything but = if you have time to do a small test project I would be very grateful. >>>=20 >>> I'm running camel 2.8.1, activemq 5.5.0, spring 3.0.5 under tomcat. = I've attached my pom.xml and camel-config.xml. mvn clean install then = deploy to tomcat. >>>=20 >>> many thanks, >>>=20 >>> Alistair >>>=20 >>> --=20 >>> mov eax,1 >>> mov ebx,0 >>> int 80h >>> >>> >>>=20 >>>=20 >>> On 30 Sep 2011, at 13:23, Tim wrote: >>>=20 >>>> Alistair. I just tried the same with an embedded activemq instance = and it >>>> works great. >>>> Maybe this has to do with broker settings? I can setup a tiny test = project >>>> for you if you want to try that? >>>>=20 >>>> On Fri, Sep 30, 2011 at 11:27 AM, Alistair Young >>>> wrote: >>>>=20 >>>>> I can now reproduce this every time. Sending 100 messages in very = quick >>>>> succession to a camel route. JMX: >>>>>=20 >>>>> >>>>> >>>>> >>>>> >>>>>=20 >>>>> EnqueueCount =3D 100 >>>>> DispatchCount =3D 100 >>>>> InFlightCount =3D 100 >>>>> DequeueCount =3D 1 >>>>>=20 >>>>> only 1 message ever gets through the route. That's 99 percent = message loss, >>>>> every time. This happens on two servers with the same config. >>>>>=20 >>>>> This happens with the producer on the same machine as the broker = as well as >>>>> a remote broker. >>>>>=20 >>>>> Is there anything I should be looking at to see where the other 99 = messages >>>>> are? JMX says they're in flight but all dead letter queues are = empty and >>>>> there are no errors anywhere. >>>>>=20 >>>>> Alistair >>>>>=20 >>>>> -- >>>>> mov eax,1 >>>>> mov ebx,0 >>>>> int 80h >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 30 Sep 2011, at 09:12, Alistair Young wrote: >>>>>=20 >>>>>> getting somewhere. >>>>>>=20 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>=20 >>>>>> - producer clock is 2mins ahead of broker clock, timestampplugin = enabled >>>>> on broker >>>>>> - no delay between messages at the producer =3D 62 out of 100 get = through >>>>> the route, consistently >>>>>> - 3sec delay at producer, around 88 - 97 get through. That's as = good as >>>>> it gets >>>>>> - 5sec delay at producer, 93 made it through the route >>>>>> - remove the route and send direct to topic in activemq, no = delay, no >>>>> message loss, consistently >>>>>>=20 >>>>>> so the messages are being lost in the route. No matter what the = delay in >>>>> sending messages, some are always lost and vanish. There are no = errors, >>>>> nothing in any dead letter queue. They simply vanish. They don't = even make >>>>> it as far as the . >>>>>>=20 >>>>>> sending from a ruby producer that blats them out far quicker than = the >>>>> java producer is even worse. Only 1 - 3 ever get through the = route. Removing >>>>> the route and sending to the activemq topic instead, all messages = get >>>>> through no matter how fast they come. >>>>>>=20 >>>>>> Alistair >>>>>>=20 >>>>>> -- >>>>>> mov eax,1 >>>>>> mov ebx,0 >>>>>> int 80h >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On 29 Sep 2011, at 18:10, Alistair Young wrote: >>>>>>=20 >>>>>>> no connection pool. What was disturbing was the first message = sent to >>>>> the broker after a restart and clean out of the data dir, = disappeared. >>>>> There's a similar route on the broker that works fine. The only = difference >>>>> is the producer for the wonky route is on windows and is up to = 1min ahead of >>>>> the broker's clock. Would have thought the timestamplugin would = take care of >>>>> that though. Can see it changing the timestamp in the logs. >>>>>>>=20 >>>>>>> Alistair >>>>>>>=20 >>>>>>> -------------- >>>>>>> mov eax,1 >>>>>>> mov ebx,0 >>>>>>> int 80 >>>>>>>=20 >>>>>>> On 29 Sep 2011, at 17:31, Tim wrote: >>>>>>>=20 >>>>>>>> Well with only 17 you definitely aren't hitting any prefetch = limits or >>>>>>>> anything like that. >>>>>>>> Are you using a connection pool? >>>>>>>>=20 >>>>>>>> On Thu, Sep 29, 2011 at 5:05 PM, Alistair Young < >>>>> alistair.young@uhi.ac.uk>wrote: >>>>>>>>=20 >>>>>>>>> I think this way madness lies. >>>>>>>>>=20 >>>>>>>>> 17 sent to topicA, dispatchCount =3D 15, dequeueCount =3D 12 >>>>>>>>> topicB enqueueCount =3D 12 >>>>>>>>>=20 >>>>>>>>> so 17 came in, 12 made it through, of the 5 that went missing = it >>>>> claims to >>>>>>>>> have sent 3 to topicB but they never arrived and the last 2 = just >>>>> simply >>>>>>>>> vanished completely. >>>>>>>>>=20 >>>>>>>>> What on earth? >>>>>>>>>=20 >>>>>>>>> Alistair >>>>>>>>>=20 >>>>>>>>> -------------- >>>>>>>>> mov eax,1 >>>>>>>>> mov ebx,0 >>>>>>>>> int 80 >>>>>>>>>=20 >>>>>>>>> On 29 Sep 2011, at 15:41, Alistair Young wrote: >>>>>>>>>=20 >>>>>>>>>> nup - cleaned out the data dir and restarted the broker. = First >>>>> message in >>>>>>>>> vanished. Wasn't persisted. So something is fundamentally = broken. >>>>>>>>>>=20 >>>>>>>>>> topicA inflightCount =3D dispatchCount =3D enqueueCount =3D 1 >>>>>>>>>> topicB is completely empty >>>>>>>>>>=20 >>>>>>>>>> so the message wasn't persisted, wasn't processed, wasn't = routed and >>>>> just >>>>>>>>> vanished from the broker. >>>>>>>>>>=20 >>>>>>>>>> Alistair >>>>>>>>>>=20 >>>>>>>>>> -------------- >>>>>>>>>> mov eax,1 >>>>>>>>>> mov ebx,0 >>>>>>>>>> int 80 >>>>>>>>>>=20 >>>>>>>>>> On 29 Sep 2011, at 15:13, Alistair Young wrote: >>>>>>>>>>=20 >>>>>>>>>>> route goes from topicA -> topicB, transacted. >>>>>>>>>>> topicA inflightCount =3D 96 and increases on each batch of = incoming >>>>>>>>> messages >>>>>>>>>>> topicB dispatchCount =3D enqueueCount >>>>>>>>>>>=20 >>>>>>>>>>> wondering if the missing messages are connected to topicA >>>>> inflightCount. >>>>>>>>> I noticed there are two consumers for topicB. The main = consumer gets >>>>> its >>>>>>>>> messages fine. Wonder if the second consumer is a durable = topic >>>>> consumer and >>>>>>>>> therefore activemq is persisting its messages but it hasn't = connected >>>>> in a >>>>>>>>> very long time. Would that cause the topic to get too big? = i.e. >>>>> messages go >>>>>>>>> into the topic until the limit is reached. Main consumer pulls >>>>> messages off >>>>>>>>> and messages are able to go onto topicB again. Before consumer = pulls >>>>> and >>>>>>>>> after limit reached, messages can't get from topicA -> topicB, = hence >>>>> the >>>>>>>>> topicA inflightCount not zero? >>>>>>>>>>>=20 >>>>>>>>>>> Alistair >>>>>>>>>>>=20 >>>>>>>>>>> -------------- >>>>>>>>>>> mov eax,1 >>>>>>>>>>> mov ebx,0 >>>>>>>>>>> int 80 >>>>>>>>>>>=20 >>>>>>>>>>> On 29 Sep 2011, at 12:17, Tim wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> Sorry you might have tried this since I haven't been = following this >>>>>>>>> thread. >>>>>>>>>>>> But can you check your jmx console. >>>>>>>>>>>> In particular check 2 things.. the route to see if the = number of >>>>>>>>> exchanges >>>>>>>>>>>> match what you think and how if any exchanges failed. >>>>>>>>>>>> Also check the JMX console on activemq for the queue or = topic in >>>>>>>>> question >>>>>>>>>>>> and see how many were enqueued vs dispatched. >>>>>>>>>>>> Check your deadletter queue from there too >>>>>>>>>>>>=20 >>>>>>>>>>>> On Thu, Sep 29, 2011 at 12:52 PM, Alistair Young >>>>>>>>>>>> wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>>> dunno - nothing works. Random messages are just vanishing = once >>>>> they >>>>>>>>> reach >>>>>>>>>>>>> the broker. No trace, no logs, no dead letter queue. Just >>>>> vanishing. >>>>>>>>> I've >>>>>>>>>>>>> removed and but it doesn't help. = The >>>>> producer >>>>>>>>> is a >>>>>>>>>>>>> few secs behind the broker: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> sent : 11:25:26 >>>>>>>>>>>>> arrived : 11:24:57 >>>>>>>>>>>>> timstamp on message : 1317291897071 =3D 29 Sep 2011 = 10:24:57 GMT, >>>>>>>>> presumably >>>>>>>>>>>>> the timestampplugin doing this >>>>>>>>>>>>> message vanishes >>>>>>>>>>>>>=20 >>>>>>>>>>>>> but all messages display this clock behaviour and not all = vanish. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Alistair >>>>>>>>>>>>>=20 >>>>>>>>>>>>> -------------- >>>>>>>>>>>>> mov eax,1 >>>>>>>>>>>>> mov ebx,0 >>>>>>>>>>>>> int 80 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On 29 Sep 2011, at 10:24, Alistair Young wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> just saw your info about transacted being before from - = will >>>>> change >>>>>>>>> that >>>>>>>>>>>>> and monitor again. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> thanks, >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Alistair >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>> mov eax,1 >>>>>>>>>>>>>> mov ebx,0 >>>>>>>>>>>>>> int 80 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> On 29 Sep 2011, at 10:18, Alistair Young wrote: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> just noticed a batch of identical 5 messages, three were = missing >>>>> and >>>>>>>>>>>>> another single message vanished. tracer logged nothing. No = errors, >>>>>>>>> dead >>>>>>>>>>>>> letter queue empty. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> One thing that happens is another machine polls the = stats topic >>>>> in >>>>>>>>>>>>> activemq every 2mins. Would that cause a problem? It asks = for >>>>> stats on >>>>>>>>> the >>>>>>>>>>>>> matrix topic, which is part of the transacted route. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> 29 September 2011 10:05:07 - Adding destination : >>>>>>>>>>>>> Topic:ActiveMQ.Advisory.Connection >>>>>>>>>>>>>>> 29 September 2011 10:05:07 - Creating new transaction = with name >>>>>>>>> [null]: >>>>>>>>>>>>> PROPAGATION_REQUIRED,ISOLATION_DEFAULT >>>>>>>>>>>>>>> 29 September 2011 10:05:07 - Stopping connection: >>>>>>>>>>>>> vm://matrixBroker#285916 >>>>>>>>>>>>>>> 29 September 2011 10:05:07 - Stopped transport: >>>>>>>>> vm://matrixBroker#285916 >>>>>>>>>>>>>>> 29 September 2011 10:05:07 - Connection Stopped: >>>>>>>>>>>>> vm://matrixBroker#285916 >>>>>>>>>>>>>>> 29 September 2011 10:05:07 - Setting up new connection = id: >>>>>>>>>>>>> ID:prodprovisioning-matrix-41707-1317215126074-4:142961, = address: >>>>>>>>>>>>> vm://matrixBroker#285920 >>>>>>>>>>>>>>> 29 September 2011 10:05:07 - Adding Connection : = ConnectionInfo >>>>>>>>>>>>> {commandId =3D 1, responseRequired =3D true, connectionId = =3D >>>>>>>>>>>>> ID:prodprovisioning-matrix-41707-1317215126074-4:142961, = clientId >>>>> =3D >>>>>>>>>>>>> ID:prodprovisioning-matrix-41707-1317215126074-5:142961, = userName >>>>> =3D >>>>>>>>> null, >>>>>>>>>>>>> password =3D *****, brokerPath =3D null, = brokerMasterConnector =3D >>>>> false, >>>>>>>>>>>>> manageable =3D true, clientMaster =3D true, faultTolerant = =3D false} >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Alistair >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>>> mov eax,1 >>>>>>>>>>>>>>> mov ebx,0 >>>>>>>>>>>>>>> int 80 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> On 29 Sep 2011, at 09:36, Alistair Young wrote: >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> Should be after >>>>>>>>>>>>>>>> it is after from - do you mean it should be before? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> thanks for the dead letter tips, will apply them. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Alistair >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>>>> mov eax,1 >>>>>>>>>>>>>>>> mov ebx,0 >>>>>>>>>>>>>>>> int 80 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> On 29 Sep 2011, at 09:20, Claus Ibsen wrote: >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> Hi >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> Should be after >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> On Thu, Sep 29, 2011 at 10:09 AM, Alistair Young >>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>> Do you use message expiry? >>>>>>>>>>>>>>>>>> no >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> timestamp plugin >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> using that >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> activemq 5.5.0 >>>>>>>>>>>>>>>>>> camel 2.8.0 >>>>>>>>>>>>>>>>>> spring 3.0.5 >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> noticed sl4j errors on startup, fixed that and now = the tracer >>>>> is >>>>>>>>>>>>> logging so hopefully I can see any errors. >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> >>>>>>>> errorHandlerRef=3D"matrixDeadLetterErrorHandler"> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>> class=3D"org.apache.activemq.ActiveMQConnectionFactory" >>>>>>>>>>>>> depends-on=3D"matrixBrokerID"> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>> value=3D"vm://matrixBroker?create=3Dfalse"/> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>> = class=3D"org.springframework.jms.connection.JmsTransactionManager"> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>> ref=3D"jmsConnectionFactory"/> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>> = class=3D"org.apache.activemq.camel.component.ActiveMQComponent"> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>> ref=3D"jmsConnectionFactory"/> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>> ref=3D"jmsTransactionManager"/> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>> class=3D"org.apache.camel.builder.DeadLetterChannelBuilder">= >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>> ref=3D"matrixRedeliveryPolicyConfig"/> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>> class=3D"org.apache.camel.processor.RedeliveryPolicy"> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> thanks, >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> Alistair >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>>>>>> mov eax,1 >>>>>>>>>>>>>>>>>> mov ebx,0 >>>>>>>>>>>>>>>>>> int 80 >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> On 29 Sep 2011, at 08:53, Claus Ibsen wrote: >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> Hi >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> Do you use message expiry? >>>>>>>>>>>>>>>>>>> Make sure clocks between server/clients is synced as = much as >>>>>>>>>>>>> possible. >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> There is a timestamp plugin >>>>>>>>>>>>>>>>>>> http://activemq.apache.org/timestampplugin.html >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> And do you use queue or topic. >>>>>>>>>>>>>>>>>>> What version of AMQ and Camel are you using? >>>>>>>>>>>>>>>>>>> And how have you configured the AMQ broker, and the = Camel >>>>>>>>> context? >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> On Thu, Sep 29, 2011 at 7:21 AM, Taariq Levack < >>>>>>>>> taariql@gmail.com> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>> Hi >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> Where the logs go, if it's logged at all, still = depends on >>>>> your >>>>>>>>>>>>> logger and >>>>>>>>>>>>>>>>>>>> how you configured it. >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> Here are links to how to enable logging[1] and = camel >>>>> logging >>>>>>>>> FAQ[2] >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> [1] >>>>> http://camel.apache.org/how-do-i-enable-debug-logging.html >>>>>>>>>>>>>>>>>>>> [2]http://camel.apache.org/logging-questions.html >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> Taariq >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> On Wed, Sep 28, 2011 at 1:23 PM, Alistair Young < >>>>>>>>>>>>> alistair.young@uhi.ac.uk>wrote: >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> which is the best trace method to use? = trace=3D"true", or >>>>>>>>>>>>> camelTracer and >>>>>>>>>>>>>>>>>>>>> traceFormatter beans? and where does the log end = up? I've >>>>>>>>> tried >>>>>>>>>>>>> them all but >>>>>>>>>>>>>>>>>>>>> no log appears. >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> Alistair >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>> mov eax,1 >>>>>>>>>>>>>>>>>>>>> mov ebx,0 >>>>>>>>>>>>>>>>>>>>> int 80h >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> On 28 Sep 2011, at 12:08, Marco Westermann wrote: >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> I suggest enable tracing to see exactly what = happens in >>>>> your >>>>>>>>>>>>> route. >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> regards, Marco >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> Am 28.09.2011 13:01, schrieb Alistair Young: >>>>>>>>>>>>>>>>>>>>>>> I now have a dead letter channel which is empty = after >>>>> losing >>>>>>>>> 9 >>>>>>>>>>>>> out of 10 >>>>>>>>>>>>>>>>>>>>> messages. I also added a logging handler which = logged >>>>> nothing. >>>>>>>>>>>>> Verified the >>>>>>>>>>>>>>>>>>>>> messages arrived at the broker, then they just = vanished. >>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>> Alistair >>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>> Claus Ibsen >>>>>>>>>>>>>>>>>>> ----------------- >>>>>>>>>>>>>>>>>>> FuseSource >>>>>>>>>>>>>>>>>>> Email: cibsen@fusesource.com >>>>>>>>>>>>>>>>>>> Web: http://fusesource.com >>>>>>>>>>>>>>>>>>> Twitter: davsclaus, fusenews >>>>>>>>>>>>>>>>>>> Blog: http://davsclaus.blogspot.com/ >>>>>>>>>>>>>>>>>>> Author of Camel in Action: = http://www.manning.com/ibsen/ >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>> Claus Ibsen >>>>>>>>>>>>>>>>> ----------------- >>>>>>>>>>>>>>>>> FuseSource >>>>>>>>>>>>>>>>> Email: cibsen@fusesource.com >>>>>>>>>>>>>>>>> Web: http://fusesource.com >>>>>>>>>>>>>>>>> Twitter: davsclaus, fusenews >>>>>>>>>>>>>>>>> Blog: http://davsclaus.blogspot.com/ >>>>>>>>>>>>>>>>> Author of Camel in Action: = http://www.manning.com/ibsen/ >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>>=20 >>>=20 >>=20 >=20