{"id":175,"date":"2003-05-14T12:06:00","date_gmt":"2003-05-14T17:06:00","guid":{"rendered":"http:\/\/crazedmonkey.com\/blog\/uncategorised\/tomcat_difficulties.html"},"modified":"2006-10-18T17:54:32","modified_gmt":"2006-10-18T21:54:32","slug":"tomcat_difficulties","status":"publish","type":"post","link":"http:\/\/crazedmonkey.com\/blog\/programming\/tomcat_difficulties.html","title":{"rendered":"Invoking the Lazy Web for my Tomcat difficulties"},"content":{"rendered":"

As the Tomcat user mailing list<\/a> has not been much help in solving two annoying Tomcat issues, I hereby invoke the Lazy Web<\/a>!<\/p>\n

The first issue involves Tomcat blocking on a call to HttpServletRequest.getSession()<\/code><\/a>. This seems to only occur when I am debugging Tomcat remotely from within IDEA under Windows XP. I am using the latest version of Tomcat, JVM 1.4.1-b21 and IDEA 3.0.1. This is possibly an IDEA issue. Since the problem only seems to occur when debugging, it is not one needing an urgent solution.<\/p>\n

The second and more annoying issue involves a mangled Content-Length<\/var> header in the occasional HTTP response<\/a>. When I say “mangled”, I mean that the header field does not read as “Content-Length”, but something almost<\/em> like “Content-Length”. Naturally, a response without a Content-Length<\/var> field violates the HTTP specifications. The content and all other header fields are never mangled\u00e2\u20ac\u201donly Content-Length<\/var>, only sometimes<\/em>, and usually when the length of the body is non-zero<\/ins>.<\/p>\n

The following code snippet illustrates how I am setting the response:<\/p>\n

private void writeHttpContent( HttpServletResponse response, byte[] contentsOutBytes ) throws Exception\r\n{\r\n    response.setContentType( \"application\/octet-stream\" );\r\n    response.setContentLength( contentsOutBytes.length );\r\n\r\n    \/\/ Only bother writing if there is something to write.\r\n    if( contentsOutBytes.length > 0 )\r\n    {\r\n        \/\/ Grab an output stream from the HTTP response and write to it\r\n        BufferedOutputStream out = new BufferedOutputStream( response.getOutputStream() );\r\n        out.write( contentsOutBytes );\r\n        response.getOutputStream().flush();\r\n    }\r\n}<\/code><\/pre>\n
I have tried a few variations on the above including calling flush()<\/code> on the BufferedOutputStream<\/code>, and closing either response.getOutputStream()<\/code> or BufferedOutputStream<\/code>, but with the same result. Using response.setHeader( \"Content-Length\", Integer.toString( contentsOutBytes.length ) )<\/code> makes no difference, as one would hope. I also eliminated the call to response.setContentLength()<\/code> but that always resulted in a missing Content-Length<\/var>.<\/p>\n
Here is an example of a mangled response:<\/p>\n
Content-Type: application\/octet-stream\r\nContent-Lengtd><b \r\nDate: Tue, 25 Feb 2003 17:28:49 GMT\r\nServer: Apache Coyote\/1.0<\/pre>\n
To date, I have only seen this happen on our Debian Linux box running Tomcat 4.1.16-1 from testing and Sun’s J2SDK1.4.1_01-b01. This led me to believe that it could be a problem with Debian, but a post to the debian-java mailing list<\/a> turned up nothing.<\/p>\n
Naturally, the above problem cannot be reproduced but it does happen often enough to be terribly annoying for our client devices. Furthermore, I have a few Java apps hitting the servlet on a consistent basis using HTTP\/1.0 and they never experience this problem. I can’t understand how this could be limited to HTTP\/1.1.<\/p>\n
If you have any suggestions\u00e2\u20ac\u201dany suggestions at all\u00e2\u20ac\u201dthen do not hesitate to leave a comment. At this point, I’d accept chicken bone voodoo magic as a possible solution.<\/p>\n
  <\/p>\n
Update (05\/15):<\/strong> After spending most of today and some of yesterday investigating this issue, we have determined that it was the router causing the munged bytes, always in the same offset within a packet. The router in question is a LinkSys, and will be subsequently hurled, beaten and torched sometime in the very near future.<\/p>\n
 <\/ins><\/p>\n","protected":false},"excerpt":{"rendered":"
As the Tomcat user mailing list<\/a> has not been much help in solving two annoying Tomcat issues, I hereby invoke the Lazy Web<\/a>!<\/p>\n
The first issue involves  Tomcat blocking on a call to HttpServletRequest.getSession()<\/a>. This seems to only occur when I … Read more<\/span><\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_mi_skip_tracking":false},"categories":[4,9,2],"tags":[],"_links":{"self":[{"href":"http:\/\/crazedmonkey.com\/blog\/wp-json\/wp\/v2\/posts\/175"}],"collection":[{"href":"http:\/\/crazedmonkey.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/crazedmonkey.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/crazedmonkey.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"http:\/\/crazedmonkey.com\/blog\/wp-json\/wp\/v2\/comments?post=175"}],"version-history":[{"count":0,"href":"http:\/\/crazedmonkey.com\/blog\/wp-json\/wp\/v2\/posts\/175\/revisions"}],"wp:attachment":[{"href":"http:\/\/crazedmonkey.com\/blog\/wp-json\/wp\/v2\/media?parent=175"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/crazedmonkey.com\/blog\/wp-json\/wp\/v2\/categories?post=175"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/crazedmonkey.com\/blog\/wp-json\/wp\/v2\/tags?post=175"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}