HTTPS请求的本地“重新传输” - 在基于Axis2的WebApp中查看

时间:2011-11-29 16:10:43

标签: ssl tcp websphere axis2

我一直在观察基于axis2的(1.4.1)webapplication(在Websphere 7中运行)中的奇怪行为。 如果基于soap的Webservice请求在服务器线程中被阻止了60秒,我再次收到Webservice请求;更具体一点:我的服务器端SOAP消息接收器再次被调用(第一个线程此时仍然阻塞,客户端应用程序已经在30秒前收到了超时)。

我一直试图追查这一点;但没有成功理解这种行为。以下是我已经掌握的事实:

事实1 :仅在启用SSL时才会发生

事实2 :基于axis1的webservice-client不是进行重传的人;它根本不是客户端。我一直在嗅探客户端的传出数据包和服务器上的传入数据包,即使我看不到内容,根据时间,重传不会通过网络。

事实3 (基于事实1 + 2):必须在SERVER端的NIC和JRE(IBM JRocket 9 VM)之间的某处启动“重新发送”。

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

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

此外,任何好主意如何跟踪这一点将非常感激。涉及这个问题的SSL正在变得更加困难......

编辑 :我刚做了一些测试,现在可以在等式中添加更多的事实:

事实4 :为了确保它不是来自客户端,我在发送第一个webservice-request后拔掉了网线。转发发生;所以,它确实发生在服务器端。

事实5 :我添加了一个servlet-filter,以查看是否为重新传输触发了它。它是;因此,重新传输必须像预期的那样在服务器上的NIC和servelt引擎之间触发;在JVM运行时或TCP级别的某个地方。

事实6 :只有在其他数据进入同一个TCP端口时才会进行重新传输。即如果我在初始webservice-request之后没有发送一些额外的包/请求,则不会发生重新传输。这有助于解决TCP层中的一些问题吗?

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

提前致谢, 丹尼尔

0 个答案:

没有答案