WAS http请求默认的响应时间是多少

WAS http请求默认的响应时间是多少的解答如下

默认超时时间是60秒,可以通过下面语句进行修改

HttpClient httpClient=new HttpClient()

httpClient.getHttpConnectionManager().getParams().setConnectionTimeout(1000 * 60)//链接超时60秒

httpClient.getHttpConnectionManager().getParams().setSoTimeout(1000 * 60)//读取超时60秒

was服务无法保持会话

部署到一台已有的was服务器上。登录时被拦截器拦截，不断报session超时，重定向到登录首页。

在tomcat及新建的was服务器下安装，都可以正常运行。

根据这个思路，打印日志，已有的was服务器显示为每次请求都新建了session，导致会话不能够保持住。

排查was配置，发现在was设置里，已经设置了cookie的path路径为 /imanager 。而我的应用上下文为mpay-manage。客户端浏览器的会话通过cookie来记录，登录时候因读取不到cookie导致session为空，服务器认为是新的请求，故而新建session。从使用者角度来看，就是页面不断跳转到登录页面，无法正常登录进应用系统。

所以，针对以上情况，当时的处理方式是将was服务器的cookie的 路径path设置为 /。重新启动was服务器实例。登录运行成功。

故此，特针对cookie重新学习下。

---------------------------------以下摘自互联网-----------------------------------------

Cookie 概述

Cookie是什么？ Cookie 是一小段文本信息，伴随着用户请求和页面在 Web 服务器和浏览器之间传递。Cookie 包含每次用户访问站点时 Web 应用程序都可以读取的信息。

为什么需要Cookie？ 因为HTTP协议是无状态的，对于一个浏览器发出的多次请求，WEB服务器无法区分 是不是来源于同一个浏览器。所以，需要额外的数据用于维护会话。 Cookie 正是这样的一段随HTTP请求一起被传递的额外数据。

Cookie能做什么？ Cookie只是一段文本，所以它只能保存字符串。而且浏览器对它有大小限制以及 它会随着每次请求被发送到服务器，所以应该保证它不要太大。 Cookie的内容也是明文保存的，有些浏览器提供界面修改，所以， 不适合保存重要的或者涉及隐私的内容。

Cookie 的限制。 大多数浏览器支持最大为 4096 字节的 Cookie。由于这限制了 Cookie 的大小，最好用 Cookie 来存储少量数据，或者存储用户 ID 之类的标识符。用户 ID 随后便可用于标识用户，以及从数据库或其他数据源中读取用户信息。 浏览器还限制站点可以在用户计算机上存储的 Cookie 的数量。大多数浏览器只允许每个站点存储 20 个 Cookie；如果试图存储更多 Cookie，则最旧的 Cookie 便会被丢弃。有些浏览器还会对它们将接受的来自所有站点的 Cookie 总数作出绝对限制，通常为 300 个。

通过前面的内容，我们了解到Cookie是用于维持服务端会话状态的，通常由服务端写入，在后续请求中，供服务端读取。

网站访问量比较小，但是有个问题一直困扰着我们，就是was服务器隔一段时间就报线程挂起，时间有长有短，短的重启5分钟内就报。

一般情况是：

1.开应用服务器——用户下载——报线程挂起——下载量下降——报线程N长时间没活动，超过was设置的阀值，释放掉。

2.开应用服务器——用户下载——报线程挂起——下载量继续或者上升，挂起线程越来越多——was自动调整线程阀值——调不过来，挂。

经过查找，基本确定问题：是因为用户在用浏览器下载文件时，网络瞬断或其他原因，导致抛出异常，但是下载的线程并未释放。可打开浏览器下载，下到一半直接关掉浏览器来模拟这个现象。

byte[] b = new byte[1024]

...

while ((len = in.read(b)) != -1) {

out.write(b, 0, len)

}

...

登录后复制

修改为

byte[] b = new byte[1024]

...

while ((len = in.read(b)) != -1) {

Thread.sleep(50)

Thread.yield()

out.write(b, 0, len)

}

...

登录后复制

一些人建议的方法是，在服务器端给线程做个时间限制，超过时间的就关掉；但是这样做，较低网速下载大文件的用户，又会受到影响。因此用上面的做法是：线程处理一段时间，停一会，让出CPU控制权，不至于造成堵塞。

这个方法可能不是最好的，但是至少是比较合适的，现在服务器上线程挂起的现象已经大大减少，并且额外加了一句

if (request.getHeader("Range") != null) {

ErrShow(request, response, "不支持多线程！")

return

}

登录后复制

这样避免掉用下载工具的多线程下载。

哪位有更优解，请提出来，一起讨论一下。

刚才看到用守护线程来处理超时线程的解决方案，但另外一个技术主管极力反对，哪位能解释一下，为什么不可用？守护线程在什么情况下可用？谢谢

---