No consumers available on endpoint: Endpoint[direct:processMsg]
Hi,
I have a problem which occurs when I have a Route which looks like this:
// initiated from queue
from("jms:queue:SOURCE_QUEUE").
to("direct:processMsg");
// initiated from file
from("file://inbox).
to("direct:processMsg");
// Main flow
from("direct:processMsg")
.process("...")
.to("validtor:foo.xsd")
.to("jms:queue:DEST_QUEUE");
Everything works fine when everything is initiated/started, but if there
already is a message on the JMS-source when camel is started I get the
following error:
WARN DirectProducer - No consumers available on endpoint:
Endpoint[direct:processMsg] to process Exchange[JmsMessage:
Seems like my "Main Flow" (defined in the same
RouteBuilder.configure-method) isn't fully initiated/started when "initiated
from JMS" is already up and running (and starts to consume messages). Could
this be handled in some way, i.e. to not start to consume messages before
all Route's are fully started?
Right now I am using Spring to start my routes (inside a
META-INF/spring/camel-context.xml) and I'm using Camel 2.0-M1.
Best Regards,
Henric
Re: No consumers available on endpoint: Endpoint[direct:processMsg]
Thank you, this simple solution (of course) worked like a charm!
My DSL become a bit backwards, but guess I have to live with that :)
/Henric
On Mon, Apr 20, 2009 at 10:58 AM, Claus Ibsen wrote:
> Hi
>
> Can you not just reorder the routes? Camel should process them in the
> order they are defined.
>
>
> On Mon, Apr 20, 2009 at 10:50 AM, Henric Hedin wrote:
> > Hi,
> >
> > I have a problem which occurs when I have a Route which looks like this:
> >
> > // initiated from queue
> > from("jms:queue:SOURCE_QUEUE").
> > to("direct:processMsg");
> >
> > // initiated from file
> > from("file://inbox).
> > to("direct:processMsg");
> >
> >
> > // Main flow
> > from("direct:processMsg")
> > .process("...")
> > .to("validtor:foo.xsd")
> > .to("jms:queue:DEST_QUEUE");
> >
> >
> > Everything works fine when everything is initiated/started, but if there
> > already is a message on the JMS-source when camel is started I get the
> > following error:
> >
> > WARN DirectProducer - No consumers available on
> endpoint:
> > Endpoint[direct:processMsg] to process Exchange[JmsMessage:
> >
> > Seems like my "Main Flow" (defined in the same
> > RouteBuilder.configure-method) isn't fully initiated/started when
> "initiated
> > from JMS" is already up and running (and starts to consume messages).
> Could
> > this be handled in some way, i.e. to not start to consume messages before
> > all Route's are fully started?
> >
> > Right now I am using Spring to start my routes (inside a
> > META-INF/spring/camel-context.xml) and I'm using Camel 2.0-M1.
> >
> > Best Regards,
> > Henric
> >
>
>
>
> --
> Claus Ibsen
> Apache Camel Committer
>
> Open Source Integration: http://fusesource.com
> Blog: http://davsclaus.blogspot.com/
> Twitter: http://twitter.com/davsclaus
> Apache Camel Reference Card:
> http://refcardz.dzone.com/refcardz/enterprise-integration
>
Re: Resequencer pattern does not work with the StreamRequencer config
Hi Nawaz,
Some comments to your code:
- Technically you should be able to get the code working using
constant(Long.valueOf("1000")) but this doesn't resequence the message
because all will have the same sequence number
- How to customize the resequencer using sequence numbers other than
long (in Camel 1.x) is also described in
https://issues.apache.org/activemq/browse/CAMEL-1371. (The gapPredicate
extension still needs to be implemented, but providing a custom
comparator is already working).
Hope that helps,
Martin
Nawaz Ahmed schrieb:
Hi all,
I was going through the Resequencer camel component available in the
link: http://camel.apache.org/resequencer.html
On trying the resequencer camel component with the StreamResequencer
config with the code below:
from("jms:queue:nq1").
convertBodyTo(String.class).
resequencer(constant("1000")).stream(new
StreamResequencerConfig()).
convertBodyTo(String.class).
to("jms:queue:nq2")
I am getting the below Exception in the Console:
java.lang.ClassCastException: java.lang.String
at
org.apache.camel.processor.resequencer.DefaultExchangeComparator.getSequ
enceNumber(DefaultExchangeComparator.java:81)
at
org.apache.camel.processor.resequencer.DefaultExchangeComparator.compare
(DefaultExchangeComparator.java:75)
at
org.apache.camel.processor.resequencer.DefaultExchangeComparator.compare
(DefaultExchangeComparator.java:38)
at
org.apache.camel.processor.resequencer.ElementComparator.compare(Element
Comparator.java:63)
at
org.apache.camel.processor.resequencer.ElementComparator.compare(Element
Comparator.java:28)
at
org.apache.camel.processor.resequencer.Sequence.higher(Sequence.java:109
)
at
org.apache.camel.processor.resequencer.Sequence.successor(Sequence.java:
73)
at
org.apache.camel.processor.resequencer.ResequencerEngine.insert(Resequen
cerEngine.java:192)
at
org.apache.camel.processor.StreamResequencer.process(StreamResequencer.j
ava:167)
at
org.apache.camel.management.InstrumentationProcessor.process(Instrumenta
tionProcessor.java:80)
at
org.apache.camel.processor.DeadLetterChannel.process(DeadLetterChannel.j
ava:185)
at
org.apache.camel.processor.DeadLetterChannel.process(DeadLetterChannel.j
ava:132)
at org.apache.camel.processor.Pipeline.process(Pipeline.java:115)
at org.apache.camel.processor.Pipeline.process(Pipeline.java:89)
at
org.apache.camel.management.InstrumentationProcessor.process(Instrumenta
tionProcessor.java:68)
at
org.apache.camel.processor.UnitOfWorkProcessor.process(UnitOfWorkProcess
or.java:52)
at
org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.
java:41)
at
org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncP
rocessor.java:66)
at
org.apache.camel.component.jms.EndpointMessageListener.onMessage(Endpoin
tMessageListener.java:72)
at
org.springframework.jms.listener.AbstractMessageListenerContainer.doInvo
keListener(AbstractMessageListenerContainer.java:531)
at
org.springframework.jms.listener.AbstractMessageListenerContainer.invoke
Listener(AbstractMessageListenerContainer.java:466)
at
org.springframework.jms.listener.AbstractMessageListenerContainer.doExec
uteListener(AbstractMessageListenerContainer.java:435)
at
org.springframework.jms.listener.AbstractPollingMessageListenerContainer
.doReceiveAndExecute(AbstractPollingMessageListenerContainer.java:322)
at
org.springframework.jms.listener.AbstractPollingMessageListenerContainer
.receiveAndExecute(AbstractPollingMessageListenerContainer.java:260)
at
org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMe
ssageListenerInvoker.invokeListener(DefaultMessageListenerContainer.java
:944)
at
org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMe
ssageListenerInvoker.run(DefaultMessageListenerContainer.java:875)
at java.lang.Thread.run(Unknown Source)
Apr 20, 2009 12:12:51 PM org.apache.camel.processor.Logger log
SEVERE: java.lang.String
Is there any problem with the above code or Is it the bug in the
Resequencer Camel component?
Thanks and Regards,
Nawaz Ahmed
Re: thoughts on the method names for the requestBody and requestBodyAndHeader etc
On Mon, Apr 20, 2009 at 11:29 AM, Roman Kalukiewicz wrote: > OK Claus, I'm somehow convinced, but what would you say about > > sendInOnly() > sendInOut() Yeah and we can have a generic send for the remaining 5% use cases, where you can set the pattern and whatnot. > > This way there is no problem at all with understanding what it does > and the name is short and clear. Yeah and it also helps bringing the exchange pattern into the light. > > Another thing is those headers that I believe should be in overloaded > signatures and shouldn't be in method names. Yeah that avoid a bit of confusion as well. However the number of overloaded methods might explode based on the combo. But we could reduce it and let people use a processor to setup the exchange before its sent. This gives them 100% control. However that usually requires inlined anonym inner class. Yeah I like your suggestion Roman. Others any thoughts, yet again its now we have the time to mess with the API. > > Roman > > 2009/4/20 Claus Ibsen : >> On Sun, Apr 19, 2009 at 8:44 PM, Roman Kalukiewicz >> wrote: >>> Hello Claus, >>> >>> You asked for thoughts, so here they are ;) >> Great the more the better. This is now you have the chance to >> influence the API before 2.0 is settled. >> So please reply with any thoughts you have. >> The producertemplate is very useful so we want to provide a API that >> intuitive and you can use without being in doubt. >> >>> >>> What about totally different approach, that would be a pattern >>> parameter instead of a method name. Especially that those methods >>> differ only in pattern set on the exchange. >>> >>> In fact I believe the best approach would be to have sendMessage() >>> method that has pattern as a parameter and is overloaded with versions >>> for sending only body, only one header, and a map of headers. Why the >>> method name has to show what parameters already clarify? >> >> I see two/three issues with the combined method approach >> >> 1) >> The method must be delcared to return something. That is a drawback >> for InOnly methods where you can use void. >> This was confusing in 1.x as people would thing that are doing an >> InOut but the have selected a InOnly method but >> in the 1.x API it would still return something, and in some of the >> older 1.x releases it was the IN payload you sent. >> >> And with the void we get help from the compiler if the end users >> things he is doing and InOut and expects an output. >> >> >> 2) >> You have to specify the pattern using an enum and thus you need >> imports and the method parameters get long >> and/or you can use static imports to shorten it. But it all takes time >> to setup in the IDE and well ... it just feels >> like a drag in 95% if the uses cases where you either use InOnly or InOut. >> >> 3) >> We should also consider being similar to the other integration >> projects in this matter. >> >> Spring Integration uses 2 different method signatures. >> Mule as well AFAIR >> >> >> And now we are talking about this API. What about: >> >> 4) >> The API in ProducerTemplate have grown to large IMHO. So I also >> suggest to reduce it and use specialized methods for the 95% use >> cases. >> And the provide a few fallback methods that you can use for the other 5%. >> >> And we should consider not having copies with both String endpointUri >> and Endpoint as the object. >> You can always go from Endpoint -> endpointUri so we should consider >> removing some of the Endpoint variations. >> >> >> >> >> >> >> >>> >>> Romek >>> >>> 2009/4/19 Claus Ibsen : Hi Actually I think the naming convention should be: send = for in only sendWithHeader sendWithHeaders sendAndReceive = for in out sendAndReceiveWithHeader sendAndReceiveWithHeaders Its more intuitive than currently send = for in only request = for in out However what about the "body" method we can do it like sendAndReceiveBody sendAndReceiveBodyWithHeader sendAndReceiveBodyWithHeaders or sendBodyAndReceiveWihHeader sendBodyAndReceiveWithHeaders I prefer the former as its sending a body and receving a body. Any thoughts on this, as we still have time to for this API change before 2.0 is ready for release. However the clock is ticking!!! On Sat, Apr 4, 2009 at 9:20 AM, Claus Ibsen wrote: > On Sat, Apr 4, 2009 at 8:38 AM, Ryan Gardner wrote: >> The requestBody method makes sense (it requests a body) - but >> "requestBodyAndHeader" and "requestBodyAndHeaders" etc methods make less >> sense - because I'm only requesting one thing (the body). >> >> maybe "requestBodyWithHeader" makes more sense? for the >> "sendBodyAndHeader" >> methods, it makes sense because you are sending two things (the body and >> the >> header) >> >> although, perhaps I'm just going crazy? > No it
Re: thoughts on the method names for the requestBody and requestBodyAndHeader etc
OK Claus, I'm somehow convinced, but what would you say about sendInOnly() sendInOut() This way there is no problem at all with understanding what it does and the name is short and clear. Another thing is those headers that I believe should be in overloaded signatures and shouldn't be in method names. Roman 2009/4/20 Claus Ibsen : > On Sun, Apr 19, 2009 at 8:44 PM, Roman Kalukiewicz > wrote: >> Hello Claus, >> >> You asked for thoughts, so here they are ;) > Great the more the better. This is now you have the chance to > influence the API before 2.0 is settled. > So please reply with any thoughts you have. > The producertemplate is very useful so we want to provide a API that > intuitive and you can use without being in doubt. > >> >> What about totally different approach, that would be a pattern >> parameter instead of a method name. Especially that those methods >> differ only in pattern set on the exchange. >> >> In fact I believe the best approach would be to have sendMessage() >> method that has pattern as a parameter and is overloaded with versions >> for sending only body, only one header, and a map of headers. Why the >> method name has to show what parameters already clarify? > > I see two/three issues with the combined method approach > > 1) > The method must be delcared to return something. That is a drawback > for InOnly methods where you can use void. > This was confusing in 1.x as people would thing that are doing an > InOut but the have selected a InOnly method but > in the 1.x API it would still return something, and in some of the > older 1.x releases it was the IN payload you sent. > > And with the void we get help from the compiler if the end users > things he is doing and InOut and expects an output. > > > 2) > You have to specify the pattern using an enum and thus you need > imports and the method parameters get long > and/or you can use static imports to shorten it. But it all takes time > to setup in the IDE and well ... it just feels > like a drag in 95% if the uses cases where you either use InOnly or InOut. > > 3) > We should also consider being similar to the other integration > projects in this matter. > > Spring Integration uses 2 different method signatures. > Mule as well AFAIR > > > And now we are talking about this API. What about: > > 4) > The API in ProducerTemplate have grown to large IMHO. So I also > suggest to reduce it and use specialized methods for the 95% use > cases. > And the provide a few fallback methods that you can use for the other 5%. > > And we should consider not having copies with both String endpointUri > and Endpoint as the object. > You can always go from Endpoint -> endpointUri so we should consider > removing some of the Endpoint variations. > > > > > > > >> >> Romek >> >> 2009/4/19 Claus Ibsen : >>> Hi >>> >>> Actually I think the naming convention should be: >>> >>> send = for in only >>> sendWithHeader >>> sendWithHeaders >>> >>> sendAndReceive = for in out >>> sendAndReceiveWithHeader >>> sendAndReceiveWithHeaders >>> >>> Its more intuitive than currently >>> send = for in only >>> request = for in out >>> >>> However what about the "body" method we can do it like >>> >>> sendAndReceiveBody >>> sendAndReceiveBodyWithHeader >>> sendAndReceiveBodyWithHeaders >>> >>> or >>> >>> sendBodyAndReceiveWihHeader >>> sendBodyAndReceiveWithHeaders >>> >>> I prefer the former as its sending a body and receving a body. >>> >>> >>> Any thoughts on this, as we still have time to for this API change >>> before 2.0 is ready for release. >>> However the clock is ticking!!! >>> >>> >>> >>> >>> On Sat, Apr 4, 2009 at 9:20 AM, Claus Ibsen wrote: On Sat, Apr 4, 2009 at 8:38 AM, Ryan Gardner wrote: > The requestBody method makes sense (it requests a body) - but > "requestBodyAndHeader" and "requestBodyAndHeaders" etc methods make less > sense - because I'm only requesting one thing (the body). > > maybe "requestBodyWithHeader" makes more sense? for the > "sendBodyAndHeader" > methods, it makes sense because you are sending two things (the body and > the > header) > > although, perhaps I'm just going crazy? No it makes sense. You only get the body as reply. But to make it consistent the sendBodyAndHeader could also be named as sendBodyWithHeader. > > Ryan > -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus Apache Camel Reference Card: http://refcardz.dzone.com/refcardz/enterprise-integration >>> >>> >>> >>> -- >>> Claus Ibsen >>> Apache Camel Committer >>> >>> Open Source Integration: http://fusesource.com >>> Blog: http://davsclaus.blogspot.com/ >>> Twitter: http://twitter.com/davsclaus >>> Apache Camel Reference Card: >>> http://refcardz.dzone.com/refcardz/enterprise-integration >>> >> > > > > -- >
Re: Resequencer pattern does not work with the StreamRequencer config
Hi
Are you using Camel 1.x?
In Camel 2.0 it should use the Camel type converter system so it can
automatic convert it to a Long type that the resequencer requires.
In Camel 1.x you must provide a Long type as it uses the regular java
type converter = (Long).
And yes we should probably propagate this fix into Camel 1.x as well.
If you want to try out how to do this, then you can check the source
code for the file in trunk and compare it with the 1.x version.
And then create a patch and create a JIRA ticket and attach the patch.
On Mon, Apr 20, 2009 at 8:46 AM, Nawaz Ahmed wrote:
> Hi all,
>
> I was going through the Resequencer camel component available in the
> link: http://camel.apache.org/resequencer.html
>
>
>
> On trying the resequencer camel component with the StreamResequencer
> config with the code below:
>
>
>
> from("jms:queue:nq1").
>
> convertBodyTo(String.class).
>
> resequencer(constant("1000")).stream(new
> StreamResequencerConfig()).
>
> convertBodyTo(String.class).
>
> to("jms:queue:nq2")
>
>
>
> I am getting the below Exception in the Console:
>
> java.lang.ClassCastException: java.lang.String
>
> at
> org.apache.camel.processor.resequencer.DefaultExchangeComparator.getSequ
> enceNumber(DefaultExchangeComparator.java:81)
>
> at
> org.apache.camel.processor.resequencer.DefaultExchangeComparator.compare
> (DefaultExchangeComparator.java:75)
>
> at
> org.apache.camel.processor.resequencer.DefaultExchangeComparator.compare
> (DefaultExchangeComparator.java:38)
>
> at
> org.apache.camel.processor.resequencer.ElementComparator.compare(Element
> Comparator.java:63)
>
> at
> org.apache.camel.processor.resequencer.ElementComparator.compare(Element
> Comparator.java:28)
>
> at
> org.apache.camel.processor.resequencer.Sequence.higher(Sequence.java:109
> )
>
> at
> org.apache.camel.processor.resequencer.Sequence.successor(Sequence.java:
> 73)
>
> at
> org.apache.camel.processor.resequencer.ResequencerEngine.insert(Resequen
> cerEngine.java:192)
>
> at
> org.apache.camel.processor.StreamResequencer.process(StreamResequencer.j
> ava:167)
>
> at
> org.apache.camel.management.InstrumentationProcessor.process(Instrumenta
> tionProcessor.java:80)
>
> at
> org.apache.camel.processor.DeadLetterChannel.process(DeadLetterChannel.j
> ava:185)
>
> at
> org.apache.camel.processor.DeadLetterChannel.process(DeadLetterChannel.j
> ava:132)
>
> at org.apache.camel.processor.Pipeline.process(Pipeline.java:115)
>
> at org.apache.camel.processor.Pipeline.process(Pipeline.java:89)
>
> at
> org.apache.camel.management.InstrumentationProcessor.process(Instrumenta
> tionProcessor.java:68)
>
> at
> org.apache.camel.processor.UnitOfWorkProcessor.process(UnitOfWorkProcess
> or.java:52)
>
> at
> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.
> java:41)
>
> at
> org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncP
> rocessor.java:66)
>
> at
> org.apache.camel.component.jms.EndpointMessageListener.onMessage(Endpoin
> tMessageListener.java:72)
>
> at
> org.springframework.jms.listener.AbstractMessageListenerContainer.doInvo
> keListener(AbstractMessageListenerContainer.java:531)
>
> at
> org.springframework.jms.listener.AbstractMessageListenerContainer.invoke
> Listener(AbstractMessageListenerContainer.java:466)
>
> at
> org.springframework.jms.listener.AbstractMessageListenerContainer.doExec
> uteListener(AbstractMessageListenerContainer.java:435)
>
> at
> org.springframework.jms.listener.AbstractPollingMessageListenerContainer
> .doReceiveAndExecute(AbstractPollingMessageListenerContainer.java:322)
>
> at
> org.springframework.jms.listener.AbstractPollingMessageListenerContainer
> .receiveAndExecute(AbstractPollingMessageListenerContainer.java:260)
>
> at
> org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMe
> ssageListenerInvoker.invokeListener(DefaultMessageListenerContainer.java
> :944)
>
> at
> org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMe
> ssageListenerInvoker.run(DefaultMessageListenerContainer.java:875)
>
> at java.lang.Thread.run(Unknown Source)
>
> Apr 20, 2009 12:12:51 PM org.apache.camel.processor.Logger log
>
> SEVERE: java.lang.String
>
>
>
> Is there any problem with the above code or Is it the bug in the
> Resequencer Camel component?
>
>
>
>
>
> Thanks and Regards,
>
> Nawaz Ahmed
>
>
>
>
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Apache Camel Reference Card:
http://refcardz.dzone.com/refcardz/enterprise-integration
Resequencer pattern does not work with the StreamRequencer config
Hi all,
I was going through the Resequencer camel component available in the
link: http://camel.apache.org/resequencer.html
On trying the resequencer camel component with the StreamResequencer
config with the code below:
from("jms:queue:nq1").
convertBodyTo(String.class).
resequencer(constant("1000")).stream(new
StreamResequencerConfig()).
convertBodyTo(String.class).
to("jms:queue:nq2")
I am getting the below Exception in the Console:
java.lang.ClassCastException: java.lang.String
at
org.apache.camel.processor.resequencer.DefaultExchangeComparator.getSequ
enceNumber(DefaultExchangeComparator.java:81)
at
org.apache.camel.processor.resequencer.DefaultExchangeComparator.compare
(DefaultExchangeComparator.java:75)
at
org.apache.camel.processor.resequencer.DefaultExchangeComparator.compare
(DefaultExchangeComparator.java:38)
at
org.apache.camel.processor.resequencer.ElementComparator.compare(Element
Comparator.java:63)
at
org.apache.camel.processor.resequencer.ElementComparator.compare(Element
Comparator.java:28)
at
org.apache.camel.processor.resequencer.Sequence.higher(Sequence.java:109
)
at
org.apache.camel.processor.resequencer.Sequence.successor(Sequence.java:
73)
at
org.apache.camel.processor.resequencer.ResequencerEngine.insert(Resequen
cerEngine.java:192)
at
org.apache.camel.processor.StreamResequencer.process(StreamResequencer.j
ava:167)
at
org.apache.camel.management.InstrumentationProcessor.process(Instrumenta
tionProcessor.java:80)
at
org.apache.camel.processor.DeadLetterChannel.process(DeadLetterChannel.j
ava:185)
at
org.apache.camel.processor.DeadLetterChannel.process(DeadLetterChannel.j
ava:132)
at org.apache.camel.processor.Pipeline.process(Pipeline.java:115)
at org.apache.camel.processor.Pipeline.process(Pipeline.java:89)
at
org.apache.camel.management.InstrumentationProcessor.process(Instrumenta
tionProcessor.java:68)
at
org.apache.camel.processor.UnitOfWorkProcessor.process(UnitOfWorkProcess
or.java:52)
at
org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.
java:41)
at
org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncP
rocessor.java:66)
at
org.apache.camel.component.jms.EndpointMessageListener.onMessage(Endpoin
tMessageListener.java:72)
at
org.springframework.jms.listener.AbstractMessageListenerContainer.doInvo
keListener(AbstractMessageListenerContainer.java:531)
at
org.springframework.jms.listener.AbstractMessageListenerContainer.invoke
Listener(AbstractMessageListenerContainer.java:466)
at
org.springframework.jms.listener.AbstractMessageListenerContainer.doExec
uteListener(AbstractMessageListenerContainer.java:435)
at
org.springframework.jms.listener.AbstractPollingMessageListenerContainer
.doReceiveAndExecute(AbstractPollingMessageListenerContainer.java:322)
at
org.springframework.jms.listener.AbstractPollingMessageListenerContainer
.receiveAndExecute(AbstractPollingMessageListenerContainer.java:260)
at
org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMe
ssageListenerInvoker.invokeListener(DefaultMessageListenerContainer.java
:944)
at
org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMe
ssageListenerInvoker.run(DefaultMessageListenerContainer.java:875)
at java.lang.Thread.run(Unknown Source)
Apr 20, 2009 12:12:51 PM org.apache.camel.processor.Logger log
SEVERE: java.lang.String
Is there any problem with the above code or Is it the bug in the
Resequencer Camel component?
Thanks and Regards,
Nawaz Ahmed
Re: No consumers available on endpoint: Endpoint[direct:processMsg]
On Mon, Apr 20, 2009 at 11:13 AM, Henric Hedin wrote:
> Thank you, this simple solution (of course) worked like a charm!
>
> My DSL become a bit backwards, but guess I have to live with that :)
You can split it into multiple files and order them using the
XML configuration.
But maybe we need to add some feature to control the ordering of
routes being started.
That will also help graceful shutdown as well.
Feel free to create a ticket for controlling the order of routes.
Link from here:
http://camel.apache.org/support.html
Then we wont forget about it.
>
> /Henric
>
> On Mon, Apr 20, 2009 at 10:58 AM, Claus Ibsen wrote:
>
>> Hi
>>
>> Can you not just reorder the routes? Camel should process them in the
>> order they are defined.
>>
>>
>> On Mon, Apr 20, 2009 at 10:50 AM, Henric Hedin wrote:
>> > Hi,
>> >
>> > I have a problem which occurs when I have a Route which looks like this:
>> >
>> > // initiated from queue
>> > from("jms:queue:SOURCE_QUEUE").
>> > to("direct:processMsg");
>> >
>> > // initiated from file
>> > from("file://inbox).
>> > to("direct:processMsg");
>> >
>> >
>> > // Main flow
>> > from("direct:processMsg")
>> > .process("...")
>> > .to("validtor:foo.xsd")
>> > .to("jms:queue:DEST_QUEUE");
>> >
>> >
>> > Everything works fine when everything is initiated/started, but if there
>> > already is a message on the JMS-source when camel is started I get the
>> > following error:
>> >
>> > WARN DirectProducer - No consumers available on
>> endpoint:
>> > Endpoint[direct:processMsg] to process Exchange[JmsMessage:
>> >
>> > Seems like my "Main Flow" (defined in the same
>> > RouteBuilder.configure-method) isn't fully initiated/started when
>> "initiated
>> > from JMS" is already up and running (and starts to consume messages).
>> Could
>> > this be handled in some way, i.e. to not start to consume messages before
>> > all Route's are fully started?
>> >
>> > Right now I am using Spring to start my routes (inside a
>> > META-INF/spring/camel-context.xml) and I'm using Camel 2.0-M1.
>> >
>> > Best Regards,
>> > Henric
>> >
>>
>>
>>
>> --
>> Claus Ibsen
>> Apache Camel Committer
>>
>> Open Source Integration: http://fusesource.com
>> Blog: http://davsclaus.blogspot.com/
>> Twitter: http://twitter.com/davsclaus
>> Apache Camel Reference Card:
>> http://refcardz.dzone.com/refcardz/enterprise-integration
>>
>
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Apache Camel Reference Card:
http://refcardz.dzone.com/refcardz/enterprise-integration
Re: Resequencer pattern does not work with the StreamRequencer config
BTW the code you have can work if you change
constant("1000")
to a long type, something like this:
constant(Long.valueOf("1000"))
On Mon, Apr 20, 2009 at 8:46 AM, Nawaz Ahmed wrote:
> Hi all,
>
> I was going through the Resequencer camel component available in the
> link: http://camel.apache.org/resequencer.html
>
>
>
> On trying the resequencer camel component with the StreamResequencer
> config with the code below:
>
>
>
> from("jms:queue:nq1").
>
> convertBodyTo(String.class).
>
> resequencer(constant("1000")).stream(new
> StreamResequencerConfig()).
>
> convertBodyTo(String.class).
>
> to("jms:queue:nq2")
>
>
>
> I am getting the below Exception in the Console:
>
> java.lang.ClassCastException: java.lang.String
>
> at
> org.apache.camel.processor.resequencer.DefaultExchangeComparator.getSequ
> enceNumber(DefaultExchangeComparator.java:81)
>
> at
> org.apache.camel.processor.resequencer.DefaultExchangeComparator.compare
> (DefaultExchangeComparator.java:75)
>
> at
> org.apache.camel.processor.resequencer.DefaultExchangeComparator.compare
> (DefaultExchangeComparator.java:38)
>
> at
> org.apache.camel.processor.resequencer.ElementComparator.compare(Element
> Comparator.java:63)
>
> at
> org.apache.camel.processor.resequencer.ElementComparator.compare(Element
> Comparator.java:28)
>
> at
> org.apache.camel.processor.resequencer.Sequence.higher(Sequence.java:109
> )
>
> at
> org.apache.camel.processor.resequencer.Sequence.successor(Sequence.java:
> 73)
>
> at
> org.apache.camel.processor.resequencer.ResequencerEngine.insert(Resequen
> cerEngine.java:192)
>
> at
> org.apache.camel.processor.StreamResequencer.process(StreamResequencer.j
> ava:167)
>
> at
> org.apache.camel.management.InstrumentationProcessor.process(Instrumenta
> tionProcessor.java:80)
>
> at
> org.apache.camel.processor.DeadLetterChannel.process(DeadLetterChannel.j
> ava:185)
>
> at
> org.apache.camel.processor.DeadLetterChannel.process(DeadLetterChannel.j
> ava:132)
>
> at org.apache.camel.processor.Pipeline.process(Pipeline.java:115)
>
> at org.apache.camel.processor.Pipeline.process(Pipeline.java:89)
>
> at
> org.apache.camel.management.InstrumentationProcessor.process(Instrumenta
> tionProcessor.java:68)
>
> at
> org.apache.camel.processor.UnitOfWorkProcessor.process(UnitOfWorkProcess
> or.java:52)
>
> at
> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.
> java:41)
>
> at
> org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncP
> rocessor.java:66)
>
> at
> org.apache.camel.component.jms.EndpointMessageListener.onMessage(Endpoin
> tMessageListener.java:72)
>
> at
> org.springframework.jms.listener.AbstractMessageListenerContainer.doInvo
> keListener(AbstractMessageListenerContainer.java:531)
>
> at
> org.springframework.jms.listener.AbstractMessageListenerContainer.invoke
> Listener(AbstractMessageListenerContainer.java:466)
>
> at
> org.springframework.jms.listener.AbstractMessageListenerContainer.doExec
> uteListener(AbstractMessageListenerContainer.java:435)
>
> at
> org.springframework.jms.listener.AbstractPollingMessageListenerContainer
> .doReceiveAndExecute(AbstractPollingMessageListenerContainer.java:322)
>
> at
> org.springframework.jms.listener.AbstractPollingMessageListenerContainer
> .receiveAndExecute(AbstractPollingMessageListenerContainer.java:260)
>
> at
> org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMe
> ssageListenerInvoker.invokeListener(DefaultMessageListenerContainer.java
> :944)
>
> at
> org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMe
> ssageListenerInvoker.run(DefaultMessageListenerContainer.java:875)
>
> at java.lang.Thread.run(Unknown Source)
>
> Apr 20, 2009 12:12:51 PM org.apache.camel.processor.Logger log
>
> SEVERE: java.lang.String
>
>
>
> Is there any problem with the above code or Is it the bug in the
> Resequencer Camel component?
>
>
>
>
>
> Thanks and Regards,
>
> Nawaz Ahmed
>
>
>
>
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Apache Camel Reference Card:
http://refcardz.dzone.com/refcardz/enterprise-integration
Re: No consumers available on endpoint: Endpoint[direct:processMsg]
Hi
Can you not just reorder the routes? Camel should process them in the
order they are defined.
On Mon, Apr 20, 2009 at 10:50 AM, Henric Hedin wrote:
> Hi,
>
> I have a problem which occurs when I have a Route which looks like this:
>
> // initiated from queue
> from("jms:queue:SOURCE_QUEUE").
> to("direct:processMsg");
>
> // initiated from file
> from("file://inbox).
> to("direct:processMsg");
>
>
> // Main flow
> from("direct:processMsg")
> .process("...")
> .to("validtor:foo.xsd")
> .to("jms:queue:DEST_QUEUE");
>
>
> Everything works fine when everything is initiated/started, but if there
> already is a message on the JMS-source when camel is started I get the
> following error:
>
> WARN DirectProducer - No consumers available on endpoint:
> Endpoint[direct:processMsg] to process Exchange[JmsMessage:
>
> Seems like my "Main Flow" (defined in the same
> RouteBuilder.configure-method) isn't fully initiated/started when "initiated
> from JMS" is already up and running (and starts to consume messages). Could
> this be handled in some way, i.e. to not start to consume messages before
> all Route's are fully started?
>
> Right now I am using Spring to start my routes (inside a
> META-INF/spring/camel-context.xml) and I'm using Camel 2.0-M1.
>
> Best Regards,
> Henric
>
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Apache Camel Reference Card:
http://refcardz.dzone.com/refcardz/enterprise-integration
Re: Aggregator batchTimeout
Frank Schwarz wrote: > > How do you read it? > (a) The aggregation is aborted after the batchTimeout, leading to possibly > fragmentary messages. The aggregation is started, when the first message > is available. > (b) The aggregator waits the batchTimeout timespan and then begins the > aggregation. Only messages that are available at this time are aggregated. > > I understand (a) but unfortunately observe (b). > It is rather option b). The aggregator will take all aggregated messages after the specified timeout and send it in one message (exchange). Perhaps this article helps you as well: http://tmielke.blogspot.com/2009_01_01_archive.html -- View this message in context: http://www.nabble.com/Aggregator-batchTimeout-tp23127654p23134835.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Multiple consumers getting created in custom endpoint
Hi Manish,
I just created a JIRA[1] for this issue, and committed a quick fix for it.
I also did a quick fix for the Camel trunk, please feel free to verify
it with Camel 2.0.
We will get it out soon, maybe this Quarter :)
[1] https://issues.apache.org/activemq/browse/CAMEL-1544
Willem
Willem Jiang wrote:
> Hi Manish,
>
> Please feel free to create a JIRA[1] ticket for it.
> I just went through the code and can confirm your finding.
>
> BTW there are some changes in the Camel 2.0 about starting and stoping
> the RouteDefinintions. Not sure if it is resolved by Camel 2.0.
>
> [1]https://issues.apache.org/activemq/browse/CAMEL
>
> Willem
>
> Manish K Bafna wrote:
>> I guess there was an issue with Camel 1.5.
>> When starting the context, the routes are added in the list.
>> This route list is not cleared during stop.
>> So when the next time, the same context is started again, the routes gets
>> added to the list again thereby duplication.
>>
>> I solved the issue by clearing the route list during the stop of the
>> context.
>>
>> Thanks,
>> Manish.
>>
>> -Original Message-
>> From: Claus Ibsen [mailto:claus.ib...@gmail.com]
>> Sent: Wednesday, April 08, 2009 8:39 PM
>> To: users@camel.apache.org
>> Subject: Re: RE: Multiple consumers getting created in custom endpoint
>>
>> Hi
>>
>> I would suggest to use the JDK concurrency stuff for spawning threads.
>>
>> See for instance the SedaConsumer
>> https://svn.apache.org/repos/asf/camel/trunk/camel-core/src/main/java/org/apache/camel/component/seda/SedaConsumer.java
>>
>>
>> On Wed, Apr 8, 2009 at 4:53 PM, wrote:
>>> I think you should "kill" your threads on method doStop() or stop() of your
>>> consumer.
>>>
>>> They are invoked when CamelContext is stopped.
>>>
>>> Cheers,
>>> Bruno Borges
>>>
>>> On Apr 8, 2009 12:38am, Manish K Bafna wrote:
The same is visible in JMS component too.
Steps:
1. Create a route from JMS topic1 to JMS queue1
2. Start the context
3. Send 1 message to the topic.
4. The queue will also receive 1 message.
5. Stop the context
6. Start the context again
7. Send 1 message to the topic.
8. the same message will be seen in the queue 2 times when there should be
only 1.
9. Repeat the above steps and the number increases.
>>>
Thanks,
Manish.
>>>
-Original Message-
From: Manish K Bafna
Sent: Tuesday, April 07, 2009 6:45 PM
To: camel-u...@activemq. apache. org (camel-u...@activemq.apache.org)
Subject: Multiple consumers getting created in custom endpoint
>>>
Hi,
I am creating my own custom endpoint using Camel 1.5
>>>
public class AbcEndpoint extends DefaultEndpoint {
public Consumer createConsumer(Processor processor) throws Exception {
Consumer c=new AbcConsumer(this,processor);
return c;
}
.
}
>>>
public class AbcConsumer extends DefaultConsumer
{
protected void doStart() throws Exception {..do something...}
protected void doStop() throws Exception {--do something--}
}
>>>
When is start the context for the 1st time, 1 consumer is created, when I
stop it and start it again, createConsumer() is called 2 times and so on.
Do I have to do something to avoid this behavior. The problem is in the
doStart() method of the Consumer, I am creating my own threads. Now since
createConsumer() is being 2 times, doStart() is being called 2 times and
multiple threads are being created.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>
>
Re: Aggregator batchTimeout
On Mon, Apr 20, 2009 at 1:22 PM, tmi wrote: > > > Frank Schwarz wrote: >> >> How do you read it? >> (a) The aggregation is aborted after the batchTimeout, leading to possibly >> fragmentary messages. The aggregation is started, when the first message >> is available. >> (b) The aggregator waits the batchTimeout timespan and then begins the >> aggregation. Only messages that are available at this time are aggregated. >> >> I understand (a) but unfortunately observe (b). >> > > It is rather option b). The aggregator will take all aggregated messages > after the specified timeout and send it in one message (exchange). > Perhaps this article helps you as well: > http://tmielke.blogspot.com/2009_01_01_archive.html Its a very good blog post on the aggreagator. I have added links to it from the Camel aggregator EIP wiki page. > > > -- > View this message in context: > http://www.nabble.com/Aggregator-batchTimeout-tp23127654p23134835.html > Sent from the Camel - Users mailing list archive at Nabble.com. > > -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus Apache Camel Reference Card: http://refcardz.dzone.com/refcardz/enterprise-integration
Visio stencil of Camel EIP (work completed)
Hi, I have added the new visio stencil file relooked of the EIP patterns to respect the color of Camel : Sand. http://cwiki.apache.org/CAMEL/enterprise-integration-patterns.html(resources section) All the EIP icons have been relooked ;-) Regards, Charles SOA Architect
Re: Aggregator batchTimeout
Torsten, thank you for confirming my findings. So, essentially the aggregator waits the specified batchTimeout milliseconds, aggregates whatever it finds on the queue and then waits for the next round. This is not quite what I was expecting - or to put it differently: Is there a way to aggregate messages that vary considerable in their arriving times? Kind regards Frank tmi wrote: > > It is rather option b). The aggregator will take all aggregated messages > after the specified timeout and send it in one message (exchange). > -- View this message in context: http://www.nabble.com/Aggregator-batchTimeout-tp23127654p23137098.html Sent from the Camel - Users mailing list archive at Nabble.com.
Accessing header variables in XQuery endpoints
I need to access camel context header variables in my XQuery endpoint.
So in my context file i do something to this effect:
bar
where my xquery does something very simple like this:
{ $in.headers.foo }
// I also tried just $foo etc... Always with an error message that the
variable wasn't defined.
I've looked at the Jira https://issues.apache.org/activemq/browse/CAMEL-918
https://issues.apache.org/activemq/browse/CAMEL-918 and at some of the
related Jiras about updating documentation of this sort of thing but have
come up empty.
Any help available?
Thanks
Rog
--
View this message in context:
http://www.nabble.com/Accessing-header-variables-in-XQuery-endpoints-tp23141569p23141569.html
Sent from the Camel - Users (activemq) mailing list archive at Nabble.com.
Camel Guice Integration
I am working on a project with heavy Guice integration and we are now developing a messaging system and have decided to go with ActiveMQ+Camel+Guice. I have a good understanding of the producer, consumer and JMSComponent injection, but I haven't been able to figure out the Guice way of bringing up a Broker. The examples and tests use the vm transport so the Broker gets started for free... I need to start a broker using the TCP transport. anyone have any examples or suggestions about how to start an ActiveMQ Broker using Guice? Thanks, Adam -- View this message in context: http://www.nabble.com/Camel-Guice-Integration-tp23148603p23148603.html Sent from the Camel - Users mailing list archive at Nabble.com.
JPA component in a JEE5 environment
Hi, I tried to make use of the jpa component. It seems to be, however, that this component tries to create an EntityManagerFactory for its own - not a good idea in a JEE5 environment. Is there any way to let Spring do the resource-configuration / -lookup stuff? Cheers, Frank (Camel 2.0M1, JBoss 5, Hibernate, configuration in Spring XML) -- View this message in context: http://www.nabble.com/JPA-component-in-a-JEE5-environment-tp23149492p23149492.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: JPA component in a JEE5 environment
Hi Yeah sure overload the jpa component and set the entity manager factory. On Tue, Apr 21, 2009 at 7:39 AM, Frank Schwarz wrote: > > Hi, > > I tried to make use of the jpa component. It seems to be, however, that this > component tries to create an EntityManagerFactory for its own - not a good > idea in a JEE5 environment. > > Is there any way to let Spring do the resource-configuration / -lookup > stuff? > > Cheers, > Frank > > (Camel 2.0M1, JBoss 5, Hibernate, configuration in Spring XML) > -- > View this message in context: > http://www.nabble.com/JPA-component-in-a-JEE5-environment-tp23149492p23149492.html > Sent from the Camel - Users mailing list archive at Nabble.com. > > -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus Apache Camel Reference Card: http://refcardz.dzone.com/refcardz/enterprise-integration
