tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leif Mortenson <leifli...@tanukisoftware.com>
Subject Re: Problem with Tomcat 4.1.30, IIS, isapi_redirect.dll and POSTs
Date Wed, 23 Jun 2004 09:24:39 GMT
For the archives. I got no replies to this. But I was able to correct this
problem by switching over to using jk2 rather than jk. That means using
isapi_redirector2.dll rather than isapi_redirect.dll.

This was not at all clear from the online docs. Everything points to using
isapi_redirect.dll for connecting via IIS.

Cheers,
Leif

Leif Mortenson wrote:

>I have been using version 4.1.18 along with the newest isapi_redirect.dll at
>the time it was installed for the past year or. Recently to resolve an
>unrelated problem we upgraded to Tomcat 4.1.30 and isapi_redirect.dll 1.2.5
>and have been testing things out on our test servers.
>
>This was working for me for a day or two. Just before I went to deploy this
>onto our live servers, I decided to do one last test. For some reason,
>all of
>the pages which are requested using a POST, hang for a couple minutes
>before returning an error.
>
>Reviewing the log from Tomcat, I found the following message:
>
>Jun 21, 2004 6:42:33 PM org.apache.jk.common.HandlerRequest invoke
>SEVERE: Error decoding request
>java.io.IOException
>at org.apache.jk.common.JkInputStream.receive(JkInputStream.java:294)
>at
>org.apache.jk.common.HandlerRequest.decodeRequest(HandlerRequest.java:537)
>at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:373)
>at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:673)
>at
>org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:615)
>at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:786)
>at
>org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683)
>at java.lang.Thread.run(Thread.java:536)
>12 34 01 c1 02 04 00 08 48 54 54 50 2f 31 2e 31 | .4.?....HTTP/1.1
>00 00 18 2f 6b 61 6e 73 68 69 2f 6a 5f 73 65 63 | .../kanshi/j_sec
>75 72 69 74 79 5f 63 68 65 63 6b 00 00 0c 31 39 | urity_check...19
>32 2e 31 36 38 2e 31 2e 33 31 00 00 0c 31 39 32 | 2.168.1.31...192
>2e 31 36 38 2e 31 2e 33 31 00 00 07 6f 72 6c 61 | .168.1.31...orla
>6e 64 6f 00 00 50 00 00 0b a0 01 00 57 69 6d 61 | ndo..P...?..Wima
>67 65 2f 67 69 66 2c 20 69 6d 61 67 65 2f 78 2d | ge/gif, image/x-
>78 62 69 74 6d 61 70 2c 20 69 6d 61 67 65 2f 6a | xbitmap, image/j
>70 65 67 2c 20 69 6d 61 67 65 2f 70 6a 70 65 67 | peg, image/pjpeg
>2c 20 61 70 70 6c 69 63 61 74 69 6f 6e 2f 78 2d | , application/x-
>73 68 6f 63 6b 77 61 76 65 2d 66 6c 61 73 68 2c | shockwave-flash,
>20 2a 2f 2a 00 a0 04 00 02 6a 61 00 a0 06 00 0a | */*.?...ja.?...
>4b 65 65 70 2d 41 6c 69 76 65 00 a0 0b 00 07 6f | Keep-Alive.?...o
>72 6c 61 6e 64 6f 00 a0 0d 00 1f 68 74 74 70 3a | rlando.?...http:
>2f 2f 6f 72 6c 61 6e 64 6f 2f 6b 61 6e 73 68 69 | //orlando/kanshi
>2f 6c 6f 67 69 6e 2e 6a 73 70 00 a0 0e 00 32 4d | /login.jsp.?..2M
>6f 7a 69 6c 6c 61 2f 34 2e 30 20 28 63 6f 6d 70 | ozilla/4.0 (comp
>61 74 69 62 6c 65 3b 20 4d 53 49 45 20 36 2e 30 | atible; MSIE 6.0
>3b 20 57 69 6e 64 6f 77 73 20 4e 54 20 35 2e 31 | ; Windows NT 5.1
>29 00 a0 09 00 2b 4a 53 45 53 53 49 4f 4e 49 44 | ).?..+JSESSIONID
>3d 37 34 39 44 46 39 34 32 42 35 45 38 32 39 33 | =749DF942B5E8293
>45 39 32 31 32 34 34 36 32 35 36 37 38 41 34 46 | E921244625678A4F
>42 00 a0 08 00 02 33 37 00 a0 07 00 21 61 70 70 | B.?...37.?..!app
>6c 69 63 61 74 69 6f 6e 2f 78 2d 77 77 77 2d 66 | lication/x-www-f
>6f 72 6d 2d 75 72 6c 65 6e 63 6f 64 65 64 00 a0 | orm-urlencoded.?
>03 00 0d 67 7a 69 70 2c 20 64 65 66 6c 61 74 65 | ...gzip, deflate
>00 00 0d 63 61 63 68 65 2d 63 6f 6e 74 72 6f 6c | ...cache-control
>00 00 08 6e 6f 2d 63 61 63 68 65 00 03 00 00 00 | ...no-cache.....
>04 00 00 00 ff | ....?
>Jun 21, 2004 6:42:33 PM org.apache.jk.common.ChannelSocket processConnection
>WARNING: processCallbacks status 2
>
>Doing additional tests, I have found that it appears to be timeout
>waiting for
>more data to be sent? (guess) I say this because if I do the POST and then
>wait patiently then the error takes about 50 seconds to show up in the log.
>The request will cause 2 such dumps before returning an error to the
>browser. However if I push the submit button on my form then the
>previous request will immediately cause the above error to be dumped.
>The second request will continue to hang until it too times out and dumps
>the above message.
>
>I enabled debug output in the connector and get the following. It seems to
>fail once and then retry. I am including the significant portion of the
>second
>attempt:
>
>[Mon Jun 21 19:14:44 2004] [jk_ajp_common.c (295)]: Into
>ajp_marshal_into_msgb
>[Mon Jun 21 19:14:44 2004] [jk_ajp_common.c (463)]:
>ajp_marshal_into_msgb - Done
>[Mon Jun 21 19:14:44 2004] [jk_connect.c (158)]: Into jk_open_socket
>[Mon Jun 21 19:14:44 2004] [jk_connect.c (165)]: jk_open_socket, try to
>connect socket = 424
>[Mon Jun 21 19:14:44 2004] [jk_connect.c (174)]: jk_open_socket, after
>connect ret = 0
>[Mon Jun 21 19:14:44 2004] [jk_connect.c (183)]: jk_open_socket, set
>TCP_NODELAY to on
>[Mon Jun 21 19:14:44 2004] [jk_connect.c (192)]: jk_open_socket, set
>SO_KEEPALIVE to on
>[Mon Jun 21 19:14:44 2004] [jk_connect.c (200)]: jk_open_socket, return,
>sd = 424
>[Mon Jun 21 19:14:44 2004] [jk_ajp_common.c (661)]: In
>jk_endpoint_t::ajp_connect_to_endpoint, connected sd = 424
>[Mon Jun 21 19:14:44 2004] [jk_ajp_common.c (693)]: sending to ajp13 #453
>[Mon Jun 21 19:14:44 2004] [jk_ajp_common.c (966)]: ajp_send_request 2:
>request body to send 37 - request body to resend 0
>[Mon Jun 21 19:14:44 2004] [jk_isapi_plugin.c (514)]: Into
>jk_ws_service_t::read
>[Mon Jun 21 19:15:44 2004] [jk_isapi_plugin.c (548)]:
>jk_ws_service_t::read, ReadClient failed
>[Mon Jun 21 19:15:44 2004] [jk_ajp_common.c (882)]: ERROR: receiving
>data from client failed. Connection aborted or network problems
>[Mon Jun 21 19:15:44 2004] [jk_ajp_common.c (1303)]: ERROR: Client
>connection aborted or network problems
>[Mon Jun 21 19:15:44 2004] [jk_isapi_plugin.c (925)]: HttpExtensionProc
>service() returned OK
>[Mon Jun 21 19:15:44 2004] [jk_ajp_common.c (1529)]: Into
>jk_endpoint_t::done, closing connection 0
>[Mon Jun 21 19:15:44 2004] [jk_ajp_common.c (605)]: In
>jk_endpoint_t::ajp_close_endpoint
>
>My question is: Do you have any idea what could be causing this. The
>really peculiar thing is that even if I go back to using my old Tomcat
>4.1.18
>deployment. This particular IIS server is now completely unable to do
>POSTs. I had not made any changes on the IIS server between the time
>that it was working and when it stopped. So I am wondering if I had just
>been lucky that things had been working before.
>
>Needless to say I am not thinking it is a good idea to try this out on the
>live servers as I have not been able to figure out a way to return the old
>state should it fail there as well.
>
>Thanks in advance for any advice you may have.
>Cheers,
>Leif
>  
>


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org


Mime
View raw message