Mailing-List: contact users-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@cxf.apache.org
Received-SPF: pass (nike.apache.org: domain of sberyozkin@gmail.com designates
 209.85.215.169 as permitted sender)
Message-ID: <4FD75B8F.6030303@gmail.com>
Date: Tue, 12 Jun 2012 16:09:03 +0100
From: Sergey Beryozkin <sberyozkin@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: users@cxf.apache.org
CC: Daniel Kulp <dkulp@apache.org>
Subject: Re: Streaming API
References: <4FD1E63B.9060306@hoegernet.de> <4FD5E5EB.4050107@gmail.com>
 <1493348.NzgvIQLXYd@dilbert.dankulp.com>
 <1649319.4MHxUC79TO@dilbert.dankulp.com>
In-Reply-To: <1649319.4MHxUC79TO@dilbert.dankulp.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Hi
On 11/06/12 22:26, Daniel Kulp wrote:
>
> I went ahead and implemented this on trunk and 2.6.x.   It would be great if
> someone could try the JAX-RS streaming stuff with tomorrows snapshot to make
> sure it really solves the problem.
>
Dan, thanks for taking care of it, my test shows the problem is fixed, 
here is the code:

@Produces(MediaType.TEXT_PLAIN)
@Path("/stream")
public StreamingOutput stream() {
            StreamingOutput so = new StreamingOutput() {

             public void write(final OutputStream output) throws 
IOException, WebApplicationException {
                                     int count = 0;
                                     while (count < 5) {
                                                    count++;
                                                    final String m = 
"Message " + count + "\r\n";
 
output.write(m.getBytes("UTF-8"));
                                                     output.flush();

                                                     Thread.sleep(1000);

                                     }

                             }

            };

            return so;
     }

and the curl trace:

GET /bookstore/stream HTTP/1.1
 > User-Agent: curl/7.21.6 (x86_64-pc-linux-gnu) libcurl/7.21.6 
OpenSSL/1.0.0e zlib/1.2.3.4 libidn/1.22 librtmp/2.3
 > Host: localhost:8080
 > Accept: */*
 >
< HTTP/1.1 200 OK
< Content-Type: text/plain
< Date: Tue, 12 Jun 2012 15:04:14 GMT
< Transfer-Encoding: chunked
< Server: Jetty(7.5.4.v20111024)
<
Message 1
Message 2
Message 3
Message 4
Message 5
* Connection #0 to host localhost left intact
* Closing connection #0

the code:

Torsten, please try the snapshots with your own tests

Thanks, Sergey

> Dan
>
>
> On Monday, June 11, 2012 11:33:28 AM Daniel Kulp wrote:
>> On Monday, June 11, 2012 01:34:51 PM Sergey Beryozkin wrote:
>>> On 09/06/12 09:44, Thorsten H�ger wrote:
>>>> I tried using the StreamingOutput and it did not work either.
>>>> But I stepped through the code and found an interesting piece in the
>>>> CXF
>>>> HTTP Transport:
>>>> org.apache.cxf.transport.http.AbstractHTTPDestination.WrappedOutputStr
>>>> e
>>>> am>
>>>>
>>>>           public void flush() throws IOException {
>>>>
>>>>               //ignore until we close
>>>>               // or we'll force chunking and cause all kinds of network
>>>>               packets
>>>>
>>>>           }
>>>
>>> We can introduce a property which can be used to let the flush() to
>>> delegate, I'll experiment with your code a bit later and update you
>>
>> Well, I was thinking something slightly different...  Basically, we block
>> that flush there as using JAXB databinding with the XMLStreamWriters
>> causes some in-opportune flushes resulting in extra chunks and network
>> packets. Thus, My THOUGHT would be to remove that line from
>> AbstractHTTPDestination and instead move it into the StaxOutInterceptor
>> where we create the XMLStreamWriter.   Basically, take the original
>> OutputStream, wrap it with a new output stream that traps the flush, then
>> create XMLStreamWriter.    For code paths that don't go thought the
>> StaxOutInterceptor, they would be un- affected.
>>
>>
>> Dan
>>
>>> Cheers, Sergey
>>>
>>>> This is part of the class the StreamingOutput gets as parameter in its
>>>> write method.
>>>>
>>>> Regards,
>>>> Thorsten
>>>>
>>>> Am 08.06.2012 19:39, schrieb Daniel Kulp:
>>>>> Well, I know why it's NOT working.....   With the PipedIn/Out things,
>>>>> CXF
>>>>> pretty much sits in a loop reading from the InputStream and writing
>>>>> to
>>>>> the HTTP OutputStream.   Since there is no way to know that you
>>>>> requested a "flush" in there, that loop just loops until the close at
>>>>> which point it would flush and close the output.
>>>>>
>>>>> You may need to wait for Sergey to be back next week, but you COULD
>>>>> look at returning a "StreamingOutput" object where you could get the
>>>>> raw OutputStream and do the periodic writes as needed.     With my
>>>>> few
>>>>> minutes of research, that's what I came up with.  :-)   Sergey may
>>>>> have better ideas.
>>>>>
>>>>> Dan
>>>>>
>>>>> On Friday, June 08, 2012 01:47:07 PM Thorsten H�ger wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I'm currently devloping a REST API for our software and I need
>>>>>> streaming
>>>>>> functionality.
>>>>>>
>>>>>> I'm using CXF with Jetty and wiring with Spring.
>>>>>>
>>>>>> I tried it with the attached code, but if I do a curl on the address
>>>>>> ti
>>>>>> blocks until Message 5 and the prints all lines.
>>>>>>
>>>>>> I expected it to print each line on its own with 1 second break.
>>>>>>
>>>>>> Can anybody give me a hint what I am doing wrong?
>>>>>>
>>>>>> Regards and thanks
>>>>>>
>>>>>> Thorsten


-- 
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Blog: http://sberyozkin.blogspot.com