skyscreamer / nevado

A JMS driver for Amazon SQS.

Home Page:http://nevado.skyscreamer.org/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

org.skyscreamer.nevado.jms.destination.TopicSubscriberTest#testTopics is failing

carterpage opened this issue · comments

The topic has been deleted, and during cleanup, the consumer close process is trying to unsubscribe from a non-existent topic. I think this used to be a nop from AWS and now throws a 500.

We can do one of the following:

  • Record deleted state in metadata and check it during unsubscribe (which can still throw an error if someone manually deletes a topic through the AWS console)
  • Swallow the exception (since it's a vague 500, probably not a good idea)
  • Check to see if the topic exists before unsubscribing (can be expensive because we have to walk through all topics)

So, two things are going on here that need to be fixed:

  1. The connection.close() operation is being aborted completely because of an exception in the middle. It would be better do do a best effort before abandoning all hope. We should still throw an exception, but after we've done all we can to close first. This will minimize uncleaned-up artifacts.
  2. Nevado deleted the topic. It should know that it is gone. In the code it is being recreated for each listener. We should share references to the state so that deleting it in one thread changes state in a way that is apparent to the other threads. This will require locking on that state too to ensure thread-safety.

I'll make a test that more explicitly checks for this, since it's only getting caught implicitly in cleanup.

Changing my mind on this. While close operations should still do everything they can to clean up, I think it's inappropriate for the close operation to exit smoothly if the topic is deleted from under it. Since this is for distributed applications, local clients should not have cleaner behavior than remote topics when a topic is deleted. The state is in SQS/SNS itself, not in Nevado.

Deleting a topic is not part of the JMS standard itself, so doing so causes undetermined behavior if there are outstanding consumers and producers. In this case, the correct action is to improve close() to be best-effort, and to fix the test to close consumers and producers before forcing the delete of a topic.

Fixed in #41