Skip to content

JMS 1.1 and AWS SQS SimpleQueueService#359

Draft
adamretter wants to merge 5 commits intofp-in-bo:mainfrom
evolvedbinary:aws-sqs
Draft

JMS 1.1 and AWS SQS SimpleQueueService#359
adamretter wants to merge 5 commits intofp-in-bo:mainfrom
evolvedbinary:aws-sqs

Conversation

@adamretter
Copy link
Copy Markdown
Contributor

I wanted to add support for an AWS SQS (Simple Queue Service) provider to jms4s.

Unfortunately the AWS SQS driver only implements some of the JMS 1.1 API, whereas jms4s was using the JMS 2.0 API. This led to a number of issues:

  1. Firstly I downgraded jms4s from JMS 2.0 to JMS 1.1 (which seems to work fine with IBM MQ and Apache MQ Artemis). The he main piece of work here was implementing a stand-in for javax.jms.JMSContext that is available in JMS 2.0, but not JMS 1.1. I decided to take this approach as jms4s makes heavy use of JMSContext. This was actually relatively easy to achieve.

  2. I commented out any methods that used JMS send with delay, as the 1.1 API does not support send with delay.

  3. I added an AWS SQS provider and test suite. As a stand-in for integration testing against AWS SQS, I selected ElasticMQ as it provides an SQS compatible API.

  4. I had to separate some of the test cases into separate traits as SQS supports Queues, but does NOT support Topics. Likewise SQS does not support local transactions for JMS.

Finally all tests pass currently against IBM MQ, Apache MQ Artemis, and ElasticMQ.

Downgrading from JMS 2.0 to 1.1 seems to have had little impact on jms4s (apart from removing send with delay functionality), It would be ideal if we could find a way to have jms4s support both JMS 1.1 and 2.0 but I am not sure what such an approach would look like... I would be very interested to discuss such an approach with the authors or jms4s ASAP.

@faustin0
Copy link
Copy Markdown
Contributor

Hi @adamretter, thanks for exploring the feasability of supporting jms 1.1.
However, removing a public API (the send with delay) is a breaking changes and this functionality is currently used in many of our projects as a retry mechanism.
I'm thinking about some other ways to support both specifications, i have an idea but i need to do some testing and check if it may works.

@adamretter
Copy link
Copy Markdown
Contributor Author

@faustin0 Understood about the API change, and thanks for the feedback. I look forward to hearing more after your testing...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants