-
Notifications
You must be signed in to change notification settings - Fork 626
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
two problems with receiving-batch #1474
Comments
See spring-projects#1474 (Does not resolve because 2 issues are reported there). `BatchingStrategy` was not set by container factory.
See spring-projects#1474 (Does not resolve because 2 issues are reported there). `BatchingStrategy` was not set by container factory. **cherry-pick to 2.4.x**
See spring-projects#1474 (Does not resolve because 2 issues are reported there). `BatchingStrategy` was not set by container factory. **cherry-pick to 2.4.x**
We will fix both but, bear in mind that the |
Resolves spring-projects#1474 When consuming the whole debatched batch as a list, all messages had the `lastInBatch` property set to true. Clone the message properties for the last record. **cherry-pick to 2.4.x**
See #1474 (Does not resolve because 2 issues are reported there). `BatchingStrategy` was not set by container factory. **cherry-pick to 2.4.x**
See #1474 (Does not resolve because 2 issues are reported there). `BatchingStrategy` was not set by container factory. **cherry-pick to 2.4.x**
Resolves #1474 When consuming the whole debatched batch as a list, all messages had the `lastInBatch` property set to true. Clone the message properties for the last record. **cherry-pick to 2.4.x**
@garyrussell I also agree with you about lastInBatch at first. Until I did not set BatchingStrategy during testing, only set other batch parameters. @Bean(name = "myBatchContainerFactory")
public SimpleRabbitListenerContainerFactory consumerBatchContainerFactory(SimpleBatchingStrategy batchingStrategy, ConnectionFactory connectionFactory) {
SimpleRabbitListenerContainerFactory factory = new SimpleRabbitListenerContainerFactory();
// {
// @Override
// public SimpleMessageListenerContainer createListenerContainer(RabbitListenerEndpoint endpoint) {
// SimpleMessageListenerContainer instance = super.createListenerContainer(endpoint);
// if (endpoint != null) {
// JavaUtils.INSTANCE.acceptIfNotNull(batchingStrategy, instance::setBatchingStrategy);
// }
// return instance;
// }
// };
//factory.setBatchingStrategy(batchingStrategy);
factory.setConnectionFactory(connectionFactory);
factory.setBatchListener(true);
factory.setConsumerBatchEnabled(true);
factory.setAcknowledgeMode(AcknowledgeMode.MANUAL);
factory.setBatchSize(4);
factory.setReceiveTimeout(5000L);
factory.setMessageConverter(new Jackson2JsonMessageConverter());
return factory;
} The sender parameters are still the same as the above example. After sending a dozen messages, the queue data is as follows. However, when receiving and processing, it is found that the data of the same list contains multiple deliverTags. If you just respond with ack at the end of the list, then there is still an error. Therefore, I only considered to judge together with lastInBatch.
|
Ok; thanks - both problems are fixed in 2.4.7-SNAPSHOT if you want to try it out. |
In what version(s) of Spring AMQP are you seeing this issue?
spring-rabbit-2.4.6
Describe the bug
I need to use batch send and batch receive.
When messages sent in batches are de-batch, the SimpleBatchingStrategy.deBatch() method shares the same instance of MessageProperties when processing AmqpHeaders.LAST_IN_BATCH, resulting in all messages in the batch becoming amqp_lastInBatch=true.
When SimpleRabbitListenerContainerFactory generates an instance, the batch strategy is only set to the endpoint, but not to the instance, so the default strategy is still used when batching: new SimpleBatchingStrategy(0, 0, 0L)
To Reproduce
Expected behavior
I provide override code samples at the end.
Sample
import dependencies
java :
bind
RabbitBatchConfig.java
RabbitConstant.java
user
producer
consumer
Attempt to deliver 5 messages and report the following error. Double ack due to bug in AmqpHeaders.LAST_IN_BATCH.
After tracing, I override the createListenerContainer() and deBatch() methods, and send 5 messages again, the test is correct.
RabbitBatchConfig
log
The text was updated successfully, but these errors were encountered: