But this client isn't using a proxy. I've even tried the same client on my home network, where other machines function properly, to try to eliminate router/network/firewall issues. Is it possible that (and here I'm delving into territory I know next to nothing about) the client's socket library waits until the response is closed? It's a windows xp machine.
On Jan 20, 2008 8:30 PM, Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote: > yes, most proxies will wait until they receive the end of the response, > before passing it on. > that's what you are seeing, a regular servlet, ends the response right away > > Filip > > > Peter Warren wrote: > > 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] > > > > > > > > > > > --------------------------------------------------------------------- > 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]
