[RESULT][VOTE] Release Apache Camel Kamelets 4.2.0
Hello all, The vote passes with the following result: 5 +1 binding votes: Andrea Cosentino, Zineb Bendhiba, Babak Vahdat, Claus Ibsen and Otavio Rodolfo Piske Thanks to all the voters. I'll go ahead with the process. Cheers.
Re: Jetty Component how to add additional steps after send http response back to the client
Dear Claus lbsen, Thanks so much for your suggestions, I will try both. Thanks again for your kind help. Have a nice day. :) From: Claus Ibsen Sent: Sunday, November 19, 2023 3:36:23 AM To: users@camel.apache.org Subject: Re: Jetty Component how to add additional steps after send http response back to the client Hi I would also add that HTTP servers like Tomcat, Jetty, JBoss etc have an access log that logs how long time each request takes. And they often have a API / plugin you can use to have your custom code triggered by the HTTP server so you can do any kind of "how long time it takes" you need. On Sat, Nov 18, 2023 at 8:34 PM Claus Ibsen wrote: > Hi > > Camel will send back the response at the end of the route in the consumer, > so what you do in that route example will not work. > However if you want to do some kind of custom logging of how long it > takes, then Camel Jetty has send back the response to the client, when the > UnitOfWork is done. > So you can use Camel's UoW done to do any custom code for "backend > response timestamp ...". > > See the docs for UnitOfWork or its also covered in the CiA2 book. > > > > On Tue, Nov 14, 2023 at 5:11 AM Han Yainsun wrote: > >> Dear Camel Community and Camel users, >> >> Greetings to you! >> >> Camel version: 3.20.4 >> Spring Boot version: 2.7.11 >> JDK: Amazon Corretto 17 >> Platform: Windows server 2019 >> IDE: IntelliJ IDEA 2021.3.2 (Community Edition) >> >> I have an requirement that need calculate each message process time, >> incould total process time and backend process time. the route likes below, >> it seems that the jetty managed the http session and send the response >> back to client automatically at the end of route. >> >> Is it possible to explicitly inform jetty send the resonse at specific >> point? >> >> Thansk in advance. >> >> from("jetty:http://0.0.0.0:8080/test";) >> .process(exchange -> exchange.setProperty("inbound timestamp", >> System.currentTimeMillis())) >> .to("http://localhost/mockbackend";) >> .process(exchange -> exchange.setProperty("backend respond timestamp", >> System.currentTimeMillis())) >> .setBody(constant("hello")) >> // I expect jetty send response back to client here. >> .process(exchange -> exchange.setProperty("backend respond timestamp", >> System.currentTimeMillis())); >> >> > > -- > Claus Ibsen > - > @davsclaus > Camel in Action 2: https://www.manning.com/ibsen2 > -- Claus Ibsen - @davsclaus Camel in Action 2: https://www.manning.com/ibsen2
Re: aggregate EIP: wrong correlation key set for aggregate exchanges
This appears to be a bug. The attached test case is failing at line #95 The issue appears to be around the following line of code: onCompletion(batchKey, originalExchange, batchAnswer, false, aggregateFailed); https://github.com/apache/camel/blob/cd5c790e18f00288d1ac62aca909efb99a7a4846/core/camel-core-processor/src/main/java/org/apache/camel/processor/aggregate/AggregateProcessor.java#L633 This is called for all the correlation keys with the same originalExchange. The method onCompletion sets the property CamelAggregatedCorrelationKey on originalMessage. So originalMessage is left with the last update for this key. orginalMessage is (appears to be) the stored aggregate for the current message that triggered completion. It does not appear to have a reason to be associated with other keys. On Monday, 20 November, 2023 at 11:01:15 am GST, Dinu Pavithran wrote: I am seeing wrong correlation key is set for the first exchange emitted from aggregate EIP. In the log below, Exchange[7F40FFF506AA26C-000D] is aggregating with correlation key: batch-1, but when this exchange is emitted, the property CamelAggregatedCorrelationKey is set as batch-4 I saw the same result with Camel v 4.2.0 run using camel-jbang and Camel v 3.18.4 using camel-main started from Groovy or Java I also saw the same result when using different aggregation strategies. Is there something wrong with the way I have configured the EIP? --- zip-files-2.yaml --- - route: id: zip-files from: uri: file:{{indir}} parameters: sort-by: reverse:file:modified #last modified will be the first pre-sort: true recursive: true max-depth: 3 min-depth: 3 antInclude: batches/** antExclude: '*/processing-*/*' include-ext: csv repeatCount: 1 synchronous: true steps: - setHeader: name: Batch simple: ${header.CamelFileParent.replaceFirst('{{inDir}}/batches/','')} - aggregate: correlation-expression: header: Batch aggregation-strategy: '#class:org.apache.camel.processor.aggregate.zipfile.ZipAggregationStrategy' completion-from-batch-consumer: true eager-check-completion: true #simplified - setHeader: name: LatestBatch constant: batch-4 - setHeader: name: RunID constant: 20231120063433118 - setHeader: name: Batch exchangeProperty: CamelAggregatedCorrelationKey - log: loggingLevel: debug message: Processing batch ${headers.Batch} from exchange ${exchangeId} - filter: simple: ${headers.LatestBatch} == ${headers.Batch} steps: # for tracing - to: file:{{indir}}/{{sentDir}}?file-name=Processing-${header.RunID}-${header.Batch}.zip - log: Wrote ${headers.Batch} to ${header.CamelFileNameProduced} - log: Send ${headers.Batch} --- tree {{indir}}/batches -- in ├── batches │ ├── batch-1 │ │ ├── events.csv │ │ └── users.csv │ ├── batch-2 │ │ ├── events.csv │ │ └── users.csv │ ├── batch-3 │ │ ├── events.csv │ │ └── users.csv │ ├── batch-4 │ │ ├── events.csv │ │ └── users.csv │ └── processing-batch-5 │ ├── events.csv │ └── users.csv -- log --- 06:34:29.845 INFO [ main] mel.main.MainSupport : Apache Camel (JBang) 4.2.0 is starting 06:34:30.061 INFO [ main] mel.main.MainSupport : Using Java 17.0.8.1 with PID 481790. Started by vscode in /home/vscode/camel 06:34:30.956 INFO [ main] main.BaseMainSupport : Auto-configuration summary 06:34:30.956 INFO [ main] main.BaseMainSupport : [application.properties] camel.main.durationMaxIdleSeconds=1 06:34:30.956 INFO [ main] main.BaseMainSupport : [application.properties] camel.main.shutdownTimeout=5 06:34:30.957 INFO [ main] main.BaseMainSupport : [application.properties] camel.server.enabled=false 06:34:30.957 INFO [ main] main.BaseMainSupport : [application.properties] camel.server.healthCheckEnabled=true 06:34:30.957 INFO [ main] main.BaseMainSupport : [application.properties] camel.server.devConsoleEnabled=true 06:34:30.958 INFO [ main] main.BaseMainSupport : [application.properties] camel.health.enabled=false 06:34:30.958 INFO [ main] main.BaseMainSupport : [application.properties] camel.health.exposureLevel=full 06:34:31.364 INFO [ main] or.LocalCliConnector : Camel CLI enabled (local) 06:34:31.744 INFO [ main] AbstractCamelContext : Apache Camel 4.2.0 (zip-files-2) is starting 06:34:31.915 INFO [ main] e.AggregateProcessor : Defaulting to MemoryAggregationRepository 06:34:32.058 INFO [ main] main.BaseMainSupport : Property-placeholders summary 06:34:32.058 INFO [ main]
Event / Exchange / Message timestamps
In Camel 3.20.8 I use the event notifier (as described here https://dzone.com/articles/event-notifier-apache-camel). One of the things I try to get timestamps. These timestamps are available on several levels: 1. Event level 2. Exchange level 3. Message level When I used the following the get the timestamps: CamelEvent.ExchangeEvent exchangeEvent = (CamelEvent.ExchangeEvent) event; // Get the message exchange from exchange event Exchange exchange = exchangeEvent.getExchange(); System.out.println("Timestamp 1 " + event.getTimestamp()); System.out.println("Timestamp 2 " + exchangeEvent.getTimestamp()); System.out.println("Timestamp 3 " + exchange.getCreated()); System.out.println("Timestamp 4 " + exchange.getIn().getMessageTimestamp()); Only timestamp 3 (exchange.getCreated()) gives a timestamp, but the others are 0. For message timestamps this can be correct (as that depends on ActiveMQ etc), but shouldn't the event always a timestamp? Raymond
Re: StreamCaching and File component doesn't work as expected
Hello.! I think that I've found an explanation of this behavior that is probably not a bug. Our code that fails because of the unreadable content is called by an ExchangeSentEvent handler. After debugging this code, setting a breakpoint on the StreamCache reset method, I see that the stream is reset later by a "StreamCachingAdice.after" operation, and not just after the endpoint (file) has produced its output. This explains why during my event handler the cached content seems to be unreadable. In my case, calling reset on the StreamCache instance seems to fix the issue. I hope this can help someone else... Regards. Le ven. 17 nov. 2023 à 16:29, Ephemeris Lappis a écrit : > > Hello. > > We've some kind of random behavior on routes that use stream caching, > with the default configuration. All our routes are executed using > blueprints in Karaf. The same error happens on old Camel 2.x on Fuse > and Camel 3.21.x on Karaf 4.x. > > In some cases the previous body is the result of a JAXB marshalling. > Some other cases use other data formats (BeanIO for example). Anyway, > the same behavior. > > Debugging the code it seems that if the produced file is rather small, > the body after writing the file is converted into an InputStreamCache. > In these cases, the "pos" attribute of the InputStream is equal to the > "count" value, and any conversion to string leads to an empty string. > This seems logical. Still debugging, if I reset "pos" to "mark" (0 in > our cases), the next string conversion is correct. > > Is this resetting expected to be done by the file producer after > writing the file ? > > When files are bigger, I can't identify the exact class of the body > that my debugger refuses to print (the display appears as a list of > blocks). In these cases, we have never had any string conversion > issue. > > Any idea of the cause of this behavior ? > > Thanks for your help. > > Regards.
[ANNOUNCE] Apache Camel 4.0.3 (LTS) Release
The Camel PMC is pleased to announce the release of Apache Camel 4.0.3. Apache Camel is an open source integration framework that empowers you to quickly and easily integrate various systems consuming or producing data. This is a patch release with 23 improvements and fixes. For more details please take a look at the release notes at: https://camel.apache.org/releases/release-4.0.3/
Re: Event / Exchange / Message timestamps
Hi No see the javadoc You need to turn on event timestamps On Mon, Nov 20, 2023 at 4:32 PM ski n wrote: > In Camel 3.20.8 I use the event notifier (as described here > https://dzone.com/articles/event-notifier-apache-camel). > > One of the things I try to get timestamps. These timestamps are available > on several levels: > > 1. Event level > 2. Exchange level > 3. Message level > > When I used the following the get the timestamps: > > CamelEvent.ExchangeEvent exchangeEvent = (CamelEvent.ExchangeEvent) event; > > // Get the message exchange from exchange event > Exchange exchange = exchangeEvent.getExchange(); > > System.out.println("Timestamp 1 " + event.getTimestamp()); > System.out.println("Timestamp 2 " + exchangeEvent.getTimestamp()); > System.out.println("Timestamp 3 " + exchange.getCreated()); > System.out.println("Timestamp 4 " + > exchange.getIn().getMessageTimestamp()); > > > Only timestamp 3 (exchange.getCreated()) gives a timestamp, but the others > are 0. For message timestamps this can be correct (as that depends on > ActiveMQ etc), but shouldn't the event always a timestamp? > > Raymond > -- Claus Ibsen - @davsclaus Camel in Action 2: https://www.manning.com/ibsen2
Re: Event / Exchange / Message timestamps
Yes, I was suspecting something like that, but the Javadoc only says: "Timestamp for each event, when the event occurred. By default, the timestamp is not included and this method returns 0." It does not say how and where it can be turned on. I first checked the EventNotifierSupport class, but apparently it needs to be set on the EventFactory: https://www.javadoc.io/static/org.apache.camel/camel-api/3.20.8/org/apache/camel/spi/EventFactory.html#setTimestampEnabled(boolean) Something like: context.getManagementStrategy().getEventFactory().setTimestampEnabled(true); Hope this will help someone. Raymond