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
