Hi Marcus, 1 Yes, let's limit it to InOnly exchanges.
2 Agreed, add an optional aggregation strategy, but keep List<Exchange> as the default, like the camel-kafka batch consumer. 3 I don't think that reusing the Camel aggregator might work. AggregateReifier always creates a dedicated single-thread "Aggregator" executor when parallelProcessing=false (the comment is literally "executor service is mandatory for the Aggregator"), and AggregateProcessor.onSubmitCompletion always dispatches through executorService.execute(...), so a completed group is never processed on the consumer thread, and session.commit() would run on a thread that doesn't own the session. Better to handle it in sjms itself with a pull-loop container that stops calling consumer.receive(...) once batchSize/batchTimeout is reached, dispatches the batch to the route synchronously, and commits or rolls back the same session on the same thread. Most of it already exists: SimpleMessageListenerContainer gives you the connection, session and recovery handling (two reply containers already subclass it), so the new part is really the receive loop and the batch/commit logic. camel-kafka had to build its own consumer loop and commit manager from scratch because there's no shared abstraction in Camel for this yet. If you want to contribute, you can request a JIRA account following https://camel.apache.org/community/support/ (be specific about the reason, e.g. mention this feature). CAMEL-16039 already covers this, but it's from 2021 and predates the design we've settled on, if you want I can update the issue to reflect this discussion. If you want to open a PR you can already do that, no need for the JIRA account, just reference CAMEL-16039: ... in the title. Greetings, Federico Il giorno mer 16 set 2026 alle ore 19:27 Marcus Ionker <[email protected]> ha scritto: > Hello Federico, > > I absolutely agree with your proposal. Thanks for your feedback. It makes > more sense than an additional batch component. > > I looked a the code, based on your proposal, even without the optional > aggregationStrategy, I think I would need to > > - develop a new batch EndpointMessageListener > - develop a new batch SimpleMessageListenerContainer > - update the SjmsEndpoint which creates the consumer > > I was wondering if at I should limit batch to an InOnly exchange? > > Adding an optional aggregationStrategy eg to only add the message body > cast to a custom class to a list would be useful. > > After looking at the code again, I was wondering if I could simply develop > listener and container that do not automatically commit or rollback at the > end of the unitOfWork. Then I could consume each message in a regular > aggregationStrategy and commit when the aggregationStrategy is completed > and the result processed. > > I do not currently have write access to the Apache Camel Jira. Regardless, > let me see what I can put together, and if I am confident in the result, > then I can consider a proper submission. I will save my „updated“ SJMS > component in my GitHub repo. > > Best Regards, > Marcus
