Closed ddossot closed 9 years ago
To be honest I wasn't aware that this is needed - which calls are broken and in which environment (programming language?)
This is language agnostic.
If you call GetQueueAttribute, there's no value associated with QueueArn
in ElasticMQ. If you do the same with SQS, you get a value.
The QueueArn
is the unique identifier for the queue: we use this value in logging statement, in monitoring and, even more importantly, when subscribing to SNS
.
Ah I see. Yeah this makes sense of course :) Maybe you'd like to try a pull request? Probably would involve changing https://github.com/adamw/elasticmq/blob/master/rest/rest-sqs/src/main/scala/org/elasticmq/rest/sqs/QueueAttributesDirectives.scala, if no other SQS calls are affected.
No change needed to core, right? Just create this attribute on the fly based on queueData.name
should do the trick, is that what you have in mind?
And sure, I could try a PR.
Yes, creating this on the fly should be good, core most certainly will be unaffected.
0.8.6 released. Thanks!
It would be great if each queue could have an associated
QueueArn
attribute: that would be ElasticMQ behave more like SQS, allowing code run the same way whether using one or the other as a back-end.