Is this library deprecated?

[flauschie]

There haven't been any recent updates, and in ticket #395 there's the statement that there'll be no active work on supporting Spring Boot 3.

We've forked the code for patching a few aspects that were impractical for our purposes but we won't really go down the rabbit hole and maintain the library - our org is just not big enough for this.

Thus for our planning - is the library effectively considered deprecated now?

Thanks

[JaidenAshmore]

I wouldn't say it is fully deprecated as I am happy to do bug and security fixes, however I don't work with SQS at my job anymore so I am not as invested in doing active feature work on this unless it looked like an interesting challenge. The Spring Boot 3 response was more an attempt to get others to contribute back if they wanted changes. I looked at the upgrade yesterday and it wasn't that difficult to implement so I released a new version (6.0.0) supporting Spring Boot 3.

I agree that it is healthy for you weigh up the risk of this library (open source, solo dev) and the dev time to implement it yourself against the functionality that you would gain from it. There may also be more modern implementations of SQS listeners that have come out in the last few years that might be lower risk for you. I haven't investigated the market in a while so I don't have any recommendations but if you find some I am happy for you to update this issue to point people to other implementations that they can explore.

[flauschie]

Thanks for all your efforts, Jaiden!

We all have our constraints so fully understood.

Your library has some value props that are pretty nice, really.
The other day I implemented consumer capacity breathing (scaling at runtime), which doesn't seem to be supported by other libraries.

As far as I can tell, Spring Cloud SQS is still unusable for anything but basic use cases - and after all these years, it still doesn't support custom attributes. Performance-wise, it was also ... well ... but I haven't verified this aspect lately.

I implemented a fallback approach using Apache Camel SQS2, which seems decent - albeit concurrency changes at runtime aren't supported.

So far, your library has worked flawlessly for us ... except for a little issue upon shutdown.

FWIW, this line here always waits until the timeout hits, despite all related threads being terminated at the time.
The pool itself reports 1 thread remaining in active state but there is nothing running really.

CoreMessageListenerContainer.stop(...):

final boolean isTerminated = executorService.awaitTermination(shutdownTimeLimitInSeconds, SECONDS);

Not a super drama, though.