users@grizzly.java.net

RE: Re: TCP/HTTP Transfer-Encoding chunk problem

From: Ustuntas Yaman <yaman.ustuntas_at_kzen.be>
Date: Thu, 24 May 2007 21:28:57 +0200

Hi Jeanfrancois,

I reproduced the output. Attached is a netbeans project with almost the same code as the grizzly-http standalone code. I just edited the Main class to make sure that the same SelectorThread and Adaptor is loaded as in my application.

Sorry I was wrong about the ChunkedOutputFilter. It is indeed invoked and the end() operation is called.
BUT the "0\r\n\r\n" is still appended to the end of the last chunk instead of an ending chunk.
And Ethereal can not analyse it as a HTTP connection. (at least I am guessing so as the rest of the message is identical on the wire to the other application server responses).

Thanks again :)

Regards,

--
Yaman
-----Original Message-----
From: Jeanfrancois Arcand [mailto:Jeanfrancois.Arcand_at_Sun.COM]
Sent: Thu 24/05/2007 19:03
To: users_at_grizzly.dev.java.net
Subject:  Re: TCP/HTTP Transfer-Encoding chunk problem
 
Hi Yaman,
Ustuntas Yaman wrote:
> Hi Jeanfrancois,
> 
> This line didn't change anything:
> res.setContentLength(-1);
> 
> As for ChunkedOutputFilter, the code gets there several times while initializing the server before it dumps the configuration in the log (displayConfiguration). BUT when the service is invoked it doesn't reach ChunkedOutputFilter at all.
Strange....I need a test case to debug :-)
> 
> I think this last chunk problem is also the reason why Ethereal shows my connection just as TCP connection and not as HTTP (Normally it tags HTTP connections as HTTP). When I do "Decode as" HTTP it does decode it correctly though as the ending "0" is there but just at the wrong time/place.
If the ChunkedOutputFilter is not invoked, that's the problem. Now I 
don't understand why it isn't invoked properly. Do you think you can 
send me you implementation so I can take a look?
Thanks
-- Jeanfrancois
> 
> Any other suggestions?
> 
> Thanks :)
> 
> --
> Yaman
> 
> 
> 
> -----Original Message-----
> From: Jeanfrancois Arcand [mailto:Jeanfrancois.Arcand_at_Sun.COM]
> Sent: Wed 23/05/2007 18:14
> To: users_at_grizzly.dev.java.net
> Subject:  Re: TCP/HTTP Transfer-Encoding chunk problem
>  
> Hi Yaman,
> 
> Ustuntas Yaman wrote:
>> Hi Jeanfrancois,
>>
>> Thanks for your reply:
>>
>> Setup class:
>>
>> SelectorThread st = new SelectorThread();
>> st.setAlgorithmClassName(NoParsingAlgorithm.class.getName());
>> st.setPort(port);
>> st.setWebAppRootPath(rootFolder);
>> st.setAdapter(new RequestHandler());
>> st.setDisplayConfiguration(true);
>> st.initEndpoint();
>> st.startEndpoint();
>>
>>
>> I use the following operation to send data, always one chunck for data:
>>
>> public void write(Response res, String contentType, byte[] data) throws IOException {
>>         res.setContentType(contentType);
>>         res.addHeader("Server", "Server");
>>         res.sendHeaders();
>>         ByteChunk chunk = new ByteChunk();
>>         chunk.setBytes(data, 0, data.length);
>>         res.doWrite(chunk);
>>         res.finish();
>> }
> 
> This looks good. If you put a breakpoint in 
> tcp/http11/filters/ChunkedOutputFilter, does it get invoked when doing 
> res.doWrite(...); Also if you add, res.setContentLength(-1), does it 
> makes a difference? I suspect the chunking is not enabled.
> 
> You are using 1.5 right?
> 
> Thanks
> 
> -- jeanfrancois
> 
> 
>> after res.doWrite(chunk) line i have also tried the following:
>>
>> req.action(ActionCode.ACTION_POST_REQUEST , null);
>> and
>> req.action(ActionCode.ACTION_COMMIT, null);
>> and
>> req.aknowledge();
>>
>> but none of them worked to send the "0\r\n\r\n" in a seperate ending chunk.
>>
>> Thanks
>>
>> --
>> Yaman Ustuntas
>>
>> 4C Technologies, kZen R&D team
>> yaman.ustuntas_at_kzen.be
>> tel: +32 (0)3 4513660
>> mob: +32 (0)484510888
>>
>>
>>
>> -----Original Message-----
>> From: Jeanfrancois Arcand [mailto:Jeanfrancois.Arcand_at_Sun.COM]
>> Sent: Wed 23/05/2007 17:01
>> To: users_at_grizzly.dev.java.net
>> Subject:  Re: TCP/HTTP Transfer-Encoding chunk problem
>>  
>> Hi Yaman,
>>
>> Ustuntas Yaman wrote:
>>> Hello,
>>>
>>> I am making a WSS security server with grizzly. 
>> Are you using 1.0 or 1.5?
>>
>> What the server returns
>>> seems fine if a url is requested by the client.
>>> But when I make a JAXWS call (generated stubs) to the service, the 
>>> client fails with the following exception:
>>>
>>> javax.xml.ws.WebServiceException: Unsupported endpoint address:
>>>         at 
>>> com.sun.xml.ws.api.pipe.TransportTubeFactory.create(TransportTubeFactory.java:108)
>>>         at 
>>> com.sun.xml.ws.transport.DeferredTransportPipe.processRequest(DeferredTransportPipe.java:76)
>>> ....
>>>
>>> This client works fine if I call the same service deployed on 
>>> tomcat/glassfish.
>>> I wrote another client, this time constructing the SOAP message manually 
>>> with SOAPMessage class (+ security). This doesn't make the GET call 
>>> before invoking the service and it works fine on my server.
>>> What JAXWS (generated stubs) does it to do a GET on the WSDL file first 
>>> before invoking the service.
>>> The server returns the WSDL but there seems to be something wrong with 
>>> the Transfer-Encoding chunk.
>> How are you staring the server (the command line)?
>>
>>
>>> I looked at the server output on the wire and the 
>>> com.sun.grizzly.tcp.Response class doesn't seem send the "0\r\n" (to 
>>> indicate the end of the chunks/response) in a seperate chunk but appends 
>>> "0\r\n to the chunk containing the response.
>>> That is the only difference I could find which could make the JAXWS 
>>> client fail.
>> The code is under tcp/http11/filters/ChunkedOutputFilter
>>
>> I suspect that filter is not invoked properly. Is the header properl;y 
>> chunked? If you can send me a test case, I can take a look.
>>
>> Thanks!
>>
>> -- Jeanfrancois
>>
>>> Any suggestion on how I can make the "0\r\n" to be send in another 
>>> (last) chunk?
>>>
>>>
>>> Thanks in advance :)
>>>
>>> --
>>> Yaman
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
For additional commands, e-mail: users-help_at_grizzly.dev.java.net