Re: Camel Routes throws TimeOutException after ESB restart
Thanks much. I was breaking my head to identify the issue Is there a defect that I can refer to? Wanted to know the reason why this is happening? Few follow on questions to do the workaround- 'You can use a fixed reply to queue to work around this issue.'- We are using temporary queue to have the request response (InOut). If we use a fixed queue, when there are multiple requests going through, will it not clash? Or will it work using the correlationId? Also where do I specify to use a fixed queue instead of temporary queue? -- View this message in context: http://camel.465427.n5.nabble.com/Camel-Routes-throws-TimeOutException-after-ESB-restart-tp3229609p3229918.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Camel Routes throws TimeOutException after ESB restart
On Thu, Oct 21, 2010 at 8:31 AM, Viju vvbiju2...@gmail.com wrote: Thanks much. I was breaking my head to identify the issue Is there a defect that I can refer to? Wanted to know the reason why this is happening? See https://issues.apache.org/activemq/browse/CAMEL-3193 Few follow on questions to do the workaround- 'You can use a fixed reply to queue to work around this issue.'- We are using temporary queue to have the request response (InOut). If we use a fixed queue, when there are multiple requests going through, will it not clash? Or will it work using the correlationId? Also where do I specify to use a fixed queue instead of temporary queue? You can either use a shared reply queue or use a reply queue per endpoint. Camel will filter based on correlation id. You use use replyTo option http://camel.apache.org/jms -- View this message in context: http://camel.465427.n5.nabble.com/Camel-Routes-throws-TimeOutException-after-ESB-restart-tp3229609p3229918.html Sent from the Camel - Users mailing list archive at Nabble.com. -- Claus Ibsen Apache Camel Committer Author of Camel in Action: http://www.manning.com/ibsen/ Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus
Re: JMS filtering based on selector
Check the unit tests of camel-jms to see some samples. On Thu, Oct 21, 2010 at 7:22 AM, Norman nor...@apache.org wrote: Hi there, you need to pass the = as %3D as stated in the component docs. See: http://camel.apache.org/jms.html So it would be: from(activemq:queue:somequeue?selector=clientid %3D 'someid').to(someOtherQueue) Bye, Norman Am 20.10.2010 22:19, schrieb Hossein: Hello, Using camel 2.2, I'm attempting to select only certain messages from queue using the following: from(activemq:queue:somequeue?selector=clientid='someid').to(someOtherQueue) where clientid was set using: exchange.getOut().setHeader(clientid, someid) Is above correct? For some reason, I don't get the filtered message and the result is camel return ALL messages of the initial queue? Thanks. --- Hossein Amerkashi -- Claus Ibsen Apache Camel Committer Author of Camel in Action: http://www.manning.com/ibsen/ Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus
Re: issue moving files to ftp
On Wed, Oct 20, 2010 at 11:21 PM, Gustavo Franke
franke.gust...@gmail.com wrote:
Based on your suggestion I've wrote this
from(FTPS_ENDPOINT
+?password=gustavomove=processed?localWorkDirectory=+ localWorkFolder)
.beanRef(parser, convert)
.to(FTPS_ENDPOINT
+/out?password=gustavofileName=${file:onlyname})
;
but for some reason the localWorkDirectory doesn't seems to be working (I
don't see the files copied in there).
and I'm getting a FileNotFoundException (in the FTP side) and the file is
there.
Do I need more detailed info besides http://camel.apache.org/ftp2 ?
At first just try to get the file downloaded.
Then later add that 2nd step to upload the file again.
And where do you get that exception?
Thanks,
Gustavo.
On Tue, Oct 19, 2010 at 8:23 AM, Claus Ibsen claus.ib...@gmail.com wrote:
The FTP component supports a local work folder directly.
See the localWorkDirectory option
http://camel.apache.org/ftp2
Then you can do
from(ftp:xxx?localWorkDirectory=/somepath).beanRef(parser,
convert).xxx?
On Mon, Oct 18, 2010 at 11:56 PM, Gustavo Franke
franke.gust...@gmail.com wrote:
Here's what I have in my RouteBuilder
public void configure() {
String localWorkFolder = /tmp/camel;
from(ftp://gustavo
@localhost:21/Test?password=gustavomove=.processed).to(file://
+ localWorkFolder);
from(file:// + localWorkFolder + ?noop=true).beanRef(parser,
convert);
from(file:///tmp/camelout).to(ftp://gustavo
@localhost:21/Test/out?password=gustavofileName=${file:onlyname});
}
I'm not sure if I am missing some thing but on the java app side the
files
are generated properly, those files should be copied to the ftp.
But for some reason, on the ftp side the files are generated but its
content
is missing or corrupt, and I'm completely clueless regarding to this.
If I don't explicit the fileName=${file:onlyname} I get this error
Error
writing file [Test/out/C:\tmp\camel\myFile.txt] being Test/out the
remote
folder and C:\tmp\camel\myFile.txt path of the file. That's the reason
why I
added the fileName=${file:onlyname} but I don't know why the content is
missing.
Any help would be great.
Thanks,
Gustavo
--
Claus Ibsen
Apache Camel Committer
Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
--
Claus Ibsen
Apache Camel Committer
Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
[Camel-exec] dynamic parameters in Spring DSL
Hello,
I am using Camel version 2.4 for the new Camel-exec component.
I would like to ask your opinion on this potential improvement for the usage
of this component with Spring DSL. To use dynamic parameters the
CamelExecCommandArgs header has to be set with a Java List object.
This of course requires Java code to create (simple of course, but still).
Would it not more user friendly if it a String could be given instead/also ?
In that case a separator would be necessary but I guess a blank space could
be the default value.
This way instead of doing
setHeader headerName=execArgs
constantarg1,arg2,arg3/constant
/setHeader
setHeader headerName=CamelExecCommandArgs
method bean=helper method=parseArgs/
/setHeader
bean id=helper class=CamelExecHelper
property name=argsHeader value=execArgs /
property name=argsSeparator value=, / !-- optional --
/bean
This could be writtent
!-- optional --
setHeader headerName=CamelExecCommandArgs
constant,/constant
/setHeader
setHeader headerName=CamelExecCommandArgs
simplearg1,arg2,arg3/simple !-- of course simple offers
many more advance possibilities --
/setHeader
The bean code is very simple indeed but is required
public ListString parseArgs(@Header(field) String argsHeader){
ListString args = new ArrayListString();
args.addAll(Arrays.asList(argsHeader.split(argsSeparator)));
return args;
}
But maybe I am not seeing an easier way already applicable with the current
version. In that case, please tell me.
--
View this message in context:
http://camel.465427.n5.nabble.com/Camel-exec-dynamic-parameters-in-Spring-DSL-tp3230040p3230040.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Camel CXF Producers And Timeout Configuration
Hi,
I also need to set a timeout for my route. Did you find out how this can be
done ?
My route fowards a call to an importer, it might take some time for the
response to come...
any tips ?
!-- VerizonImportService 8420 --
route
from
uri=cxf://http://service-test1.test:8420/rating-bus/verizonImport?wsdlURL=http://service-test1.test:8380/destination-server/verizonImport#63;wsdlamp;serviceName={http://www.tc.nl/nl.tc.rating.destination-service}VerizonDestinationImportServiceamp;portName={http://www.tc.nl/nl.tc.rating.destination-service}VerizonDestinationImporterImplPortamp;dataFormat=MESSAGE;
/
to
uri=cxf://http://service-test1.test:8380/destination-server/verizonImport?wsdlURL=http://service-test1.test:8380/destination-server/verizonImport#63;wsdlamp;serviceName={http://www.tc.nl/nl.tc.rating.destination-service}VerizonDestinationImportServiceamp;portName={http://www.tc.nl/nl.tc.rating.destination-service}VerizonDestinationImporterImplPortamp;dataFormat=MESSAGE;
/
/route
--
View this message in context:
http://camel.465427.n5.nabble.com/Camel-CXF-Producers-And-Timeout-Configuration-tp477973p3230048.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: [Camel-exec] dynamic parameters in Spring DSL
Hi Olivier,
It can be interesting, yes.
Could you raise an improvement Jira ?
Regards
JB
On 10/21/2010 10:24 AM, Olivier.Roger wrote:
Hello,
I am using Camel version 2.4 for the new Camel-exec component.
I would like to ask your opinion on this potential improvement for the usage
of this component with Spring DSL. To use dynamic parameters the
CamelExecCommandArgs header has to be set with a Java List object.
This of course requires Java code to create (simple of course, but still).
Would it not more user friendly if it a String could be given instead/also ?
In that case a separator would be necessary but I guess a blank space could
be the default value.
This way instead of doing
setHeader headerName=execArgs
constantarg1,arg2,arg3/constant
/setHeader
setHeader headerName=CamelExecCommandArgs
method bean=helper method=parseArgs/
/setHeader
bean id=helper class=CamelExecHelper
property name=argsHeader value=execArgs /
property name=argsSeparator value=, / !-- optional --
/bean
This could be writtent
!-- optional --
setHeader headerName=CamelExecCommandArgs
constant,/constant
/setHeader
setHeader headerName=CamelExecCommandArgs
simplearg1,arg2,arg3/simple !-- of course simple offers
many more advance possibilities --
/setHeader
The bean code is very simple indeed but is required
public ListString parseArgs(@Header(field) String argsHeader){
ListString args = new ArrayListString();
args.addAll(Arrays.asList(argsHeader.split(argsSeparator)));
return args;
}
But maybe I am not seeing an easier way already applicable with the current
version. In that case, please tell me.
Re: [Camel-exec] dynamic parameters in Spring DSL
Sure, I just created https://issues.apache.org/activemq/browse/CAMEL-3263 CAMEL-3263 -- View this message in context: http://camel.465427.n5.nabble.com/Camel-exec-dynamic-parameters-in-Spring-DSL-tp3230040p3230061.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: [Camel-exec] dynamic parameters in Spring DSL
Thanks Olivier, I'm gonna work on it as I'm making some change on the camel-exec component. Regards JB On 10/21/2010 10:36 AM, Olivier.Roger wrote: Sure, I just created https://issues.apache.org/activemq/browse/CAMEL-3263 CAMEL-3263
Re: Camel CXF Producers And Timeout Configuration
I also tried following, but this throws exceptions:
2010-10-21 11:40:34,150 [WARN ] DefaultManagementLifecycleStrategy - Could
not unregister service:
Consumer[http://service-test1.test:8420/rating-bus/verizonImportTest] as
Service MBean.
javax.management.InstanceNotFoundException:
org.apache.camel:context=service-test1/camelContext,type=consumers,name=CxfConsumer(0x2eb6fb)
2010-10-21 11:40:34,157 [WARN ] DefaultManagementLifecycleStrategy - Could
not unregister service:
sendTo(Endpoint[http://service-test1.test:8380/destination-server/verizonImport])
as Service MBean.
javax.management.InstanceNotFoundException:
org.apache.camel:context=service-test1/camelContext,type=processors,name=SendProcessor(0x169c398)
org.apache.camel.FailedToCreateProducerException: Failed to create Producer
for endpoint:
Endpoint[http://service-test1.test:8380/destination-server/verizonImport].
Reason: java.lang.NullPointerException
cxf:cxfEndpoint
id=importerEndpoint
serviceName=myservice:VerizonDestinationImportService
address=http://service-test1.test:8380/destination-server/verizonImport;
wsdlURL=http://service-test1.test:8380/destination-server/verizonImport?wsdl;
cxf:properties
beans:entry key=portName
value=VerizonDestinationImporterImplPort/
beans:entry key=dataFormat value=MESSAGE/
beans:entry key=receiveTimeout value=12/
beans:entry key=connectionTimeout value=12/
/cxf:properties
/cxf:cxfEndpoint
camelContext
id=camelContext
xmlns=http://camel.apache.org/schema/spring;
xmlns:lookupservice=http://www.tc.nl/nl.tc.rating.destination-service;
xmlns:soap=http://schemas.xmlsoap.org/wsdl/soap/;
xmlns:tns=http://www.tc.nl/nl.tc.rating.destination-service;
xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/;
xmlns:xsd=http://www.w3.org/2001/XMLSchema;
trace=true
autoStartup=true
route
from
uri=cxf://http://service-test1.test:8420/rating-bus/verizonImportTest?wsdlURL=http://service-test1.test:8380/destination-server/verizonImport#63;wsdlamp;serviceName={http://www.tc.nl/nl.tc.rating.destination-service}VerizonDestinationImportServiceamp;portName={http://www.tc.nl/nl.tc.rating.destination-service}VerizonDestinationImporterImplPortamp;dataFormat=MESSAGE;
/
to uri=cxf:bean:importerEndpoint /
/route
--
View this message in context:
http://camel.465427.n5.nabble.com/Camel-CXF-Producers-And-Timeout-Configuration-tp477973p3230161.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: AW: AW: AW: Calling Soapservices using SoapDataFormat
Hallo Christian You guessed right in case of jms and file ! Thanks for your additional hints. We have to rethink about this issue. Best Regards Fitzgerald -- View this message in context: http://camel.465427.n5.nabble.com/Calling-Soapservices-using-SoapDataFormat-tp3228535p3230186.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: [Camel-exec] dynamic parameters in Spring DSL
Hello Oliver,
some functionality that could help you already exist in the Camel exec
component.
To use the component conveniently, you can use the args endpoint
argument with whitespace separator, as described in the documentation
http://camel.apache.org/exec.html.
You can not however achieve everything with the current implementation of
the argument parsing, for example the parsing has no support for nested
symbols. The implementation of the commons-exec library, that is the
default implementation used by the component,, does not provide a perfect
argument parsing algorithm that can be reused as well.
I personally prefer and use the list argument, because my code is less
error-prone when someone else, who has not read the component
documentation, decides to change and/or add an argument.
Regards,
Mitko
From:
Olivier.Roger olivier.ro...@bsb.com
To:
users@camel.apache.org
Date:
21.10.2010 10:24
Subject:
[Camel-exec] dynamic parameters in Spring DSL
Hello,
I am using Camel version 2.4 for the new Camel-exec component.
I would like to ask your opinion on this potential improvement for the
usage
of this component with Spring DSL. To use dynamic parameters the
CamelExecCommandArgs header has to be set with a Java List object.
This of course requires Java code to create (simple of course, but still).
Would it not more user friendly if it a String could be given instead/also
?
In that case a separator would be necessary but I guess a blank space
could
be the default value.
This way instead of doing
setHeader headerName=execArgs
constantarg1,arg2,arg3/constant
/setHeader
setHeader headerName=CamelExecCommandArgs
method bean=helper method=parseArgs/
/setHeader
bean id=helper class=CamelExecHelper
property name=argsHeader value=execArgs /
property name=argsSeparator value=, / !-- optional --
/bean
This could be writtent
!-- optional --
setHeader headerName=CamelExecCommandArgs
constant,/constant
/setHeader
setHeader headerName=CamelExecCommandArgs
simplearg1,arg2,arg3/simple !-- of course simple
offers
many more advance possibilities --
/setHeader
The bean code is very simple indeed but is required
public ListString parseArgs(@Header(field) String argsHeader){
ListString args = new ArrayListString();
args.addAll(Arrays.asList(argsHeader.split(argsSeparator)));
return args;
}
But maybe I am not seeing an easier way already applicable with the
current
version. In that case, please tell me.
--
View this message in context:
http://camel.465427.n5.nabble.com/Camel-exec-dynamic-parameters-in-Spring-DSL-tp3230040p3230040.html
Sent from the Camel - Users mailing list archive at Nabble.com.
InterComponentWare AG:
Vorstand: Peter Kirschbauer (Vors.), Jörg Stadler
Aufsichtsratsvors.: Prof. Dr. Christof Hettich
Firmensitz: 69190 Walldorf, Altrottstraße 31
AG Mannheim HRB 351761 / USt.-IdNr.: DE 198388516
Re: Camel CXF Producers And Timeout Configuration
On 10/21/10 6:04 PM, raymond wrote: Hi, thank you for responding. snapshot from my wsdl at: http://service-test1.test:8380/destination-server/verizonImport?wsdl wsdl:service name=VerizonDestinationImportService - wsdl:port binding=tns:VerizonDestinationImportServiceSoapBinding name=VerizonDestinationImporterImplPort soap:address location=http://service-test1.test:8380/destination-server/verizonImport/ /wsdl:port /wsdl:service snapshot camel context, seems the names are matching. Am I missing something here ? From stack trace , it looks like your cxf endpoint service name is wrong. Can you try to use the below configuration, and update the THE_TARGET_NAMESPACE_OF_YOUR_WSDL part with your wsdl target namespace ? cxf:cxfEndpoint id=importerEndpoint serviceName=myservice:VerizonDestinationImportService endpointName=myservice:VerizonDestinationImporterImplPort xmlns:myservice=THE_TARGET_NAMESPACE_OF_YOUR_WSDL address=http://service-test1.test:8380/destination-server/verizonImport; wsdlURL=http://service-test1.test:8380/destination-server/verizonImport?wsdl; cxf:properties beans:entry key=dataFormat value=MESSAGE/ beans:entry key=receiveTimeout value=12/ beans:entry key=connectionTimeout value=12/ /cxf:properties /cxf:cxfEndpoint -- Willem -- Open Source Integration: http://www.fusesource.com Blog:http://willemjiang.blogspot.com (English) http://jnn.javaeye.com (Chinese) Twitter: http://twitter.com/willemjiang
2 minor MINA bugs
First off, thanks for the work. The more I use Camel, the more I love it. Here are 2 'bugs' I have run across: 1. On the page http://camel.apache.org/mina.html, for the list of configuration parameters you list decorderMaxLineLength, this is a typo and should be decoderMaxLineLength. I copy and pasted the word into my code and took me a few minutes to find the problem. 2. Secondly, I am sending long lines of data to the Camel-MINA component and needed to increase the decoderMaxLineLength. Until I bumped the ActiveMQ log4j.properties file to ALL, I did not see the exception that stated the line was too long. Shouldn't this exception be logged as an error? If so I would have seen it sooner. IIRC right now the exception is logged as a DEBUG. Thank you, Mark
Re: 2 minor MINA bugs
On Thu, Oct 21, 2010 at 3:33 PM, Mark Webb elihusma...@gmail.com wrote: First off, thanks for the work. The more I use Camel, the more I love it. Here are 2 'bugs' I have run across: 1. On the page http://camel.apache.org/mina.html, for the list of configuration parameters you list decorderMaxLineLength, this is a typo and should be decoderMaxLineLength. I copy and pasted the word into my code and took me a few minutes to find the problem. Fixed the typo. 2. Secondly, I am sending long lines of data to the Camel-MINA component and needed to increase the decoderMaxLineLength. Until I bumped the ActiveMQ log4j.properties file to ALL, I did not see the exception that stated the line was too long. Shouldn't this exception be logged as an error? If so I would have seen it sooner. IIRC right now the exception is logged as a DEBUG. Can you post the stacktrace? Thank you, Mark -- Claus Ibsen Apache Camel Committer Author of Camel in Action: http://www.manning.com/ibsen/ Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus
Re: 2 minor MINA bugs
Here is the stack trace. It is a WARN, not DEBUG. Sorry about that. I cut out the Hexdump dump for brevity. WARN | [/127.0.0.1:53690] Unexpected exception from exceptionCaught handler. org.apache.camel.CamelException: org.apache.mina.filter.codec.ProtocolDecoderException: org.apache.mina.common.BufferDataException: Line is too long: 1973 (Hexdump: 5C 3D 0D 0A) at org.apache.camel.component.mina.MinaConsumer$ReceiveHandler.exceptionCaught(MinaConsumer.java:91) at org.apache.mina.common.support.AbstractIoFilterChain$TailFilter.exceptionCaught(AbstractIoFilterChain.java:564) at org.apache.mina.common.support.AbstractIoFilterChain.callNextExceptionCaught(AbstractIoFilterChain.java:345) at org.apache.mina.common.support.AbstractIoFilterChain.access$1000(AbstractIoFilterChain.java:53) at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.exceptionCaught(AbstractIoFilterChain.java:643) at org.apache.mina.filter.executor.ExecutorFilter.processEvent(ExecutorFilter.java:224) at org.apache.mina.filter.executor.ExecutorFilter$ProcessEventsRunnable.run(ExecutorFilter.java:264) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619) Caused by: org.apache.mina.filter.codec.ProtocolDecoderException: org.apache.mina.common.BufferDataException: Line is too long: 1973 (Hexdump: 5C 3D 0D 0A) at org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecFilter.java:165) at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(AbstractIoFilterChain.java:299) at org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoFilterChain.java:53) at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceived(AbstractIoFilterChain.java:648) at org.apache.mina.common.support.AbstractIoFilterChain$HeadFilter.messageReceived(AbstractIoFilterChain.java:499) at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(AbstractIoFilterChain.java:299) at org.apache.mina.common.support.AbstractIoFilterChain.fireMessageReceived(AbstractIoFilterChain.java:293) at org.apache.mina.transport.socket.nio.SocketIoProcessor.read(SocketIoProcessor.java:228) at org.apache.mina.transport.socket.nio.SocketIoProcessor.process(SocketIoProcessor.java:198) at org.apache.mina.transport.socket.nio.SocketIoProcessor.access$400(SocketIoProcessor.java:45) at org.apache.mina.transport.socket.nio.SocketIoProcessor$Worker.run(SocketIoProcessor.java:485) at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:51) ... 3 more Caused by: org.apache.mina.common.BufferDataException: Line is too long: 1973 at org.apache.mina.filter.codec.textline.TextLineDecoder.decodeAuto(TextLineDecoder.java:188) at org.apache.mina.filter.codec.textline.TextLineDecoder.decode(TextLineDecoder.java:112) at org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecFilter.java:158) ... 14 more On Thu, Oct 21, 2010 at 10:14 AM, Claus Ibsen claus.ib...@gmail.com wrote: On Thu, Oct 21, 2010 at 3:33 PM, Mark Webb elihusma...@gmail.com wrote: First off, thanks for the work. The more I use Camel, the more I love it. Here are 2 'bugs' I have run across: 1. On the page http://camel.apache.org/mina.html, for the list of configuration parameters you list decorderMaxLineLength, this is a typo and should be decoderMaxLineLength. I copy and pasted the word into my code and took me a few minutes to find the problem. Fixed the typo. 2. Secondly, I am sending long lines of data to the Camel-MINA component and needed to increase the decoderMaxLineLength. Until I bumped the ActiveMQ log4j.properties file to ALL, I did not see the exception that stated the line was too long. Shouldn't this exception be logged as an error? If so I would have seen it sooner. IIRC right now the exception is logged as a DEBUG. Can you post the stacktrace? Thank you, Mark -- Claus Ibsen Apache Camel Committer Author of Camel in Action: http://www.manning.com/ibsen/ Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus
Re: 2 minor MINA bugs
So are you saying that you dont notice the WARN? That is a really high level. On Thu, Oct 21, 2010 at 6:15 PM, Mark Webb elihusma...@gmail.com wrote: Here is the stack trace. It is a WARN, not DEBUG. Sorry about that. I cut out the Hexdump dump for brevity. WARN | [/127.0.0.1:53690] Unexpected exception from exceptionCaught handler. org.apache.camel.CamelException: org.apache.mina.filter.codec.ProtocolDecoderException: org.apache.mina.common.BufferDataException: Line is too long: 1973 (Hexdump: 5C 3D 0D 0A) at org.apache.camel.component.mina.MinaConsumer$ReceiveHandler.exceptionCaught(MinaConsumer.java:91) at org.apache.mina.common.support.AbstractIoFilterChain$TailFilter.exceptionCaught(AbstractIoFilterChain.java:564) at org.apache.mina.common.support.AbstractIoFilterChain.callNextExceptionCaught(AbstractIoFilterChain.java:345) at org.apache.mina.common.support.AbstractIoFilterChain.access$1000(AbstractIoFilterChain.java:53) at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.exceptionCaught(AbstractIoFilterChain.java:643) at org.apache.mina.filter.executor.ExecutorFilter.processEvent(ExecutorFilter.java:224) at org.apache.mina.filter.executor.ExecutorFilter$ProcessEventsRunnable.run(ExecutorFilter.java:264) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619) Caused by: org.apache.mina.filter.codec.ProtocolDecoderException: org.apache.mina.common.BufferDataException: Line is too long: 1973 (Hexdump: 5C 3D 0D 0A) at org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecFilter.java:165) at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(AbstractIoFilterChain.java:299) at org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoFilterChain.java:53) at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceived(AbstractIoFilterChain.java:648) at org.apache.mina.common.support.AbstractIoFilterChain$HeadFilter.messageReceived(AbstractIoFilterChain.java:499) at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(AbstractIoFilterChain.java:299) at org.apache.mina.common.support.AbstractIoFilterChain.fireMessageReceived(AbstractIoFilterChain.java:293) at org.apache.mina.transport.socket.nio.SocketIoProcessor.read(SocketIoProcessor.java:228) at org.apache.mina.transport.socket.nio.SocketIoProcessor.process(SocketIoProcessor.java:198) at org.apache.mina.transport.socket.nio.SocketIoProcessor.access$400(SocketIoProcessor.java:45) at org.apache.mina.transport.socket.nio.SocketIoProcessor$Worker.run(SocketIoProcessor.java:485) at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:51) ... 3 more Caused by: org.apache.mina.common.BufferDataException: Line is too long: 1973 at org.apache.mina.filter.codec.textline.TextLineDecoder.decodeAuto(TextLineDecoder.java:188) at org.apache.mina.filter.codec.textline.TextLineDecoder.decode(TextLineDecoder.java:112) at org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecFilter.java:158) ... 14 more On Thu, Oct 21, 2010 at 10:14 AM, Claus Ibsen claus.ib...@gmail.com wrote: On Thu, Oct 21, 2010 at 3:33 PM, Mark Webb elihusma...@gmail.com wrote: First off, thanks for the work. The more I use Camel, the more I love it. Here are 2 'bugs' I have run across: 1. On the page http://camel.apache.org/mina.html, for the list of configuration parameters you list decorderMaxLineLength, this is a typo and should be decoderMaxLineLength. I copy and pasted the word into my code and took me a few minutes to find the problem. Fixed the typo. 2. Secondly, I am sending long lines of data to the Camel-MINA component and needed to increase the decoderMaxLineLength. Until I bumped the ActiveMQ log4j.properties file to ALL, I did not see the exception that stated the line was too long. Shouldn't this exception be logged as an error? If so I would have seen it sooner. IIRC right now the exception is logged as a DEBUG. Can you post the stacktrace? Thank you, Mark -- Claus Ibsen Apache Camel Committer Author of Camel in Action: http://www.manning.com/ibsen/ Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus -- Claus Ibsen Apache Camel Committer Author of Camel in Action: http://www.manning.com/ibsen/ Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus
Re: Camel Routes throws TimeOutException after ESB restart
Hi, Looks like the issue you are facing relates to temporary queues which display different behaviors in different JMS implementations. The simple workaround as Claus pointed out is to use a named replyTo queue which is then persisted and outlives the recycling of the container/broker since it is cached automatically to persistent store. As for how to do this it can be added as a query parameter on the JMS URI as follows. jms:queue:foo?replyTo=bar Any responses to messages sent to queue foo will be sent to the queue called bar. Hope this helps. Cheers, Ashwin... - - Ashwin Karpe Apache Camel Committer Sr Principal Consultant FUSESource (a Progress Software Corporation subsidiary) http://fusesource.com http://fusesource.com Blog: http://opensourceknowledge.blogspot.com http://opensourceknowledge.blogspot.com - -- View this message in context: http://camel.465427.n5.nabble.com/Camel-Routes-throws-TimeOutException-after-ESB-restart-tp3229609p3231467.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Camel-jms with ActiveMQ: loosing messages by using non persistent messaging
Hello Willem, thanks for sharing this. Christian
Could camel support configurable interceptor strategy in spring?
Hi: Camel's Context support a low level API(CamelContext.addInterceptStrategy), which we could use it to add our custom interceptor-strategy in Java DSL program; But while using Spring DSL, it seems there is no such a configuration we can use to configure the custom interceptor-strategy; How about to add such a support? It may looks like as following: beans bean id=interceptorStrategyList class=org.apache.camel.InterceptorStrategyList camel:context ... /camel:context /beans The bean interceptorStrategyList support a method to return a list of custom interceptor strategy; And camel-spring could find the bean and register the interceptors into camelContext; Thanks any suggestion
Re: Could camel support configurable interceptor strategy in spring?
You can just add the InterceptorStrategies into the application, CamelContextFactoryBean will pick up these interceptorStrategies and set them into the camelContext. You can find the code in the afterPropertiesSet() method of AbstractCamelContextFactoryBean[1]. [1]https://svn.apache.org/repos/asf/camel/trunk/components/camel-core-xml/src/main/java/org/apache/camel/core/xml/AbstractCamelContextFactoryBean.java On 10/22/10 12:15 PM, ext2 wrote: Hi: Camel's Context support a low level API(CamelContext.addInterceptStrategy), which we could use it to add our custom interceptor-strategy in Java DSL program; But while using Spring DSL, it seems there is no such a configuration we can use to configure the custom interceptor-strategy; How about to add such a support? It may looks like as following: beans bean id=interceptorStrategyList class=org.apache.camel.InterceptorStrategyList camel:context ... /camel:context /beans The bean interceptorStrategyList support a method to return a list of custom interceptor strategy; And camel-spring could find the bean and register the interceptors into camelContext; Thanks any suggestion -- Willem -- Open Source Integration: http://www.fusesource.com Blog:http://willemjiang.blogspot.com (English) http://jnn.javaeye.com (Chinese) Twitter: http://twitter.com/willemjiang
Re: how to implement the instrumentation of from-endpoint?(Should camel to support the route level interceptor)
There is an InterceptFrom DSL[1] that can meet you requirement. [1]http://camel.apache.org/intercept.html#Intercept-InterceptFrom On 10/22/10 12:01 PM, ext2 wrote: Hi: Camel support interceptors for processor, but recently I encounter a requirement, it ask for a custom instrumentation strategy of from endpoint; for example , we need the statistics of how much times the message is successfully processed in a given time, and how much message is failed; I think we could have three choice to achieve such purpose. 1) Do instrument things, in the from-endpoint. it's bad, because it need to change the code of camel's consumer 2) Extend a policy processor to wrapper the whole route, and do measurement It seems the solution is too heavy. But the solution does works, and now I am using this solution in my work; 3) Support a route level interceptor (just like the processor's interceptor, but it will wrapper the whole route). It seems the solution is more lightweight than the policy-processor. How about to add such the support in camel? Thanks any suggestion -- Willem -- Open Source Integration: http://www.fusesource.com Blog:http://willemjiang.blogspot.com (English) http://jnn.javaeye.com (Chinese) Twitter: http://twitter.com/willemjiang
: Could camel support configurable interceptor strategy in spring?
Thanks a lot. I see; Camel could look up all the configured interceptor-strategies in spring application context. But unfortunately, it seems we couldn't control the wrap order of interceptor-strategies; On 2010/10/22 12:29 Willem Jiang Wrote Re: Could camel support configurable interceptor strategy in spring? You can just add the InterceptorStrategies into the application, CamelContextFactoryBean will pick up these interceptorStrategies and set them into the camelContext. You can find the code in the afterPropertiesSet() method of AbstractCamelContextFactoryBean[1]. [1]https://svn.apache.org/repos/asf/camel/trunk/components/camel-core-xml/sr c/main/java/org/apache/camel/core/xml/AbstractCamelContextFactoryBean.java On 10/22/10 12:15 PM, ext2 wrote: Hi: Camel's Context support a low level API(CamelContext.addInterceptStrategy), which we could use it to add our custom interceptor-strategy in Java DSL program; But while using Spring DSL, it seems there is no such a configuration we can use to configure the custom interceptor-strategy; How about to add such a support? It may looks like as following: beans bean id=interceptorStrategyList class=org.apache.camel.InterceptorStrategyList camel:context ... /camel:context /beans The bean interceptorStrategyList support a method to return a list of custom interceptor strategy; And camel-spring could find the bean and register the interceptors into camelContext; Thanks any suggestion -- Willem -- Open Source Integration: http://www.fusesource.com Blog:http://willemjiang.blogspot.com (English) http://jnn.javaeye.com (Chinese) Twitter: http://twitter.com/willemjiang
Re: Camel Routes throws TimeOutException after ESB restart
Thanks very much for the quick updates. I tried the same with a fixed queue and it works. -- View this message in context: http://camel.465427.n5.nabble.com/Camel-Routes-throws-TimeOutException-after-ESB-restart-tp3229609p3231764.html Sent from the Camel - Users mailing list archive at Nabble.com.
