RabbitMQ通过websocket Stomp：无法检索排队的消息
我正在使用RabbitMQ Stomp的耐用订阅（文档在这里 ）。 根据文档，当客户重新连接（订阅）相同的ID，他应该得到所有排队的消息。 但是，即使消息在服务器端排队，我也无法取回任何东西。 以下是我正在使用的代码：
RabbitMQ版本：3.6.0
客户代码：
var sock; var stomp; var messageCount = 0; var stompConnect = function() { sock = new SockJS(options.url); stomp = Stomp.over(sock); stomp.connect({}, function(frame) { debug('Connected: ', frame); console.log(frame); var id = stomp.subscribe('<url>' + options.source + "." + options.type + "." + options.id, function(d) { console.log(messageCount); messageCount = messageCount + 1; }, {'auto-delete' : false, 'persistent' : true , 'id' : 'unique_id', 'ack' : 'client'}); }, function(err) { console.log(err); debug('error', err, err.stack); setTimeout(stompConnect, 10); }); }; 服务器代码：
public class WebSocketConfig extends AbstractWebSocketMessageBrokerConfigurer { @Override public void configureMessageBroker(final MessageBrokerRegistry config) { config.enableStompBrokerRelay("<endpoint>", "<endpoint>").setRelayHost(host) .setSystemLogin(username).setSystemPasscode(password).setClientLogin(username) .setClientPasscode(password); } @Override public void registerStompEndpoints(final StompEndpointRegistry registry) { registry.addEndpoint("<endpoint>").setAllowedOrigins("*").withSockJS(); } }
我正在执行的步骤：
- 在客户端运行脚本，发送订阅请求。
- 在服务器端创build一个队列（名字为stomp-subscription- *），所有消息都被压入队列中，客户端可以对这些消息进行stream式处理。
- 杀死脚本，这导致断开连接。 服务器日志显示客户端已断开，消息开始排队。
- 再次使用相同的ID运行脚本。 它以某种方式设法连接到服务器，但是，没有消息从服务器返回。 该队列上的消息计数保持不变（另外，RabbitMQpipe理控制台不显示该队列的任何使用者）。
- 10秒后，连接将被丢弃，并在客户端日志中打印以下内容：
哎呦！ 与<url>失去连接
- 服务器也显示相同的消息（即客户端断开连接）。 如客户端代码所示，它会在10秒后尝试build立连接，然后再次重复相同的循环。
我已经尝试了以下的东西：
- 删除
'ack' : 'client'标题。 这导致所有的消息被排除在队列之外，但是没有到达客户端。 经过这个答案之后，我添加了这个头文件。 - 增加了
d.ack();在函数中，在递增messageCount之前。 这会导致服务器端发生错误，因为它会在会话closures后（由于断开连接）尝试确认消息。
此外，在某些情况下，当我重新连接排队消息的数量less于100，我能够得到所有的消息。 但是，一旦超过100，就没有任何反应（不确定这是否与问题有关）。
我不知道问题是否存在于服务器或客户端。 任何投入？
最后，我能够find（并解决）这个问题。 我们使用nginx作为代理，并将proxy_buffering设置为on （默认值），看看这里的文档。
这就是它说的：
当启用缓冲时，nginx会尽快从代理服务器接收响应，并将其保存到由proxy_buffer_size和proxy_buffers指令设置的缓冲区中。
由于这个原因，消息被缓冲（延迟），导致断开连接。 我们尝试绕过nginx，它工作正常，然后我们禁用代理缓冲，现在似乎工作正常，即使与nginx代理。