Kafka equivalent to HttpRequest's `@RequestScope`

[hrothwell]

Feature description

We have the ability to make a @RequestScope bean in Micronaut which ties a bean to the current HttpRequest the server is executing on, would it be possible to do something similar for a Kafka message/batch of messages/etc?

[graemerocher]

probably, would require implementing a custom scope and binding the scope to a thread. Could probably use AbstractConcurrentCustomScope

[hrothwell]

I'll do some digging on it at some point this week if I get time, thanks for the lead as to where to look

[hrothwell]

I did spend some time today digging through this with mostly more questions than answers (wip branch for reference) , but to document some notes / ideas / findings / etc about it:

• My initial use case was to have a simple POJO bean for holding a value that was either constantly recalculated or passed through dozens of function calls. Usually this is something like the current date time at the time the whole chain started, where if you recalculate it you can sometimes cross into a new day, which can throw off any calculations that might care about what day it is.
• What I was envisioning was something similar to the RequestScope beans (we have used these in apis for this same purpose), but as I was going through I found myself focusing more on trying to merge the ideas of ThreadLocal and Refreshable
  • Each consumer instance might need its own instance of this bean. This bean would also need to refresh just before processRecords, in the use case described above this would have to pause execution until said refreshing was completed and before calling to process
  • because of the need for this type of refreshing, I started taking a look more at Refreshable and thinking if there was possibly some other solution other than a new custom scope. The one idea I had and something that potentially has the use outside of just this example: Allowing for the refreshing of speciic beans before a particular method is called. Something like a @Refreshes(beans = {BeanTypeToRefresh.class}, qualifiers = {/* maybe qualifiers could also be applied in the case of multiple beans of said types */}) method annotation.
  • to maybe then simplify the initial use case, you could just annotate your consumer's entrypoint with @Refreshes.
  • One other benefit to this and one of the issues I was considering that brought me here: perhaps most of the app logic is shared by both a consumer and an HTTP endpoint, in which case you would want both to trigger this bean to update. However, maybe that leads back to the needing to be bound to whatever thread is executing... Hadn't gotten that far in thinking about it until I started typing this out 🤔

[hrothwell]

random weekend brain thoughts that I am putting down to not forget:

could it be ThreadLocal but then also have a "refresh" function on the bean that is called every poll loop?