tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Hanik - Dev Lists <devli...@hanik.com>
Subject Re: comet client doesn't receive server response
Date Mon, 21 Jan 2008 04:30:39 GMT
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
> <leonardo.fraga@cedrofinances.com.br> 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
>> leonardo.fraga@cedrofinances.com.br
>>
>>
>> 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: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>>
>>>
>>>
>>>       
>> ---------------------------------------------------------------------
>> To start a new topic, e-mail: users@tomcat.apache.org
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>>     
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
>   


---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message