Re: SQL Component : Error while Inserting record in db table
2010/6/10 mevikasg :
>
> Hi Roman,
>
> Thanks for the reply.
>
> I have already tried it but no luck.
>
> Infact, tried following too:
>
> errorHandler(deadLetterChannel("mock:error"))
> from("imaps://imap.gmail.com?username=testm...@gmail.com&password="
>
> +"&deleteProcessedMessages=false&processOnlyUnseenMessages=true&consumer.delay=600")
> .process(new MyProProcessorImpl())
> .to("sql:insert into message values
> (3,'#',true,1)?dataSourceRef=myDataSource")
> .to("activemq:queue:VIKAS")
> .to("stream:out")
Could you give us the stacktrace you had this time? In this case I
believe everything should work just fine as there are no parameters we
have to put into the statement (as # is quoted anyway).
Roman
Re: SQL Component : Error while Inserting record in db table
Hello,
In camel-sql component you should use # sign instead of ? as question
marks has its own meaning in URL notation.
Unfortunately it looks that you cannot really use # sign itself, as it
will be converted to questionmark (so your '#' will become '?').
I'll create a a bug for this # sign problem.
Roman
2010/6/10 mevikasg :
>
> Hi,
>
> I am a newbie in Grails-Camel world.
>
> In my grails-groovy web application, i am trying to insert received messages
> in mail account into db table using Camel SQL component.
>
> So far via my Route, i can easily access my mail messages and even can
> perform SELECT queries on db as well. But, i am unable to Insert the
> received messages in database.
>
> Route:
>
>
> errorHandler(deadLetterChannel("mock:error"))
> from("imaps://imap.gmail.com?username=testm...@gmail.com&password="
> +
> "&deleteProcessedMessages=false&processOnlyUnseenMessages=true&consumer.delay=600")
> .process(new MyPro
> http://old.nabble.com/file/p28841104/MyProcessorImpl.java
> MyProcessorImpl.java cessorImpl())
> .to("sql:insert into message values
> (?,'#',true,1)?dataSourceRef=myDataSource")
> .to("activemq:queue:VIKAS")
> .to("stream:out")
>
>
> Its squealing following error:
>
> 2010-06-10 14:57:37,750 [Thread: 1
> org.apache.camel.component.mail.mailcompon...@1894800] ERROR
> processor.DeadLetterChannel - Failed delivery for exchangeId:
> ID-everest/1739-1276162039140/0-0. On delivery attempt: 0 caught:
> org.springframework.jdbc.UncategorizedSQLException:
> PreparedStatementCallback; uncategorized SQLException for SQL [insert into
> queues values (]; SQL state [S1009]; error code [0]; Parameter index out of
> range (1 > number of parameters, which is 0).; nested exception is
> java.sql.SQLException: Parameter index out of range (1 > number of
> parameters, which is 0).
> org.springframework.jdbc.UncategorizedSQLException:
> PreparedStatementCallback; uncategorized SQLException for SQL [insert into
> queues values (]; SQL state [S1009]; error code [0]; Parameter index out of
> range (1 > number of parameters, which is 0).; nested exception is
> java.sql.SQLException: Parameter index out of range (1 > number of
> parameters, which is 0).
> at
> org.springframework.jdbc.support.SQLStateSQLExceptionTranslator.translate(SQLStateSQLExceptionTranslator.java:96)
> at
> org.springframework.jdbc.support.SQLErrorCodeSQLExceptionTranslator.translate(SQLErrorCodeSQLExceptionTranslator.java:257)
> at
> org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:477)
> at
> org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:489)
> at
> org.apache.camel.component.sql.SqlProducer.process(SqlProducer.java:45)
> at
> org.apache.camel.impl.converter.AsyncProcessorTypeConverter$ProcessorToAsyncProcessorBridge.process(AsyncProcessorTypeConverter.java:43)
> at
> org.apache.camel.processor.SendProcessor.process(SendProcessor.java:84)
> at
> org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:68)
> at
> org.apache.camel.processor.interceptor.StreamCachingInterceptor.proceed(StreamCachingInterceptor.java:87)
> at
> org.apache.camel.processor.interceptor.StreamCachingInterceptor.process(StreamCachingInterceptor.java:82)
> at
> org.apache.camel.processor.DeadLetterChannel.process(DeadLetterChannel.java:189)
> at
> org.apache.camel.processor.DeadLetterChannel.process(DeadLetterChannel.java:133)
> 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(InstrumentationProcessor.java:68)
> at
> org.apache.camel.processor.interceptor.StreamCachingInterceptor.proceed(StreamCachingInterceptor.java:87)
> at
> org.apache.camel.processor.interceptor.StreamCachingInterceptor.process(StreamCachingInterceptor.java:82)
> at
> org.apache.camel.processor.UnitOfWorkProcessor.process(UnitOfWorkProcessor.java:52)
> at
> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:41)
> at
> org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:66)
> at
> org.apache.camel.component.mail.MailConsumer.processMessage(MailConsumer.java:174)
> at
> org.apache.camel.component.mail.MailConsumer.processMessages(MailConsumer.java:156)
> at
> org.apache.camel.component.mail.MailConsumer.poll(MailConsumer.java:105)
> at
> org.apache.camel.impl.ScheduledPollConsumer.run(ScheduledPollConsumer.java:66)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> at
> java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150)
> at
>
Re: request reply with sql query
This is DEBUG level. If you set DEBUG you somehow agree to see a lot of junk
;) Just raise log4j log level for this logger (or simply for
org.springframework).
BTW this is perfectly valid behavior - Spring-JMS just logs those things on
DEBUG level.
Roman
2009/10/19 linuca
>
> But I want ActiveMQ to do the actual JMS sending / receiving.
>
> Anyway, I changed the code to:
>
> Object response =
> template.requestBody("activemq:queue:test.queue?maxMessagesPerTask=-1",
> "select * from clients");
>
> And it does the same "did not receive a message " logging.
>
> Any ideas?
>
>
> Claus Ibsen-2 wrote:
> >
> > On Mon, Oct 19, 2009 at 4:56 PM, linuca wrote:
> >>
> >> Thanks Claus,
> >>
> >> It works like charm.
> >>
> >> For now, I just send one message.
> >>
> >> I find weird that every second I get this message in the log:
> >>
> >> DEBUG org.springframework.jms.listener.DefaultMessageListenerContainer -
> >> Consumer [ActiveMQMessageConsume
> >> r { value=ID:mendoza04-43584-1255964003207-0:0:1:1, started=true }] of
> >> session [ActiveMQSession
> >> {id=ID:mendoza04-43584-1255964003207-0:0:1,started=true}]
> >> did not receive a message
> >>
> >> Why is that?
> >
> > Its actually Spring JMS that does the JMS sending / receiving. Camel
> > is just on the top :)
> >
> > You may be able to get rid of it by setting the maxMessagesPerTas=-1
> > as documented here:
> > http://camel.apache.org/jms.html
> >
> >
> >
> >> --
> >> View this message in context:
> >>
> http://www.nabble.com/request-reply-with-sql-query-tp25958657p25959791.html
> >> Sent from the Camel - Users (activemq) 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
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/request-reply-with-sql-query-tp25958657p25960255.html
> Sent from the Camel - Users (activemq) mailing list archive at Nabble.com.
>
>
Re: sql throwing oracle 17004 ORA-17004 error
I believe before you send your message to jms endpoint you should clear your message body. SQL componet assumes your body is used as query parameters. If you don't have any parameters in your query, but you send some body, there could be an exception thrown. Roman 2009/10/19 SoaMattH > > > If I change the Query to > uri="sql:select 'MyTitle' title from > dual?dataSourceRef=sabaDataSource"/> > > I get the same error ?? Any Thoughts?? > > I can query the db and tables with dbVisualizer and the dame odbc14.jar > for oracle 10.2.0.3.0 > > Thanks Matt Hannay > > > > SoaMattH wrote: > > > > I have the following End point and route: > > > >> uri="sql:select * from > > RPV_DES_OMS_COURSES?dataSourceRef=sabaDataSource"/> > > > > > > > > > > > > > > > > > > > > > > The Endpoint is a view that consists of CHAR, VARCHAR2 and DATE coulmns > > so nothing out of the ordinary. > > > > > > > > > > When the SQL is called the following Error is given: > > > > DEBUG [DefaultQuartzScheduler_QuartzSchedulerThread] > > (SimpleJobFactory.java:50) - Producing instance of Job > > 'DEFAULT.quartz://omsSabaCourses/?cron=0+0+20+%3F+*+MON-SUN', > > class=org.apache.camel.component.quartz.CamelJob > > DEBUG [DefaultQuartzScheduler_Worker-1] (JobRunShell.java:201) - Calling > > execute on job DEFAULT.quartz://omsSabaCourses/?cron=0+0+20+%3F+*+MON-SUN > > DEBUG [DefaultQuartzScheduler_Worker-1] (QuartzEndpoint.java:115) - > Firing > > Quartz Job with context: JobExecutionContext: trigger: > > 'Camel.omsSabaCourses job: > > DEFAULT.quartz://omsSabaCourses/?cron=0+0+20+%3F+*+MON-SUN fireTime: 'Mon > > Oct 19 20:00:00 EST 2009 scheduledFireTime: Mon Oct 19 20:00:00 EST 2009 > > previousFireTime: 'null nextFireTime: Tue Oct 20 20:00:00 EST 2009 > > isRecovering: false refireCount: 0 > > DEBUG [DefaultQuartzScheduler_Worker-1] (QuartzEndpoint.java:115) - > Firing > > Quartz Job with context: JobExecutionContext: trigger: > > 'Camel.omsSabaCourses job: > > DEFAULT.quartz://omsSabaCourses/?cron=0+0+20+%3F+*+MON-SUN fireTime: 'Mon > > Oct 19 20:00:00 EST 2009 scheduledFireTime: Mon Oct 19 20:00:00 EST 2009 > > previousFireTime: 'null nextFireTime: Tue Oct 20 20:00:00 EST 2009 > > isRecovering: false refireCount: 0 > > DEBUG [DefaultQuartzScheduler_Worker-1] > > (AbstractPlatformTransactionManager.java:371) - Creating new transaction > > with name [null]: PROPAGATION_REQUIRED,ISOLATION_DEFAULT > > DEBUG [DefaultQuartzScheduler_Worker-1] > (DriverManagerDataSource.java:163) > > - Creating new JDBC DriverManager Connection to > > [jdbc:oracle:thin:@aserver:1521:sabpdb] > > DEBUG [DefaultQuartzScheduler_Worker-1] > > (DataSourceTransactionManager.java:202) - Acquired Connection > > [oracle.jdbc.driver.t4cconnect...@19f1bac] for JDBC transaction > > DEBUG [DefaultQuartzScheduler_Worker-1] > > (DataSourceTransactionManager.java:219) - Switching JDBC Connection > > [oracle.jdbc.driver.t4cconnect...@19f1bac] to manual commit > > DEBUG [DefaultQuartzScheduler_Worker-1] (DefaultProducer.java:66) - > > Starting producer: Producer[sql://select * from > > RPV_DES_OMS_COURSES?dataSourceRef=sabaDataSource] > > DEBUG [DefaultQuartzScheduler_Worker-1] (DefaultProducer.java:66) - > > Starting producer: Producer[sql://select * from > > RPV_DES_OMS_COURSES?dataSourceRef=sabaDataSource] > > DEBUG [DefaultQuartzScheduler_Worker-1] (ProducerCache.java:201) - Adding > > to producer cache with key: Endpoint[sql://select * from > > RPV_DES_OMS_COURSES?dataSourceRef=sabaDataSource] for producer: > > Producer[sql://select * from > > RPV_DES_OMS_COURSES?dataSourceRef=sabaDataSource] > > DEBUG [DefaultQuartzScheduler_Worker-1] (ProducerCache.java:201) - Adding > > to producer cache with key: Endpoint[sql://select * from > > RPV_DES_OMS_COURSES?dataSourceRef=sabaDataSource] for producer: > > Producer[sql://select * from > > RPV_DES_OMS_COURSES?dataSourceRef=sabaDataSource] > > DEBUG [DefaultQuartzScheduler_Worker-1] (JdbcTemplate.java:574) - > > Executing prepared SQL statement [select * from RPV_DES_OMS_COURSES] > > INFO [DefaultQuartzScheduler_Worker-1] > (XmlBeanDefinitionReader.java:323) > > - Loading XML bean definitions from class path resource > > [org/springframework/jdbc/support/sql-error-codes.xml] > > DEBUG [DefaultQuartzScheduler_Worker-1] (DefaultDocumentLoader.java:72) - > > Using JAXP provider [org.apache.xerces.jaxp.DocumentBuilderFactoryImpl] > > DEBUG [DefaultQuartzScheduler_Worker-1] (BeansDtdResolver.java:72) - > Found > > beans DTD [http://www.springframework.org/dtd/spring-beans-2.0.dtd] in > > classpath: spring-beans-2.0.dtd > > DEBUG [DefaultQuartzScheduler_Worker-1] > > (DefaultBeanDefinitionDocumentReader.java:86) - Loading bean definitions > > DEBUG [DefaultQuartzScheduler_Worker-1] > > (DefaultSingletonBeanRegistry.java:214) - Creating shared instance of > > singleton bean 'DB2' > > DEBUG [DefaultQuartzScheduler_Worker-1] > > (AbstractAutowireCapableBeanFactory.java:383) - Creating instance of be
Re: Route Camel : Pass variables in a SQL query
You set the body to constant value, so you have constant value. Use EL
expression instead of constant one if you want it to be evaluated.
In simple words put where you have ;)
Roman
2009/9/27 titexe :
>
> Hello,
>
> I'm trying to develop a route camel who can:
>
> Retrieve a value from the header of a message
> and put this value in an SQL query.
>
> Below my configuration:
>
>
>
>
> UPDATE CAMEL SET B='${in.header.MessageId}' WHERE
> C=2
>
>
>
>
> When I tested this variable ${in.header.MessageId}, I retrieve its value,
> unlike when I put this variable in the SQL query.
>
> Otherwise, the SQL executes perfectly.
>
> Thank you in advance for helping me complete this route
>
> Best regards,
>
> titexe
> --
> View this message in context:
> http://www.nabble.com/Route-Camel-%3A-Pass-variables-in-a-SQL-query-tp25635878p25635878.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
>
Re: config datasource sql server
Hey! Looks like you should do what exception tells you to do: please check your classpath contains the needed jar camel component. that is camel-jdbc.jar. If you have it on your classpath, then we will look into different reasons. Roman 2009/9/23 titexe : > > Hello, > > I'm just a beginner, I'm enthusiasm to make a model based on ActiveMQ and > Camel. > > I try to make a camel route which query the database and put the result into > a queue. > > I have a problem with the declaration of the database sql server 2005 I > always get this error: > > ERROR: java.lang.RuntimeException: Failed to execute start task. Reason: > org.apache.camel.NoSuchEndpointException: No endpoint could be found for: > jdb > c: testdb, please check your classpath contains the needed jar camel > component. > > below my configuration: > > xmlns="http://activemq.apache.org/camel/schema/spring";> > > > > select * from customer > > > > > > > > > > > > > > > version activemq : fuse message broker 5.3.0.3 > version java : Java 1.6 > > Thank you for helping me resolve this problem, > > Best regards, > > titexe > -- > View this message in context: > http://www.nabble.com/config-datasource-sql-server-tp25531210p25531210.html > Sent from the Camel - Users mailing list archive at Nabble.com. > >
Re: dynamic sql request
You can also use SQL component this way:
from("jms:q_in")
.transform(XPathBuilder.xpath("/Listes/Liste/id").stringResult())
.to("sql:SELECT * FROM v_test WHERE indv=#")
.to("somewhere else");
Roman
2009/8/7 Claus Ibsen :
> On Thu, Aug 6, 2009 at 7:09 PM, abdes wrote:
>>
>> Hi,
>> i have diffficult to pass parameter from exchange content to SQL request :
>> here my code :
>>
>> exchange content :
>>
>>
>> 123456
>>
>>
>> 123456
>>
>>
>>
>>
>> from("jms:q_in")
>> .enrich("direct:resource", new ExampleAggregationStrategy())
>> .to("direct:result");
>>
>>
>>
>> from("direct:resource")
>> .setBody(constant("SELECT * FROM v_test WHERE indv ="))
>>
>> That i want, is to pass value to indv parameter.
>> How can i process ?
>>
>
> The XML above is that content from the JMS message?
>
> Do you need the XML afterwards or only need to grab the tag?
>
> You can use XPath to select the XML node of choice. But also use a
> POJO to fetch it?
> In the POJO you can even set the result as the SQL statement directly
>
> For starters you can use a plain Processor that is a bit low level but
> gives you power in regular Java code to work with it.
>
> To get the data as XML you can use
>
> Document doc = exchange.getIn().getBody(Document.class);
>
> from(jms)
> process(new MyIdToSQLProcessor())
> .to("jdbc:myDatasource")
> .to("somewhereelse");
>
>
>
> And in relation to the constant language. Camel provides a bit more
> powerful the simple language that allows you to build strings dynamic
> http://camel.apache.org/simple.html
>
> And then there are all the others with a real programming language underneath
> http://camel.apache.org/languages.html
>
>
>> Regards
>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/dynamic-sql-request-tp24850692p24850692.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
>
Re: Camel 2.0-snapshot deployed on SMKNL4 - There are 2 parameters that couldn't be set on the endpoint
When you use & in XML document it has to be written as & as single
& starts escape sequences in XML. The same goes to '<' that is written
as < and to other special symbols.
Roman
2009/8/3 SoaMattH :
>
> The #{} is my custom place holder configurer.
>
>
> uri="file://#{omsws.incident.file.landingzone}/?preMoveNamePrefix=#{omsws.incident.file.processing}/&moveNamePrefix=#{omsws.incident.file.processed}/;"/>
>
> If I put a & in as aseperator I get validation error:
> The reference to entity "moveNamePrefix" must End with the ';' delimiter
> and the following Exception:
>
> org.springframework.beans.factory.parsing.BeanDefinitionParsingException:
> Configuration problem: Failed to import bean definitions from relative
> location [Camel-Context.xml]
> Offending resource: ServletContext resource
> [/WEB-INF/ApplicationContext.xml]; nested exception is
> org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line
> 30 in XML document from ServletContext resource [/WEB-INF/Camel-Context.xml]
> is invalid; nested exception is org.xml.sax.SAXParseException: The reference
> to entity "moveNamePrefix" must end with the ';' delimiter.
> at
> org.springframework.beans.factory.parsing.FailFastProblemReporter.error(FailFastProblemReporter.java:68)
>
>
>
> Thanks Matt
>
>
>
>
>
>
> SoaMattH wrote:
>>
>> I am A little confuses as to how my Enpoint should be configured
>> when trying to add properties and delimiters?
>>
>> I am Utilising Camel 2.0M3
>>
>> If I say
>> > uri="file://#{omsws.incident.file.landingzone}/" />
>> Every thing works fine .
>>
>>
>> If I say
>> >
>> uri="file://#{omsws.incident.file.landingzone}/?preMoveNamePrefix=#{omsws.incident.file.processing}/&moveNamePrefix=#{omsws.incident.file.processed}/"
>> />
>>
>> where in my properties
>> #
>> # Incident File Processing.
>> #
>> omsws.incident.file.landingzone=D:/matt-dev/incident/landingzone
>> omsws.incident.file.processing=D:/matt-dev/incident/processing
>> omsws.incident.file.processed=D:/matt-dev/incident/processed
>> omsws.incident.file.deadletter=D:/matt-dev/incident/deadletter
>>
>> I get a validation Error
>> "The reference to entity moveNamePrefix must end with the ';' delimiter.
>>
>> If I change it to
>> >
>> uri="file://#{omsws.incident.file.landingzone}/?preMoveNamePrefix=#{omsws.incident.file.processing}/;moveNamePrefix=#{omsws.incident.file.processed}/;"
>> />
>>
>> No validation errors, I rebuild and deploy I get:
>>
>> org.apache.camel.ResolveEndpointFailedException: Failed to resolve
>> endpoint: incidentFileEndpoint due to: Error creating bean with name
>> 'incidentFileEndpoint': FactoryBean threw exception on object creation;
>> nested exception is org.apache.camel.ResolveEndpointFailedException:
>> Failed to resolve endpoint:
>> file://D:/matt-dev/incident/landingzone/?preMoveNamePrefix=D%3A%2Fmatt-dev%2Fincident%2Fprocessing%2F%3BmoveNamePrefix%3DD%3A%2Fmatt-dev%2Fincident%2Fprocessed%2F%3B
>> due to: Failed to resolve endpoint:
>> file://D:/matt-dev/incident/landingzone/?preMoveNamePrefix=D%3A%2Fmatt-dev%2Fincident%2Fprocessing%2F%3BmoveNamePrefix%3DD%3A%2Fmatt-dev%2Fincident%2Fprocessed%2F%3B
>> due to: There are 1 parameters that couldn't be set on the endpoint. Check
>> the uri if the parameters are spelt correctly and that they are properties
>> of the endpoint. Unknown
>> parameters=[{preMoveNamePrefix=D:/matt-dev/incident/processing/;moveNamePrefix=D:/matt-dev/incident/processed/;}]
>> at
>> org.apache.camel.impl.DefaultCamelContext.getEndpoint(DefaultCamelContext.java:404)
>>
>>
>> org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:45)
>> at
>> org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3764)
>>
>>
>> org.springframework.beans.factory.support.FactoryBeanRegistrySupport$1.run(FactoryBeanRegistrySupport.java:127)
>> at java.security.AccessController.doPrivileged(Native Method)
>>
>> What should I defint it as?
>>
>> Thanks Matt
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> cmoulliard wrote:
>>>
>>> Hi,
>>>
>>> The following error is reported when I deploy a camel project on Service
>>> Mix Kernel 1.1.0 snashot where Camel-2.0 SNAPSHOT osgi bundle is deployed
>>> ?
>>>
>>> 17:36:17,640 | ERROR | xtenderThread-15 | OsgiBundleXmlApplicationContext
>>> | gatedExecutionApplicationContext 366 | Post refresh error
>>> org.apache.camel.ResolveEndpointFailedException: Failed to resolve
>>> endpoint:
>>> file://d:/temp/data/?preMoveNamePrefix=inprogress/&moveNamePrefix=../done/
>>> due to: org.apache.camel.ResolveEndpointFailedException: Failed to
>>> resolve endpoint:
>>> file://d:/temp/data/?preMoveNamePrefix=inprogress/&moveNamePrefix=../done/
>>> due to: There are 2 parameters that couldn't be set on the endpoint.
>>> Check the uri if the parameters are spelt correctly and that they are
>>> properties of the endpoint. Unknown parameters=[{moveNamePrefix=../done/,
>>> preMoveNamePrefi
Re: Load Balancing Questions
Hello Carlo!
You can try StickyLoadBalancer instead of regular one and have an
expression that returns the current thread like
from("direct:start").loadBalance().
sticky(new Expression() { public evaluate(Exchange e,
Thread.class){return Thread.currentThread();}}).to("mock:x", "mock:y",
"mock:z");
I believe it should work.
Roman
2009/7/29 Carlo Camerino :
> Hi,
>
> I have an inquiry regarding balancing.
> If i use round robin load balancing, it will distribute my requests into
> three different queues which have different processors in them.
>
> If I spawn for example 200 threads, they will go to queue 1,2,3 in a round
> robin way.
> This is if 200 threads each have 1 requests
>
> What if for example I have 200 threads?
> but each thread can have a variable number of requests?
>
> Is there anyway that I can set it
>
> 1st Thread - 3 requests ( All GOes To Queue 1)
> 2nd Thread - 4 requests ( All Goes To Queue 2)
> 3rd Thread - 1 request ( Goes To Queue 3)
> 4th Thread - 3 request( Goes TO Queue 1)
>
> So in short, the affinity is related to the thread ( or thread id) i'm not
> sure.
>
> Is there a way for camel to do this?
>
> Thanks A Lot!
>
Re: How to avoid a org.apache.camel.component.bean.AmbiguousMethodCallException when calling methods of a Bean component
You can always send BeanInvocation instance as your body. Then you can choose whatever method you want in your payload. Roman 2009/7/14 Charles Moulliard : > Hi, > > Is there any other workaround except renaming the method "updatStatus" to > avoid to have an error : AmbiguousMethodCallException. > > In my example, I would like to allow to have two methods with the same name > but having different input parameters and return type > > Here is the route that I want to use : > > from(file) > .to(beanA) // Create Request > .to(beanB) // parse request > .to(queueA) > > from(queueA) > .to(beanC) // validate request > .to(beanD method="updateStatus") // update Status (input parameter : Body = > Request.class, return type = void) > .to(queueB) > > ... > > from(queueX) > .to(beanX) > .to(beanD method="updateStatus") // update Status (input parameter : Body = > Report.class, Header "requestId" String request ID, return type = void) > > Is it possible ? > > Regards, > > Charles Moulliard > Senior Enterprise Architect > Apache Camel Committer > > * > blog : http://cmoulliard.blogspot.com >
Re: XML Validation throws NoXmlBodyValidationException
2009/6/23 Claus Ibsen : > Hi > I think the ValidatingProcessor was created like this using DOMSource and > DOMResult. > > I wonder if it can use SaxSource and SaxResult instead, in case its faster > and uses less CPU resources. I guess it could be, but according to [1] it has to be either DOMSource or SaxSource even if the signature says that it is generic Source. But you are right - SaxSource in majority of cases would be better. Roman [1] http://java.sun.com/j2se/1.5.0/docs/api/javax/xml/validation/Validator.html
Re: end() method in a route
BTW The message in the Exception could be more clear. It is not
obvious what "Root node with no active block" is ;)
Roman
2009/6/10 Claus Ibsen :
> On Wed, Jun 10, 2009 at 1:09 PM, Peter Maas wrote:
>> Hi,
>>
>> I wondered what the purpose of the 'end' method in a route is. I sort of
>> expected it to be a terminator for dead-end routes. But that doesn't seem to
>> be the case.
>>
>> If I do something like this:
>>
>> from("direct:start")
>> .process(new Processor(){
>> public void process(Exchange arg0) throws Exception {
>> System.out.println("hello!");
>> }
>> })
>> .end();
>>
>>
>> I get the following exception:
>>
>>
>> java.lang.IllegalArgumentException: Root node with no active block
>> at
>> org.apache.camel.model.ProcessorDefinition.end(ProcessorDefinition.java:719)
>>
>>
>> I currently 'terminate' such a route by using a non-existent direct
>> endpoint, which works but raises a WARN messages...
>>
>> What is the preferred way to do this?
> Not to use end() at all.
>
> They should only be used for some special EIP that kinda have sub
> routes, such as
> - aggregator
> - splitter
> and a few others
>
> So your route should just be:
> from("direct:start")
> .process(new Processor(){
> public void process(Exchange arg0) throws Exception {
> System.out.println("hello!");
> }
> });
>
>
>
>>
>> -P
>>
>>
>>
>
>
>
> --
> Claus Ibsen
> Apache Camel Committer
>
> Open Source Integration: http://fusesource.com
> Blog: http://davsclaus.blogspot.com/
> Twitter: http://twitter.com/davsclaus
>
Re: How long do the camel headers live in routes?
2009/5/6 Matteo Redaelli :
>
> Thanks Claus for you answer, I'll look at the XSD for any future issue.
>
> But sorry for the silly question: now that I can set a property, how can I
> retrieve it in spring xml?
> do I have to set a header with the value of my new property to use it in a
> velocity template?
I believe velocity will see it the same way as headers. But I'm not sure.
You can of course also set it as header just before velocity endpoint
and there is... strange convention that whenever you read your header
via header() or it reads the header, but if none exists, it
returns the propoerty. So to set a header 'foo' to the value of 'foo'
property you do
setHeader("foo", header("foo"))
looks strange, but works :D
Roman
Re: How long do the camel headers live in routes?
2009/5/4 Matteo Redaelli : > > Thanks for your quick answer. > > Is it possibile to use SetProperty in Spring XML routes? Sure it is. Take a look at camel schema for XML routes: http://camel.apache.org/schema/spring/camel-spring.xsd there is setProperty element defined and you can use it the same way as setHeader element. Roman
Re: How long do the camel headers live in routes?
Ciao Matteo! You can use exchange properties for this. You do it using setProperty() instead of setHeader() and they live as long as the flow. Headers can be lost at endpoints basically as they usually represent some component specific things (request headers in http protocol are different than response headers, so they simply have to be lost). Roman 2009/5/4 Matteo Redaelli : > > Ciao > > I would like to save a value at the beginnig of my route and reuse it at the > end. What could I do? Headers? > How long do the camel headers live in routes? > > Is it possible to do something like > from jms -> set header MYHEADER -> to velocity -> to jdbc -> split -> to > velocity (reusing MYHEADER) -> to jms > ? > > Thanks in advance > Matteo > > -- > View this message in context: > http://www.nabble.com/How-long-do-the-camel-headers-live-in-routes--tp23375104p23375104.html > Sent from the Camel - Users mailing list archive at Nabble.com. > >
Re: Error handling Questions
In Camel 1.x there is AsyncProcessor interface (it extends Processor)
that allows you to handle things asynchronously. While it is rather
hard to use it, you have a chance to process your request
asynchronously.
In fact Camel doesn't specify if error handling will happen in some
thread or not - it depends on components you use, and processor type
you use. Especially with AsyncProcessor you don't really know which
thread will execute your AsyncCallback (interface used in
AsyncProcessor).
But as Clause mentioned Camel plans to change this interface to
something JDK's Future-based solution in 2.x.
Roman
2009/5/4 Zhi Zhou :
> Claus,
> Thank you very much for the quick response!
>
> On Mon, May 4, 2009 at 5:07 PM, Claus Ibsen wrote:
>
>> Hi
>>
>> What version of Camel are you using? Camel 2.0 has many improvments in
>> error handling and processing over 1.x.
>>
>
> Sorry that I forgot to mention I am using 1.x for now as 2.0 is still going
> through milestone release stage.
>
>
>>
>> On Mon, May 4, 2009 at 10:54 AM, Zhi Zhou wrote:
>> > Hello all,
>> >
>> > Camel's error handling is pretty powerful, but lately I am having two
>> > questions about it.
>> >
>> > 1) I am working a custom camel component, and not quite sure how to
>> handle
>> > certain error condition. I may be having wrong idea from the very
>> beginning
>> > but let me give you a simple scenario to describe the issue.
>> >
>> > from("jms:someQueue").to("myCustom:endpoint");
>> >
>> > My custom endpoint does some async message sending. For performance
>> reason,
>> > it should keep sending messages from the jms queue without waiting for
>> > responses. responses come back asynchronously from the remote host. The
>> > question here is that if a response doesn't return without a timeout
>> period,
>> > I would like an exception to be thrown and hence to be captured by
>> camel's
>> > error handling where some redelivery logic is made possible.
>> unfortunately,
>> > with this async nature of producing, the timeout event will be triggered
>> in
>> > a different thread and hence no way to have camel to capture my created
>> > exception up to my limited camel knowledge.
>> We are planning to add a new Async API in Camel 2.0 so you leverage
>> Camel to do async routing much more easily.
>>
>
>> Anyway if you leverage the async task execution in the JDK 1.5
>> concurrent API then you can get a handle to your async task, known as
>> a Future handle.
>> With that you can test whether the task is complete, get the result,
>> get the result within a timeout period etc.
>>
> Exactly I am using the concurrent API to implement a timeout task. but my
> headache is how to have camel informed of the exception that's created in my
> timeout task. it seems impossible to call any current 1.x API to align this
> timeout exception with the camel's standard error handling yet.
>
> well look forward to the new Async API of 2.0. before having it on board, I
> probably still need to think of a solution.
>
>
>>
>> >
>> >
>> > 2) my second question: is it possible that the error handling will happen
>> in
>> > multiple threads in case of multi-threaded exchange processing. for
>> example,
>> > the following route:
>> >
>> > from("direct:start").thread(10).process(new Processor(){/*throw some
>> > exception*/});
>> >
>> > will the error handling happen in the same thread of the caller that
>> > produces message to "direct:start", or will happen concurrently in
>> multiple
>> > threads?
>> The thread is basically a worker pool, and since you use direct
>> component your route is synchronous all the way. Leveraging up till 10
>> worker threads.
>>
>> If you want to divide into async you should use the seda component.
>> But when you want to do request-reply over seda it gets complicated.
>>
>
> I am just wondering whether camel will spawn a thread for error handing or
> it's just using the current thread context. my above example might not be
> exactly what I wanted to show. Put it more straightforward, if I have an
> event-driven consumer, it typically does:
>
> getProcessor().process(exchange);
>
> to have the exchange consumed. in case of an exception ocurred down the
> route, camel's error handling will be sharing the same thread as the above
> call or executing in a separate thread? if it's the same thread, that means
> my event-driven consumer will be delayed until the exchange gets clear on
> exception.
>
>
>
>> Hence we are planning a new Async API in Camel 2.0 that addresses this.
>> There is a discussion on this in the camel-dev forum.
>>
>>
>> >
>> >
>> > Zhi
>> >
>>
>>
>>
>> --
>> 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: Asynchronous Jetty
2009/4/24 Aaron Mulder :
> I have a situation where a request comes in to Jetty, and goes through
> two other routes and queues before a response is generated that allows
> the HTTP response to be sent to the caller. I'd like to be able to
> force Jetty into using continuations so it doesn't park a thread while
> those other routes are going.
>
> The async page on the wiki suggests a usage pattern that would allow
> Jetty to operate asynchronously, but it's short on specifics, and it's
> not clear I can coerce my logic into that pattern anyway.
>
> It was suggested on IRC that I file a Jira, but I just thought I'd
> collect any other thoughts on this before doing so.
>
> I guess I'm thinking it wold be nice to have like a
> "continuations=true" type parameter on a Jetty endpoint that would
> explicitly tell it to go into asynchronous mode.
Hello Aaron!
I guess Jetty uses continuations by default. The only thing is that
processors you send messages to have to support asynchronous
messaging.
If you are not sure if your processors/endpoints support async
processing you can always do something like:
from("jetty:http://0.0.0.0:1234/foo";).threads(5).to(something);
I'm writing it without actually looking into the code, so I might be
wrong, but lets check it out.
Roman
Re: Camel Content Filter
You can save the body in some header first, do the validation and then
reset the body using the header like
.setHeader("old", body())
.transform(xquery())
.to("validate:mySchema.xsl")
.transform(header("old"))
Roman
2009/4/22 ychawla :
>
> Hello All,
> I have a question about the usage of the content filter. I have a route
> where I want to validate the message, but I only want to validate a certain
> part of the message. I looked at the content filter pattern and it didn't
> seem like Camel had much built in functionality there:
>
> http://camel.apache.org/content-filter.html
>
> In the Spring XML, it referenced having a bean do a transform:
>
>
> What I would like to do is to pass part of a message using xquery to the
> validation component. Something like this:
>
>
> //tns:pathToMyElementToValidate
>
> http://foo.com/mySchema.xsd"/>
>
> The above code works, but the body of my message is now the xquery result
> for further endpoints rather than the whole message.
>
> Is there a way to filter an XML node for one endpoint and then go back to
> using the original message for the following endpoints?
>
> Thanks,
> Yogesh
>
> --
> View this message in context:
> http://www.nabble.com/Camel-Content-Filter-tp23175505p23175505.html
> Sent from the Camel - Users (activemq) mailing list archive at Nabble.com.
>
>
Re: programatically rewire routes
Another thing you can do is to substitute some endpoints in the
context like this (assuming you use ContextTestSupport):
protected CamelContext createCamelContext() throws Exception {
CamelContext camelContext = super.createCamelContext();
camelContext.addEndpoint("jms:in.queue", new
DirectEndpoint("jms:in.queue"));
camelContext.addEndpoint("http://www.cnn.com/";, new
MockEndpoint("http://www.cnn.com/";));
return camelContext;
}
Of course it works for endpoints only, but might be enough. You can
always attach processors to mock endpoint then, but the point is, that
you can test your business flow without explicitly using mock
component.
Roman
2009/4/22 Peter Maas :
> Hi,
>
> is it possible the programmatically replace parts of a route (for testing
> purposes) to temporarily add processor in the middle of the route for
> example? One case I (think) I need it for is for testing unexpected errors,
> I'd like to mimic this by 'injecting' a processor which throws a unchecked
> exception; the ErrorHandlerTest does do this but only with custom routes...
>
> any ideas?
>
> Peter
>
>
>
>
>
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) >>>>> >
Re: Composed Message Processor
2009/4/19 Frank Schwarz : > > Hi, > > I am trying to realize a composed message processor - without luck so far. > > The messages get perfectly split, but I am not sure, how to realize the > aggregation later on. > > Is there any built-in correlation criteria for the aggregation? > > The documentation (http://camel.apache.org/splitter.html) says: > CamelSplitIndex: Camel 2.0: A split counter that increases for each Exchange > being split. The counter starts from 0. > > How shall I read this line? > (a) For each composed message that is split, every item (that results from > the split) gets the _same_ value for the header "CamelSplitIndex". For the > next composed message to be split, this counter is increased by 1. > (b) For each split item from a composed message the header "CamelSplitIndex" > is increased by 1. With every new composed message to be split, this counter > start from 0. > > I understand the documentation as (a) but what I observe is (b). > > What is the correct reading? What is the intended behavior? Intended behavior and the implemented one is (b) > If (b), why does the splitter not insert a correlation header for the > aggregation later on? There is no correlation header, because if you want to aggregate split messages back, then splitter has a built in aggregator, that simply aggregates parts that it sent - there is no reason for additional correlation id when it knows identities of those exchanges. Of course it means that splitter works in in-out mode and you provided aggregation strategy. Of course you can provide your own correlation id for some future aggregation of those messages, but this is your choice, so you provide your own way of correlation. Camel doesn't force you to aggregate things the same way as they were split. For details of usage refer to http://svn.apache.org/repos/asf/camel/trunk/camel-core/src/test/java/org/apache/camel/processor/SplitterTest.java I hope my explanation helps a little, Roman
Re: Payload Gets Nulled Out
2009/4/18 Claus Ibsen : > We could add boolean hasOut() as a method on the Exchange. > Then you can test whether an OUT has been set or not. > > even though getOut(false) does exactly that. Returning null if no OUT exists. This is not my point, that there is no clear way of verifying if there is out or not. There is one you described. The problem (I believe) is in the way getOut() method works. The majority of developers assume, that getter (and getOut() conforms to JavaBean getter) will not modify anything in a way that can seriously influence future behavior. In the case of getOut() an invocation of this method can change the flow VERY significantly (in pipeline when there is no OUT). Only this possible misunderstanding is my concern (and believe me - I found a lot of cases when it happened to fresh camel riders) Roman
Re: thoughts on the method names for the requestBody and requestBodyAndHeader etc
Hello Claus, You asked for thoughts, so here they are ;) 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? 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: Payload Gets Nulled Out
Hello,
Just a quick note here. People usually get confused by what happens in
getOut() method. Sometimes people just want to check if out message
simply exists and they call getOut(). What happens is out message
being created that is not what usually happens with methods that
conform to JavaBeans convention.
Maybe we should try to fix it before 2.0 finally comes out? I've seen
a lot of such errors already simply because Camel don't stick to
convention. It is easy to avoid it by looking into javadoc or source,
bu... who does it really before trying ;) ?
Romek
2009/4/18 Claus Ibsen :
> Hi
>
> Or just set the header on the IN body.
>
> So the rule of thumb with the pipeline is basically as Willem writes.
> If OUT != null then use OUT otherwise use IN.
>
> So if you just need to alter/set a single header on the payload then
> you can just do it on IN and it will keep all the other data.
> If you set something on OUT then you are starting from scratch and
> must copy/set all the values you want to keep.
>
>
> On Sat, Apr 18, 2009 at 6:33 AM, Willem Jiang wrote:
>> Hi,
>>
>> Please keep in mind, if you are using pipeline message pattern,
>> the pipeline processor will copy the in message to the in message of
>> the next processor's exchange if there is no out message. But if you set the
>> out
>> message to the exchange, the pipeline processor will copy the out message
>> into the in message of next processor's exchange.
>> You may need to change the processor() like this
>> ...
>> process(new Processor() {
>> public void process(Exchange exchange) throws Exception {
>> ...
>> exchange.getOut().setHeader("foo", "bar")
>> exchange.getOut().setBody(exchange.getIn().getBody);
>> ...
>> }
>> }).to("seda:next");
>>
>>
>> Willem
>>
>> On Sat, Apr 18, 2009 at 4:35 AM, Joe Fernandez <
>> joe.fernan...@ttmsolutions.com> wrote:
>>
>>>
>>> Hello Camel Riders,
>>>
>>> I implemented a simple pipeline message pattern and ran across a situation
>>> where I would lose the body of my inbound message as it got forwarded from
>>> one processor to the next. In other words, the exchange.getIn().getBody()
>>> method would return null. I finally narrowed it down to the
>>> exchange.getOut().setHeader() method, which I have listed below. If I
>>> comment out that line, the next processor can get the inbound body. Why
>>> would setting a header in the outbound message affect the inbound message?
>>> Am I doing something wrong?
>>>
>>> ...
>>> process(new Processor() {
>>> public void process(Exchange exchange) throws Exception {
>>> ...
>>> exchange.getOut().setHeader("foo", "bar");
>>> ...
>>> }
>>> }).to("seda:next");
>>>
>>> Thanks,
>>> Joe
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Payload-Gets-Nulled-Out-tp23105477p23105477.html
>>> Sent from the Camel - Users (activemq) 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
>
Re: Camel transactions with in-out JMS
Hey Claus!
Yes - I've seen it. This is the flag that allows you to do something I
already described - it allows you to turn transactions off for in-out
"jms:splited" so you are able to actually send anything. Without this option
it doesn't work at all. With this option requests are not transactional, so
you can have duplicates if original request is rolled back and redelivered.
Roman
2009/4/8 Claus Ibsen
> Hi
>
> Just a quick reply.
>
> There is a trasactedInOut URI option for the JMS component. Have you
> looked at it?
>
>
> On Tue, Apr 7, 2009 at 6:29 PM, Roman Kalukiewicz
> wrote:
> > Hello Camel Riders!
> >
> > Let me show an example of a problem I'm working on:
> >
> > from("jms:in-queue").split(xpath("/foos/*"),
> > myAggregator).parallelProcessing().to("jms:splited");
> >
> > (this is not created with IDE, so might be worng but I hope you get the
> > idea).
> >
> > If this flow works as in-out and is transactional then it will not work
> as
> > messages are not sent to "jms:splitted" before transaction from
> > "jms:in-queue" is commited and it is not commited before response from
> > splitter is not sent back. It just hungs up.
> >
> > One solution is to make "jms:splited" non-transactional, but then we
> agree,
> > that we can have duplicates on "jms:splited" queue (we sent few messages
> > already, something fails, transaction is rolled back, we consume it once
> > again and we resend parts, that were already sent to "splited").
> >
> > I believe the proper behaviour would be to have two separate transactions
> > here:
> > * first transaction covers receive operation from in-queue, split and
> > sending requests to jms:splited and is commited when all requests to
> > 'jms:splitted' are sent
> > * second transaction covers all receive operations from jms:splited,
> > aggregation and sending a response to jms:in-queue. Is commited when
> final
> > response is sent.
> >
> > This way we are 100% transactional and nothing can be lost and nothing
> can
> > be duplicated.
> >
> > Right now I don't believe it is possible in camel. Moreover I cannot find
> a
> > way to clearly abstract the problem so it can be unified over other
> > components (not only JMS).
> > I believe the problem is, that we try to model JMS (that is by its nature
> > in-only especially when it comes to transactions) as in-out. If we model
> it
> > as two separate in-only flows with splitter and agregator it would work
> > fine, but then we don't have a way to listen only for our responses and
> to
> > receive all responses in the same transaction.
> >
> > Maybe some of you have any thoughts on this problem?
> >
> > Cheers
> > Roman Kalukiewicz
> >
>
>
>
> --
> 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
>
Camel transactions with in-out JMS
Hello Camel Riders!
Let me show an example of a problem I'm working on:
from("jms:in-queue").split(xpath("/foos/*"),
myAggregator).parallelProcessing().to("jms:splited");
(this is not created with IDE, so might be worng but I hope you get the
idea).
If this flow works as in-out and is transactional then it will not work as
messages are not sent to "jms:splitted" before transaction from
"jms:in-queue" is commited and it is not commited before response from
splitter is not sent back. It just hungs up.
One solution is to make "jms:splited" non-transactional, but then we agree,
that we can have duplicates on "jms:splited" queue (we sent few messages
already, something fails, transaction is rolled back, we consume it once
again and we resend parts, that were already sent to "splited").
I believe the proper behaviour would be to have two separate transactions
here:
* first transaction covers receive operation from in-queue, split and
sending requests to jms:splited and is commited when all requests to
'jms:splitted' are sent
* second transaction covers all receive operations from jms:splited,
aggregation and sending a response to jms:in-queue. Is commited when final
response is sent.
This way we are 100% transactional and nothing can be lost and nothing can
be duplicated.
Right now I don't believe it is possible in camel. Moreover I cannot find a
way to clearly abstract the problem so it can be unified over other
components (not only JMS).
I believe the problem is, that we try to model JMS (that is by its nature
in-only especially when it comes to transactions) as in-out. If we model it
as two separate in-only flows with splitter and agregator it would work
fine, but then we don't have a way to listen only for our responses and to
receive all responses in the same transaction.
Maybe some of you have any thoughts on this problem?
Cheers
Roman Kalukiewicz
Re: Combination of filters
2009/2/25 david_geary : > > Hi, > > I'm using an xpath filter in the xml configuration eg > > > //cs:case/@queue="13" > > > > What's the easiest way to combine filters eg I want to accept it if its on > queue 13 OR 14 (or if on queue 13 AND some other attribute is a particular > value?) > > I know I can set up separate filters and chain them to get 'AND' logic or > achieve 'OR' logic by putting the results onto the same seda queue say but > is there an easier general way to do this with the or xml > syntax? There is org.apache.camel.builder.PredicateBuilder class that has helper methods that allows you to nicely combine Predicates. Unfortunately it helps with Java DSL only.
Re: understanding SEDA and Thread processor
2009/2/3 huntc : > > I think that what you're looking for is something akin to the > "concurrentConsumers" parameter for a JMS endpoint. > My recommendation is to raise a JIRA request for an enhancement so that the > SEDA endpoint can receive a concurrentConsumers parameter. After all seems > to me that using SEDA is a poor-mans JMS endpoint. I even created such a JIRA: https://issues.apache.org/activemq/browse/CAMEL-1297 In fact it is almost done, but I have to access a box that I was working on to commit this thing ;) Roman
Re: sql component with no parameters
Thanks for pointing it out! I created a JIRA for this problem already and I'm going to have it fixed ASAP. https://issues.apache.org/activemq/browse/CAMEL-1283 Roman 2009/1/21 nojonojo > > From observing behavior and looking at the code of SqlProducer, it doesn't > seem like it's possible to use a query with no binding parameters (and thus > no body) with the SQL component. Is this true, or is there something that > I'm missing? > -- > View this message in context: > http://www.nabble.com/sql-component-with-no-parameters-tp21591819s22882p21591819.html > Sent from the Camel - Users mailing list archive at Nabble.com. > >
