What is interesting to me is that the exact same client code only using a different url (i.e. to a normal http servlet, not a comet servlet) succeeds. Is there something in comet response headers that an antivirus app or firewall would pick up on? Why would a request to a normal servlet succeed and a comet servlet fail? Keep in mind the comet servlet has been shown to be funtional on numerous other machines.
I believe I disabled all firewalls and antivirus on the suspect machine, but I will double-check. Thanks for your response, Peter On Jan 15, 2008 9:37 AM, Leonardo Fraga <[EMAIL PROTECTED]> wrote: > Hello, > > I've had problems with long http responses and some kind of antiviruses > and internet firewalls (avg family, basically). > They put a hook on the winsocket stack for http connections and buffer > everything you are receiving, until the end (or some high amount of > data), to run the checks. In my case, this buffering lasts for minutes, > with no byte sent back to the browser. > > I think this can be a simple point to check... > > Hugs, > > Leonardo Fraga > Web Developer > [EMAIL PROTECTED] > > > Peter Warren wrote: > > >I posted this question along with some others recently. I'm > >re-posting it in its own thread with some additional information. > > > >I have a comet client app that works on all the machines I've tested > >except one. The failing machine sends a comet request to the server > >and then waits indefinitely for the response, even though the server > >has sent the response and flushed the buffer. I'm trying to figure > >out why the client doesn't receive the response and would really > >appreciate any tips. > > > >Server is latest from 6.0.x trunk and using nio connector. > > > >Failing machine info: > >- runs windows xp > >- windows firewall is turned off > >- fails on multiple networks, so it doesn't seem to be a router or > >firewall issue > >- computer has no problem with other network access > >- same test code pointed at a non-comet servlet (simply changing the > >url) succeeds!!! > > > >I used a socket monitoring tool to see if the client machine receives > >the response at all. It doesn't appear to. Below are traces from a > >successful machine and the failing machine. I'm not a sockets expert, > >so I don't really know what to look for, but the two things that stand > >out to me are: > >- failing machine uses localhost ip instead of its LAN ip (which is > >192.168.1.102 according to ipconfig) > > - succeeding machine uses LAN ip > > - I don't understand why they're different > >- failing machine receives WSAEWOULDBLOCK error instead of server response > > > >I believe the WSAEWOULDBLOCK basically indicates that there's nothing > >on the socket to be read, which seems to indicate that the failing > >machine never receives the response at all. > > > >Is this a comet problem? Is it a routing problem? Anyone have any > >ideas for what the problem might be? Any tips on what I should > >investigate next? > > > >Thanks, > >Peter > > > >SUCCEEDING MACHINE SOCKET TRACE > >========================= > >Connect ---------------------------------------------------- > >Address: 66.241.85.247:80 > >Return Value: 0 > >Error Code: 0 > > > >GetSockName ------------------------------------------------ > >Address: 192.168.1.133:1104 > >Return Value: 0 > >Error Code: 0 > > > >SetSockOpt ------------------------------------------------- > >Level: SOL_SOCKET > >Opt Name: SO_KEEPALIVE > >Opt Len: 4 > >Return Value: 0 > >Error Code: 0 > >01 00 00 00 .... > > > >Send ------------------------------------------------------- > >Address: 192.168.1.133:1104 => 66.241.85.247:80 > >Flags: 0 > >Return Value: 0 > >Error Code: 0 > >Data: > >POST /servlet/Receive HTTP/1.1 > >Host: www.seekspeak.com > >User-Agent: SeekSpeak > >Connection: keep-alive > >Content-Type: text/plain > >Transfer-Encoding: chunked > > > >2c > >source_chat_id=192.168.1.1%3A486547763981705 > > > > > >Recv ------------------------------------------------------- > >Address: 192.168.1.133:1104 =< 66.241.85.247:80 > >Flags: 0 > >Return Value: 0 > >Error Code: 0 > >Data: > >HTTP/1.1 200 OK > >Server: Apache-Coyote/1.1 > >Set-Cookie: JSESSIONID=4618F4394D4924A5629628ED1CD2ADDE; Path=/ > >Transfer-Encoding: chunked > >Date: Thu, 10 Jan 2008 07:55:05 GMT > > > >49 > >OK > >COMMAND > >INVITATION_ACCEPTED > >tutorial_client > >Invitation accepted... > > > > > >FAILING MACHINE SOCKET TRACE > >===================== > >Connect ---------------------------------------------------- > >Address: 66.241.85.247:80 > >Return Value: 0 > >Error Code: 0 > > > >GetSockName ------------------------------------------------ > >Address: 127.0.0.1:2085 > >Return Value: 0 > >Error Code: 0 > > > >SetSockOpt ------------------------------------------------- > >Level: SOL_SOCKET > >Opt Name: SO_KEEPALIVE > >Opt Len: 4 > >Return Value: 0 > >Error Code: 0 > >01 00 00 00 .... > > > >Send ------------------------------------------------------- > >Address: 127.0.0.1:2085 => 66.241.85.247:80 > >Flags: 0 > >Return Value: 0 > >Error Code: 0 > >Data: > >POST /servlet/Receive HTTP/1.1 > >Host: www.seekspeak.com > >User-Agent: SeekSpeak > >Connection: keep-alive > >Content-Type: text/plain > >Transfer-Encoding: chunked > > > >2c > >source_chat_id=192.168.1.1%3A485374421886120 > > > > > >Select ----------------------------------------------------- > >Return Value: 0 > >Error Code: 0 > > > >Recv ------------------------------------------------------- > >Address: 127.0.0.1:2077 =< 66.241.85.247:80 > >Flags: 0 > >Return Value: -1 > >Error Code: WSAEWOULDBLOCK > > > >--------------------------------------------------------------------- > >To start a new topic, e-mail: users@tomcat.apache.org > >To unsubscribe, e-mail: [EMAIL PROTECTED] > >For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > --------------------------------------------------------------------- > To start a new topic, e-mail: users@tomcat.apache.org > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
