soloaris环境下tomcat日志奇怪问题

在soloaris环境下
在使用过程中后台报了很多如下的错误，目前还不能确定该错误和应用程序的操作有什么关系，并且在
该错误的前后一般都没有报其他系统异常。

2007-9-6 0:14:30 org.apache.tomcat.util.net.TcpWorkerThread runIt
严重: Remote Host /172.16.16.94 SocketException: 无效的自变量
2007-9-6 0:14:30 org.apache.tomcat.util.net.TcpWorkerThread runIt
严重: Remote Host /172.16.16.94 SocketException: 无效的自变量

目前从网上找到一种说法是给soloaris打补丁，因为2.61的soloaris是最新的，所以还没有试用该方法。
不知道大家有什么碰到过？给些意见和经验

找到下面这篇文章，基本可以确定这个错应该忽略，实际使用过程中也没有因为这个日志错而导致什么问题出现。
Tomcat的SEVERE: Remote Host / SocketException: Connection reset原因分析及解决办法

引用:

昨天在测试帮助文件时发现一直打不开，好像是一直再刷新，于是就到服务器上查看Tomcat的日志，就发现了下面的信息：
Apr 21, 2008 9:27:34 AM org.apache.tomcat.util.net.TcpWorkerThread runIt
SEVERE: Remote Host /172.16.128.248 SocketException: Connection reset
并且这两条信息几乎是每个1-2秒就出现一次，很是频繁。于是就搜索了一下，就找到了下面的内容：
The usual cause is that the browser''s stopped a HTTP request part-way through,
generally because the user''s navigated to another page before the first page has
completely downloaded. The browser closes the connection, with the result that
Tomcat gets an exception when it next tries to write data to the socket.
Arguably it shouldn''t be logged as a SEVERE error on production systems, but
getting that log message during development and stress testing can be very
handy! 于是就查看它引用的JavaScript文件，发现好多不存在。终于明白，是因为有些变量不存在，导致了这里的反复重载。重新加入这些JavaScript文件后，问题解决。

Fix it by any of the following (in increasing order of difficulty):

1) Ignore it (and change any log-reading scripts that look for SEVERE errors to
ignore this one);

2) Grab the source for 5.0.28, find the line where this is logged and change the
logging level in the case of a connection reset error, then recompile Tomcat;

3) Educate your users that they are supposed to sit on their hands until the
page has completely loaded (by far the hardest ;-) ).

后面还有别人的补充：
If it happens that often and you don''t have a high traffic site, it might be a monitor script, that does only check if it can do a TCP connect and drop the connection before a full HTTP request-response cycle has finished.

不过我的情况和上面所说的都不符合，于是就查看了源文件，发现了如下代码：



if (!window.gbWhVer||!window.gbWhUtil||!window.gbWhMsg)
    document.location.reload();