我想在订阅上设置pull请求的读取超时。现在唯一的选择是设置returnImmediately=true
或者等到pubsub返回,如果没有发布消息,这似乎是90秒。
我正在使用gcloud-node模块来调用pubsub。它使用引擎盖下的request模块来进行gcloud api调用。我已更新gcloud-node/lib/pubsub/subscription.js的本地副本,将请求超时设置为30秒
this.request({
method: 'POST',
uri: ':pull',
timeout: 30000,
json: {
returnImmediately: !!options.returnImmediately,
maxMessages: options.maxResults
}
}
当我这样做时,我看到的行为是30秒后连接将在客户端超时,但pubsub仍然打开请求。如果我有两个客户端拉动订阅并且其中一个客户端在30秒后超时,则会向该主题发布一条消息,剩下的侦听客户端将有50/50的机会检索该消息。
有一种方法可以在一段时间后告诉pubsub超时拉连接吗?
更新: 我可能需要澄清一下我的例子。我有两个客户端同时连接并从同一个订阅中获取。两者之间的唯一区别是第一个配置为在30秒后超时。由于两个客户端连接到同一个订阅,pubsub将在它们之间分配消息负载。如果我在两个客户端连接后45秒发布消息,则pubsub将有50/50的机会将消息传递给尚未超时的第二个客户端。如果我发送10条消息而不是仅发送一条消息,则第二条客户端将收到10条消息的子集。看起来这是因为我的客户进行了长时间的民意调查。如果客户端断开连接,则服务器不知道并将尝试发送已发布的消息,该消息是由已超时的客户端发出的请求的响应。根据我的测试,这是我观察到的行为。我想做的是能够在pull请求中发送一个超时参数,告诉subpub在30000ms之后发回一个响应,如果在此期间没有发布消息的话。阅读API docs,这似乎不是一种选择。
答案 0 :(得分:1)
设置请求超时是30秒后拉出超时的正确方法。取消请求的存在可能不是导致其他拉动不立即获取消息的原因。如果你的第二次拉动(没有超时)设法拉出之前发布的其他消息,它就不必等待在超时之后发布的其他消息在完成之前进入。它只保证不返回更多而不是maxMessages
,只有在确切地maxMessages
(如果有多个可用)时才返回。一旦你的发布完成,一些后来的pull将获得消息,但是不确定何时会发生这种消息。