Re: [jetty-users] ProxyServlet & chunking

[Greg Wilkins]

You are able to call response.flushBuffers() to flush any buffered content.



On Tue, 12 July 2022, 14:25 LP via jetty-users, 
wrote:

> Hi,
>
>   My understanding of HTTP/1.1 chunking is that it's considered to be a
> hop-to-hop feature, and so if the server behind an (Async)ProxyServlet
> responds with a stream of small chunks they can be buffered. This poses a
> challenge for some chunking use-cases, including SSE (Server Sent Events).
> One workaround I found for SSE is to send a large-ish "flush" event with
> some random junk after each "real" event to push the real event through the
> buffer. This works fine when the events aren't too frequent, but it's
> obviously not a great solution.
>
>   Is there any functionality available that allows for setting a timeout
> in the ProxyServlet after which any buffered response content would
> automatically be flushed via chunking? If not, would this be difficult to
> implement?
>
>   Jetty rules!
>
> Thanks,
>   LP
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jetty-users
>
___
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/jetty-users

[jetty-users] ProxyServlet & chunking

[LP via jetty-users]

Hi,

My understanding of HTTP/1.1 chunking is that it's considered to be a 
hop-to-hop feature, and so if the server behind an (Async)ProxyServlet responds 
with a stream of small chunks they can be buffered. This poses a challenge for 
some chunking use-cases, including SSE (Server Sent Events). One workaround I 
found for SSE is to send a large-ish "flush" event with some random junk after 
each "real" event to push the real event through the buffer. This works fine 
when the events aren't too frequent, but it's obviously not a great solution.

Is there any functionality available that allows for setting a timeout in the 
ProxyServlet after which any buffered response content would automatically be 
flushed via chunking? If not, would this be difficult to implement?

Jetty rules!

Thanks,
LP___
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/jetty-users

Re: [jetty-users] incorrect http 200 response while shutting down jetty

[Robben, Bert via jetty-users]

I added a simple unit test now to 
https://github.com/eclipse/jetty.project/issues/8271 that shows the issue.

From: jetty-users  On Behalf Of Robben, Bert 
via jetty-users
Sent: Thursday, 7 July, 2022 4:42 PM
To: JETTY user mailing list 
Cc: Robben, Bert 
Subject: Re: [jetty-users] incorrect http 200 response while shutting down jetty

Done. See 
https://github.com/eclipse/jetty.project/issues/8271

From: jetty-users 
mailto:jetty-users-boun...@eclipse.org>> On 
Behalf Of Joakim Erdfelt
Sent: Thursday, 7 July, 2022 3:49 PM
To: JETTY user mailing list 
mailto:jetty-users@eclipse.org>>
Subject: Re: [jetty-users] incorrect http 200 response while shutting down jetty

This would make for a good issue to open.

Joakim Erdfelt / joa...@webtide.com


On Thu, Jul 7, 2022 at 8:46 AM Robben, Bert via jetty-users 
mailto:jetty-users@eclipse.org>> wrote:
Hi,

We are using the graceful shutdown feature (in other words, we configured our 
Jetty server with the StatisticsHandler as advised in the aftermath of 
https://github.com/eclipse/jetty.project/issues/8210)
 and noticed that a small number of requests are now getting an incorrect HTTP 
200 response. These requests enter the server just after we asked the server to 
stop (by calling Server#stop). The vast majority of requests that enter the 
server after we called stop are terminated with a proper 503. However, 
sometimes, one or two requests get this 200 response. The response is incorrect 
because it's NOT delivered by our REST resources (they return HTTP 204, but 
never HTTP 200), and even worse, our server-side logic for this particular 
request was NOT executed. Before we started using StatisticsHandler we never 
got this.

I did some digging and managed to produce(*) a stack trace that shows that the 
response seems to be written because the statistics handler flushes the 
response buffer.

I think this issue is caused by a race condition where the server is not yet 
shut down in the beginning of StatisticsHandler.handle, but by the time 
execution reaches the end of this method, the server is shutting down.

at org.eclipse.jetty.server.HttpChannel.sendResponse(HttpChannel.java:998)
at org.eclipse.jetty.server.HttpChannel.write(HttpChannel.java:1086)
at org.eclipse.jetty.server.HttpOutput.channelWrite(HttpOutput.java:285)
at org.eclipse.jetty.server.HttpOutput.channelWrite(HttpOutput.java:269)
at org.eclipse.jetty.server.HttpOutput.flush(HttpOutput.java:751)
at org.eclipse.jetty.server.Response.flushBuffer(Response.java:1112)
at 
org.eclipse.jetty.server.handler.StatisticsHandler.handle(StatisticsHandler.java:208)
at 
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:234)
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
at org.eclipse.jetty.server.Server.handle(Server.java:516)
at org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:487)
at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:732)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:479)
at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:277)
at 
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105)
at org.eclipse.jetty.io.ChannelEndPoint$1.run(ChannelEndPoint.java:104)
at 
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:338)
at 
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:315)
at 
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:173)
at 
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:131)
at 
org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:409)
at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:883)
at 
org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1034)
at java.lang.Thread.run(Thread.java:748)

Debug logs are attached for a problematic request/response.