我有一个要求读1读，然后在我的Amazon SQS队列的所有消息的排序是基于创建时间戳和业务逻辑就可以了。

要确保所有的SQS主机被检查的消息，我启用了长轮询。我这样做的方法是设置默认的等待时间为队列为10秒。 （任何值大于0将启用长轮询）。

然而，当我试图读取队列，但它仍然没有给我所有的消息，我不得不做多次读取，让所有的消息。我甚至通过启用每个接收请求，code长轮询，仍然没有工作。下面是code我使用。

  AmazonSQSClient sqsClient =新AmazonSQSClient（新ClasspathPropertiesFileCredentialsProvider（））;
sqsClient.setEndpoint（sqs.us-west-1.amazonaws.com）;
字符串queueUrl =htt​​ps://sqs.us-west-1.amazonaws.com/12345/queueName;
。ReceiveMessageRequest receiveRequest =新ReceiveMessageRequest（）withQueueUrl（queueUrl）.withMaxNumberOfMessages（10）.withWaitTimeSeconds（20）;
名单＆LT;消息＆GT;消息= sqsClient.receiveMessage（receiveRequest）.getMessages（）;
 

我在队列中3消息，我每次运行code时，我得到了不同的结果，有时我得到的所有3消息，有时仅仅是1可见性超时我设置为2秒，只是为了消除消息成为无形的，作为没有看到他们在读的原因。 这是短轮询预期的行为。长轮询是应该消除多个民意调查。难道有什么我做错了什么？

感谢

长轮询是应该消除多个投票

没有，长轮询是应该淘汰一大批空投票和虚假的空应答时messsages实际可用。长轮询的SQS不会坐，等待的等待时间只是在寻找更多的东西返回，或继续寻找，一旦它发现了一些东西的最大金额。长轮询的SQS只等待足够长的时间来发现的的东西的：

＆ldquo; 长轮询允许亚马逊SQS服务要等到一个消息队列中可以发送一个响应之前。所以，除非连接超时，的响应ReceiveMessage请求将包含至少一个可用的消息（如果有的话），并达到在ReceiveMessage调用请求的最大数量 ＆rdquo;

＆mdash; http://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-long-polling.html （强调）的

因此​​，在＆ldquo;东西＆rdquo;的的那SQS找到并返回可以是所有的消息（最多的最多），或消息的子集，因为，如已经提到的，SQS是一个分布式系统。有可能是尽快一旦我们发现了一些回报和搜索整个系统的一切可能高达消息的客户端将接受的最大数量......，鉴于所成的架构决策这些替代品，它似乎是合理的，大多数应用程序将preFER的更快的响应给我尽你所能，尽可能快地就可以了。

您不知道，你实际上已经耗尽一个队列，直到你回来从一个长轮询一个空的响应。

I have a requirement to read all messages in my Amazon SQS queue in 1 read and then sort it based on created timestamp and do business logic on it.

To make sure all the SQS hosts are checked for messages, I enabled long polling. The way I did that was to set the default wait time for the queue as 10 seconds. (Any value more than 0 will enable long polling).

However when I tried to read the queue, it still did not give me all the messages and I had to do multiple reads to get all the messages. I even enabled long polling through code per receive request, still did not work. Below is the code I am using.

AmazonSQSClient sqsClient = new AmazonSQSClient(new ClasspathPropertiesFileCredentialsProvider());
sqsClient.setEndpoint("sqs.us-west-1.amazonaws.com");
String queueUrl = "https://sqs.us-west-1.amazonaws.com/12345/queueName";
ReceiveMessageRequest receiveRequest = new ReceiveMessageRequest().withQueueUrl(queueUrl).withMaxNumberOfMessages(10).withWaitTimeSeconds(20);
List<Message> messages = sqsClient.receiveMessage(receiveRequest).getMessages();

I have 3 messages in the queue and each time I run the code I get a different result, sometimes I get all 3 messages, sometimes just 1. The visibility timeout I set as 2 seconds, just to eliminate the messages becoming invisible as the reason for not seeing them in the read. This is the expected behavior for short polling. Long polling is supposed to eliminate multiple polls. Is there anything I am doing wrong here?

Thanks

Long polling is supposed to eliminate multiple polls

No, long polling is supposed to eliminate a large number of empty polls and false empty responses when messsages are actually available. A long poll in SQS won't sit and wait for the maximum amount of wait time just looking for more things to return, or keep searching once it's found something. A long poll in SQS only waits long enough to find something:

“Long polling allows the Amazon SQS service to wait until a message is available in the queue before sending a response. So unless the connection times out, the response to the ReceiveMessage request will contain at least one of the available messages (if any) and up to the maximum number requested in the ReceiveMessage call.”

— http://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-long-polling.html (emphasis added)

So, the “something” that SQS finds and returns may be all of the messages (up to your max), or a subset of the messages, because, as has been mentioned, SQS is a distributed system. There was likely an architectural decision to be made between "return as quickly as possible once we've found something" and "search the entire system for everything possible up to the maximum number of message the client will accept" ... and, given those alternatives, it seems reasonable that most applications would prefer the faster response of "give me whatever you can, as quickly as you can."

You don't know that you've actually drained a queue until you get back an empty response from a long poll.