Skip to content

Allow for setting TTL on a response sent by @JmsListener [SPR-13774] #18348

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

Closed
spring-projects-issues opened this issue Dec 8, 2015 · 4 comments
Assignees
Labels
in: messaging Issues in messaging modules (jms, messaging) status: backported An issue that has been backported to maintenance branches type: enhancement A general enhancement
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

spring-projects-issues commented Dec 8, 2015

Maciej Miklas opened SPR-13774 and commented

Currently AbstractAdaptableMessageListener#sendResponse(...) calls producer.send(response) which results with JMS Message without TTL.

We are using ActiveMQ with persistent messages, in order to avoid queue pollution we have to set TTL on every message.

One possibility to solve this issue is to introduce new annotation, like @ResponseTTL, or something more generic: @ResponseSetup

Other possibility would be to give us option to pragmatically configure MessageProducer.
The MessagingMessageListenerAdapter has already a suitable method: #postProcessProducer(), but currently it's impossible to register custom implementation.
The reason for that is that the class MethodJmsListenerEndpoint has factory method creating MessagingMessageListenerAdapter, but MethodJmsListenerEndpoint cannot be extended because JmsListenerAnnotationBeanPostProcessor creates its instance inside of #processJmsListener().
Actually it would be enough to create factory method on JmsListenerAnnotationBeanPostProcessor that would create instance of MethodJmsListenerEndpoint.


Affects: 4.1.8, 4.2.3

Issue Links:

Referenced from: commits d04f785, 9589749

Backported to: 4.1.9

@spring-projects-issues
Copy link
Collaborator Author

Juergen Hoeller commented

Good point, we should at least allow for extension through consistent availability of factory methods there. We'll address that right away for 4.2.4 and possibly 4.1.9 as well.

As for a first-class TTL setting, a per-listener annotation might be a bit overkill... That said, a "timeToLive" property on JmsListenerAnnotationBeanPostProcessor (and on the jms namespace / @EnableJms) might be a worthwhile compromise, possibly in conjunction with other QoS settings (a la JmsTemplate). This should rather be 4.3 though.

Juergen

@spring-projects-issues
Copy link
Collaborator Author

spring-projects-issues commented Dec 8, 2015

Maciej Miklas commented

Factory method is really welcome extension - thank you !

Setting default TTL on @EnableJms seams to be better idea than new annotation. Actually it should be sufficient for most use cases to set global TTL for all responses. Custom logic can be still implemented by configuring MessageProducer in #postProcessProducer(...) or by overwriting #sendResponse(....)

Maciej

@spring-projects-issues
Copy link
Collaborator Author

spring-projects-issues commented Dec 8, 2015

Juergen Hoeller commented

Alright, thanks for the feedback! We'll proceed with the factory method arrangement for 4.2.4 / 4.1.9 then and do the configurable approach for 4.3 (#18349).

Juergen

@spring-projects-issues
Copy link
Collaborator Author

Juergen Hoeller commented

I've added a corresponding createMethodJmsListenerEndpoint() method. To be backported to 4.1.9 tonight.

Juergen

@spring-projects-issues spring-projects-issues added in: messaging Issues in messaging modules (jms, messaging) status: backported An issue that has been backported to maintenance branches type: enhancement A general enhancement labels Jan 11, 2019
@spring-projects-issues spring-projects-issues added this to the 4.2.4 milestone Jan 11, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: messaging Issues in messaging modules (jms, messaging) status: backported An issue that has been backported to maintenance branches type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

2 participants