Return-Path: Delivered-To: apmail-tomcat-users-archive@www.apache.org Received: (qmail 8378 invoked from network); 20 Apr 2010 07:36:14 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 20 Apr 2010 07:36:14 -0000 Received: (qmail 22927 invoked by uid 500); 20 Apr 2010 07:36:11 -0000 Delivered-To: apmail-tomcat-users-archive@tomcat.apache.org Received: (qmail 22644 invoked by uid 500); 20 Apr 2010 07:36:08 -0000 Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Tomcat Users List" Delivered-To: mailing list users@tomcat.apache.org Received: (qmail 22632 invoked by uid 99); 20 Apr 2010 07:36:07 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 20 Apr 2010 07:36:07 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of flyaruu@gmail.com designates 209.85.210.192 as permitted sender) Received: from [209.85.210.192] (HELO mail-yx0-f192.google.com) (209.85.210.192) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 20 Apr 2010 07:36:00 +0000 Received: by yxe30 with SMTP id 30so3446734yxe.30 for ; Tue, 20 Apr 2010 00:35:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:content-type; bh=Y/HOiVusaK0XXscCGZIv7g87YSIPLp+zByFSQbfnzVc=; b=ty6iXsp8rk3FMLBm/wfSFGFqdCzml6cTc3dXXDyAVprgw0wmwRbe52KuMhhEAVYfjs EbN+VuqQTqnpf7Xyx++PaEglqBwt5oakVhs4C4Tt5xNGwhvwido3cz3YO/i4auh1DqHH 3K79X21ThS/++4SAVHjzzcaZJrm00Uu/h66es= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=wbRsNa2gfQOsRoyGPx6AJCEAjwDq8zcIm38qjyuYf0h9WkA0zN4D7UGGHbkI5A/pSw 1ulMFjk2C8xXS4SbO2LnW2N7DC2zkk6kTOQdzd2syUQHeePjulrqtxUQwmEjVi9VslF2 GjOsYrw7c5Sem3tjqaTliGAvIq6f1Fq5yzhvU= MIME-Version: 1.0 Received: by 10.90.71.9 with HTTP; Tue, 20 Apr 2010 00:35:38 -0700 (PDT) In-Reply-To: <4BCD5116.6080601@ice-sa.com> References: <4BCD5116.6080601@ice-sa.com> Date: Tue, 20 Apr 2010 09:35:38 +0200 Received: by 10.91.185.3 with SMTP id m3mr3511959agp.79.1271748938852; Tue, 20 Apr 2010 00:35:38 -0700 (PDT) Message-ID: Subject: Re: Missing events in Comet From: Frank Lyaruu To: Tomcat Users List Content-Type: multipart/alternative; boundary=0016e6460744be68510484a61f67 X-Virus-Checked: Checked by ClamAV on apache.org --0016e6460744be68510484a61f67 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Andre, Thanks for your reply. Yes, it does. I am using a very basic java client (using a HttpURLConnectio= n), and I tested it against a server socket, and I always get a final, empty chunk. regards Frank. ps. I am seeing this both on Tomcat 6.0.26 and Tomcat 7 trunk. 2010/4/20 Andr=E9 Warnier > Frank Lyaruu wrote: > >> Hi all, >> >> We are trying to use Comet to make our web-service platform more resiste= nt >> to heavy loads. >> We use HTTP/1.1 POSTS to send our requests (using chunked requests), and >> the >> client waits for the response. >> >> My problem is the following: As far as I can see, I have no way of >> (reliably) detecting the end of the request. >> I sometimes receive an END event, and sometimes a READ event with 0 >> available bytes. Those seem to indicate >> that the request is complete, but sometimes I just get a few regular REA= D >> events and then nothing. >> >> If I don't use chunking, I can get it to work, as I just 'know' how many >> bytes to expect. If I could do the de-chunking >> myself I could also detect the final empty chunk + CRLF to know the >> request >> is done. >> >> My question is: Shouldn't the final chunk always fire an END event, or a= t >> least an empty READ event? >> >> I hope someone can help me, I can supply all sorts of concise testing >> code. >> >> Have you verified that /the client/ does the chunking properly ? > As far as I recall, it /must/ send a last chunk of size zero to indicate > the end of the request, but does it, always ? > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org > For additional commands, e-mail: users-help@tomcat.apache.org > > --0016e6460744be68510484a61f67--