hello,please answer my questions ？
when i use axon-kafka-4.0-RC3, Configuration group id invaild, i want to fixed group id,
It’s not fixed group id.
like this:Axon.Streamable.Consumer-153a129e-ac3b-43db-9110-5bcc84b64999
The properties on paths axon.kafka, axon.kafka.consumer and axon.kafka.producer resemble key-value pairs. So from an implementation perspective, you are looking at a Map. Due to this, the keys aren’t known up front so are no described through javadoc either.
Know that the properties folders are intended to provide any Kafka specific configuration which are not opened up through distinct keys.
The groupId property you are mentioning has however been removed for quite sometime know, which required me to dig in a little too. I tracked it towards this commit message. So more specifically, there is no means to define a default groupId anymore, as the structure of the extension has changed.
Right now the implementation will need to provide the groupId when setting up the consumer (as specified in this) commit message. From your end this means you will need to provide the groupId when you create the message source for an Event Processor. How this is done, can be found in the Reference Guide on this page.
By the way, we introduced this breaking change as the Kafka Extension has no seen a final release yet (as specified with RC, Release Candidate). I am not anticipating any major breaking changes for the following release though.
Trusting this helps you out sufficiently @Vinson!
Cheers,
Steven
Are there any examples? The documentation is not very readable
The extension-kafka has an example app inside it, check it out.
If any portion of the documentation is unclear, providing suggested adjustments would be more than welcome actually. You can simply draft up an issue, favorably a pull request actually, over here.
When drafting that page we felt everything was provided sufficiently enough.
However apparently you’ve found some missing pointers here, so your insights would be much appreciated on the matter too. Hope to see a PR from you soon @Vinson 
First of all, thanks for your help. 
Use this framework for the first time, It’s hard to avoid some confusion, hope you will understand.
One more question. Help me out.
Query side multi server consumer kafka message,How to code and set?Is the subscribing mode ?how？
application.properties:
axon.eventhandling.processors.kafka-group.mode=subscribing
axon.kafka.client-id=@axon.kafka.client-id@
axon.kafka.default-topic=@axon.kafka.default-topic@
axon.kafka.consumer.bootstrap-servers=@axon.kafka.consumer.bootstrap-servers@
axon.kafka.consumer.event-processor-mode=subscribing
axon.kafka.consumer.auto-offset-reset=earliest
axon.distributed.enabled=true
If you want to merge several Kafka Streams as the message source inside Axon, you are inclined to use the following:
- The
StreamableKafkaMessageSourceas provided by Axon’s Kafka Extension - The
MultiStreamableMessageSourceas contained in Axon Framework.
You will have to define all your StreamableKafkaMessageSource by hand in this case, as the auto-configuration only expects a single Kafka source. Once all these are in place, you can combine them in the MultiStreamableMessageSource. The Builder paradigm provides by the MultiStreamableMessageSource should be clear enough on how to construct it.
Then lastly, you can use the MultiStreamableMessageSource as the message source for your TrackingEventProcessor.
I would like to point out though that simply ingesting events from several sources into your main application is considered not to be a best practice. Instead you’d want to perform some context mapping, so not to pollute your system with the “language” the other application speak. In essence, you’d be constructing an Anti-Corruption Layer in this case.
Whether this is what you’re after, is however unclear at the moment. If you’re simply looking to distribute your basic application using all Axon’s messaging ideas, I’d recommend giving Axon Server a spin. It simplifies the process greatly, as you no longer have to maintain N-or-so separate Kafka streams, alongside other infrastructure components to distribute commands, queries and the event store.