You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Thorsten Höger <li...@hoegernet.de> on 2012/06/08 13:47:07 UTC
Streaming API
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
Re: Streaming API
Posted by Thorsten Höger <li...@hoegernet.de>.
Hi,
it is working with the 2.6.x branch
Thank you very much.
Regards,
Thorsten
Am 12.06.2012 17:09, schrieb Sergey Beryozkin:
> 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
>
>
Re: Streaming API
Posted by Sergey Beryozkin <sb...@gmail.com>.
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
Re: Streaming API
Posted by Daniel Kulp <dk...@apache.org>.
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
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
Re: Streaming API
Posted by Daniel Kulp <dk...@apache.org>.
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.
Actually, just discovered Aegis is 10x worse than JAXB. Aegis calls
"flush" for every single writeEndElement call which would be really bad.
That should be fixed.
Dan
>
>
> 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
Re: Streaming API
Posted by Daniel Kulp <dk...@apache.org>.
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.WrappedOutputStre
> > 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
Re: Streaming API
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi
On 09/06/12 09:44, Thorsten Höger wrote:
> Hi,
>
> 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.WrappedOutputStream
>
> 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
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
Re: Streaming API
Posted by Thorsten Höger <li...@hoegernet.de>.
Hi,
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.WrappedOutputStream
public void flush() throws IOException {
//ignore until we close
// or we'll force chunking and cause all kinds of network packets
}
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
Re: Streaming API
Posted by Daniel Kulp <dk...@apache.org>.
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
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com