本地“重传” HTTPS 请求 - 在基于 Axis2 的 WebApp 中看到这一点

发布于 2024-12-18 17:36:47 字数 1335 浏览 0 评论 0原文

我一直在基于 axis2 (1.4.1) 的 Web 应用程序（在 Websphere 7 中运行）中观察到奇怪的行为。如果我的基于肥皂的 Web 服务请求在服务器线程中被阻塞正好 60 秒，我会再次收到 Web 服务请求；更具体地说：我的服务器端 SOAP 消息接收器再次被调用（第一个线程此时仍处于阻塞状态，并且客户端应用程序已在 30 秒前收到超时）。

我一直在努力追查这一点；但没有成功理解这种行为。以下是我已经掌握的事实：

事实 1：仅在启用 SSL 的情况下才会发生

事实 2：基于 axis1 的 Web 服务客户端不是进行重新传输的客户端；而是基于 axis1 的 Web 服务客户端。它也根本不是客户。我一直在嗅探客户端的传出数据包和服务器的传入数据包，即使我看不到内容，根据时间，重新传输也不会通过网络进行。

事实 3（基于事实 1+2）：“重新发送”必须在服务器端的 NIC 和 JRE (IBM JRocket 9 VM) 之间的某个位置启动。

最初这个问题发生在我的应用程序中，因为调用在数据库请求上被阻塞，但我一直在通过在服务器中为此请求设置断点来模拟它。

抱歉，我无法提供任何有用的跟踪/日志来支持我的“事实”，但我希望我可能会在这里遗漏一些相当明显的东西......显然，应用程序层不应该看到任何重传； tcp应该知道哪些包已经被传递到上层；所以，我认为问题可能出在接近 java 中的 HTTP(S) 协议层实现的地方？？？

此外，任何如何追踪此问题的好主意将不胜感激。 SSL 卷入这个问题使得一切变得有点困难...

编辑：我刚刚做了一些更多的测试，现在可以在方程式中添加更多事实：

编辑： >事实 4：为了真正确定它不是来自客户端，我在发送第一个 Web 服务请求后拔掉了网络电缆。发生了重传；所以，这肯定发生在服务器端。

事实 5：我添加了一个 servlet 过滤器来查看是否会触发重传。这是;因此，重传必须像预期的那样在服务器上的 NIC 和 serlt 引擎之间触发； JVM 运行时或 TCP 级别的某个位置。

事实 6：仅当其他数据发送到中间的同一 TCP 端口时才会发生重传。即，如果我在初始 Web 服务请求之后不发送一些额外的包/请求，则不会发生重新传输。这是否有助于解释 TCP 层的一些问题？

我正在运行一个相当旧的 RedHat Enterprise Linux：Linux 2.6.9-89.EL

提前致谢，丹尼尔

原文

I have been observing a strange behaviour in my axis2-based (1.4.1) webapplication (running in Websphere 7).
If my soap-based Webservice-request is blocked in the server-thread for exactly 60 seconds, I receive the Webservice-request again; more specific: my server-side SOAP message receiver is invoked again for that call (the first thread is still blocking at this time and the client application has received a timeout already 30 seconds ago).

I have been trying to trace this down; but did not succeed to understand the behaviour. Here are the facts that I have already:

Fact 1: It only happens with SSL enabled

Fact 2: The axis1-based webservice-client is not the one doing the retransmits; neither is it the client at all. I have been sniffing the outgoing packets at the client and incoming packets at the server and even though I cannot see the contents, based on the time, the retransmit is not going over the network.

Fact 3 (based on Facts 1+2): The "resend" must be initiated somewhere between the NIC and JRE (IBM JRocket 9 VM) on the SERVER-side.

Initially this problem happend in my application beacause the call was blocking on a database-request but I have been simulation it with setting a break-point in the server for this request.

Sorry that I cannot provide any useful traces/logs to back up my "facts", but I was hoping that I might be missing something fairly obvious here... Obviously, the application layer should not see any retransmits; tcp should know what packages have been delivered to the upper layer; so, i would assume the problem could be somewhere close to the HTTP(S) protocol layer implementation in java???

Also, any good idea how to track this down would be highly appreciated. SSL beeing involved in the problem makes it all a litte harder...

Edit: I just did some more test and can now add some more facts to the equation:

Fact 4: To be really sure it is not comiming from the client, I unplugged the network-cable after sending the first webservice-request. The retransmit happend; so, it is definitvley happening at server-side.

Fact 5: I added a servlet-filter to see if it is triggered for the retransmit. It is; so, the retransmit must be, like expected, triggered between NIC and servelt engine on the server; somewhere in the JVM runtime or at TCP level.

Fact 6: The retransmit only happens if other data is going to the same TCPport in between. I.e. if i do not send some additional packages/requests after the initial webservice-request, the retransmit does not happen. Does this help to explain it with some problems in teh TCP layer?

I am running a rather older RedHat Enterprise Linux: Linux 2.6.9-89.EL

Thanks in advance,
Daniel

分享到QQ

分享到微博