Java EC2上jgroups通道上的数据包丢失问题

当我们试图通过jgroups3.1.0在EC2（大型实例）上设置Infinispan时，我们看到了不一致的网络故障——最终运行在Amazon的64位LinuxAMI上。空缓存启动正常，并且似乎可以工作一段时间，但是一旦缓存已满，新服务器将同步，导致缓存锁定

我们决定滚动自己的缓存，但看到的行为大致相同。在同步过程中交换10兆字节，但它们不会被淹没。在应用程序级别有一个来回的data->ack对话，但看起来有些消息从未到达远程

在查看单播跟踪日志时，我看到了以下内容：

# my application starts a cache refresh operation 
01:02:12.003 [Incoming-1,mprewCache,i-f6a9d986] DEBUG c.m.e.q.c.l.DistributedMapManager - i-f6a9d986: from i-d2e29fa2: search:REFRESH 
01:02:12.003 [Incoming-1,mprewCache,i-f6a9d986] INFO  c.m.e.q.c.l.DistributedMapRequest - starting REFRESH from i-d2e29fa2 for map search, map-size 62373 
01:02:12.003 [Incoming-1,mprewCache,i-f6a9d986] DEBUG c.m.e.q.c.l.DistributedMapManager - i-f6a9d986: to i-d2e29fa2: search:PUT_MANY, 50 keyValues 
# transmits a block of 50 values to the remote but this never seems to get there 
01:02:12.004 [Incoming-1,mprewCache,i-f6a9d986] TRACE o.j.p.UNICAST - i-f6a9d986 --> DATA(i-d2e29fa2: #11, conn_id=10) 
# acks another window 
01:02:12.004 [Incoming-1,mprewCache,i-f6a9d986] TRACE o.j.p.UNICAST - i-f6a9d986 --> ACK(i-d2e29fa2: #4) 
# these XMITs happen for over and over until 01:30:40 
01:02:12.208 [Timer-2,mprewCache,i-f6a9d986] TRACE o.j.p.UNICAST - i-f6a9d986 --> XMIT(i-d2e29fa2: #6) 
01:02:12.209 [Timer-2,mprewCache,i-f6a9d986] TRACE o.j.p.UNICAST - i-f6a9d986 --> XMIT(i-d2e29fa2: #7) 
01:02:12.209 [Timer-2,mprewCache,i-f6a9d986] TRACE o.j.p.UNICAST - i-f6a9d986 --> XMIT(i-d2e29fa2: #8) 
...

这是我们的计划。我们在运行时将

PING

协议替换为我们自己的

EC2\u-PING

版本，该版本使用AWS调用来查找其他候选集群成员。这不是连接问题

你知道为什么有些包裹没有到达目的地吗

你知道为什么有些包裹没有到达目的地吗

这是一个值得追踪的有趣问题。它对某些EC2实例的影响似乎比其他实例大得多。问题在于通过UDP在EC2实例之间发送大数据包

缓存同步代码正在向远程服务器发送一个大的~300k消息，该消息被分段（使用FRAG2）为4个60k数据包（默认大小）和1个43k数据包，并发送到远程机箱。由于某些网络限制，遥控箱仅接收最后（第5）条43k信息。6万条信息永远不会到达。这似乎只发生在某些主机对之间——其他主机对可以使用大数据包进行良好通信。我花了这么长时间才将问题隔离出来，并对其进行诊断，这是因为它不是通用的

我最初认为这是UDP接收器窗口大小问题，并尝试对其进行调整（

sysctl-w net.core.rmem_max=10240000

），但这没有帮助。查看tcpdump显示，60k个数据包没有到达远程主机。只有43k个数据包被删除

解决方案是将frag尺寸减小到16k（32k可能还可以，但我们是保守的）。当数据包在亚马逊的虚拟网络中传输时，AWS对数据包的大小有一些内部限制，亚马逊的虚拟网络正在过滤可能超过50k的大型UDP数据包。默认的Jgroups片段大小（60k）为big IMO，可能应该减少到32k左右

我们就此向亚马逊提交了一份通知单，他们承认了这个问题，但普遍的反应是，他们很难解决这个问题。我们已经调整了碎片的大小，并且正在工作，所以票被关闭了。从票中引用：

发件人：Amazon Web服务

这是案例XXXXXXXXX的更新。我们目前在Amazon EC2上的数据包大小限制为32k及以下，并且可以确认您在较大数据包大小时面临的问题。我们正在研究解决这一限制的办法。请让我们知道您是否可以将数据包大小保持在此级别以下，或者这是否是阻碍您操作能力的严重问题

我们正在积极研究增加数据包大小以及其他平台改进，并对由此带来的不便表示歉意

关于EC2的一些其他评论。首先，我们看到同一可用性区域中的主机需要大于8的TTL。如果您正在使用多播，请确保您的TTL设置为128或其他。我们起初认为这是问题所在，但最终并非如此

---

希望这对其他人有所帮助。

在不添加任何元素的情况下，我想添加一种检测相同问题的替代方法

我不是tcpdump专家，然后通过调试和日志记录分析了这个问题

在我们的例子中，一条消息被分割成若干较小的数据包（给定FRAG2的FRAGU size参数）。其中一些（不一定是最后一个）是随机不发送的：通常情况下，数据包1到19被正确发送，21被发送，但20丢失

随后，在两个实例之间进行了大量往返：

客户将丢失数据包#20，它再次确认#19并要求20；服务器将发送明确请求的#20和未确认的#21

缺少20号的客户将收到21号（但不是20号），重新确认19号，重新询问20号，以此类推，时间从1秒到50秒不等

---

最后，缺少20号的客户通常会一声不吭地完成（即使从未收到过20号）。

万岁！非常感谢你的帖子。我们已经调查了一个类似的问题好几天了，但没有预见到任何解决方案。直到你的帖子写得恰到好处。