THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
| Code Block | ||||
|---|---|---|---|---|
| ||||
public Consumer {
...
/**
* Manually assign a list of partitions with specific key ranges to this consumer. If a partition maps to an empty list,
* that means a full ownership of the partition.
*/
void assign(Map<TopicPartition, List<Tuple<int64, int64>>> partitionWithKeyRanges);
} |
New Configurations
Broker configs
fetched.data.max.wait.ms | The maximum amount of time in ms that the fetch manager will wait un Default is 604800000 (7 days). This allows periodic weekly producer jobs to maintain their ids. |
max.transaction.timeout.ms | The maximum allowed timeout for transactions. If a client’s requested transaction time exceed this, then the broker will return a InvalidTransactionTimeout error in InitPidRequest. This prevents a client from too large of a timeout, which can stall consumers reading from topics included in the transaction. Default is 900000 (15 min). This is a conservative upper bound on the period of time a transaction of messages will need to be sent. |
| transaction.state.log.replication.factor | The number of replicas for the transaction state topic. Default: 3 |
| transaction.state.log.num.partitions | The number of partitions for the transaction state topic. Default: 50 |
Consumer configs
The maximum amount of time in ms that the fetch manager will wait un Default is 604800000 (7 days). This allows periodic weekly producer jobs to maintain their ids. | |
| transaction.state.log.replication.factor | The number of replicas for the transaction state topic. Default: 3 |
Related Work
Pulsar has officially supported key share feature in 2.4, which suggests multiple consumers could share the same partition data.
...