Configurable HTTP response buffering in Aleph

[Shantanu Kumar]

Hi,

I noticed that when I return ring response :body as InputStream, the response buffering in Aleph 0.4.0 is higher than in 0.3.2 -- is there a way I can configure response buffering, especially on a per request basis?

I know `aleph.http/connection-pool` accepts a kwarg :response-buffer-size, but I'm not yet sure whether that can do the job, or how to use it.

Shantanu

[Zach Tellman]

You cannot set it per-request.  It's a per-connection setting, and many different requests may share the same connection, so I made it a parameter for a connection pool.  You can, however, define multiple connection pools with different buffer sizes and specify :pool on a per-request basis.

--
You received this message because you are subscribed to the Google Groups "Aleph" group.
To unsubscribe from this group and stop receiving emails from it, send an email to aleph-lib+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Shantanu Kumar]

I failed to mention in my original post that I am trying to control response buffering on an HTTP server implemented using Aleph. My ring handler returns InputStream as body. Does `aleph.http/start-server` accept any argument to control response buffering? Is `aleph.http/connection-pool` useful in a server use case?

Shantanu

[Zach Tellman]

I'm sorry, I misread your question.  The chunk size for responses is hard-coded to 8192 bytes here: https://github.com/ztellman/aleph/blob/master/src/aleph/http/core.clj#L279.  This is a pretty typical size for sending HTTP chunks, but I could definitely make it configurable.  Can you describe your use case so I can get an idea of what I need to support?

Zach

[Shantanu Kumar]

I am trying to implement Server-sent Events stream using Aleph. I tried https://github.com/josephwilk/hystrix-event-stream-clj#usage-with-nettycompojure but it does not seem to stop the server side when the client disconnects. Returning InputStream as :body stops the server when the client does, but buffering makes it bursty. Making it possible to call a cleanup function on disconnect would be great.

Shantanu

[Zach Tellman]

Why use an InputStream, and not a Manifold stream?  That will let you send messages of any size (each message will be sent immediately), and better hooks into the lifecycle of the connection.

[Shantanu Kumar]

Thanks for the tip! I got it working with Aleph4 and Manifold. When the client disconnects, `manifold.stream/on-closed` handles it fine. I get the following stack trace in logs but I can ignore that.

Oct 25, 2015 8:35:47 AM clojure.tools.logging$eval1191$fn__1195 invoke

SEVERE: error in message propagation

io.netty.handler.codec.EncoderException: java.lang.IllegalStateException: unexpected message type: DefaultHttpContent

at io.netty.handler.codec.MessageToMessageEncoder.write(MessageToMessageEncoder.java:107)

at io.netty.channel.ChannelHandlerInvokerUtil.invokeWriteNow(ChannelHandlerInvokerUtil.java:158)

at io.netty.channel.DefaultChannelHandlerInvoker$WriteTask.run(DefaultChannelHandlerInvoker.java:440)

at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:322)

at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:356)

at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:703)

at io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:137)

at java.lang.Thread.run(Thread.java:745)

Caused by: java.lang.IllegalStateException: unexpected message type: DefaultHttpContent

at io.netty.handler.codec.http.HttpObjectEncoder.encode(HttpObjectEncoder.java:92)

at io.netty.handler.codec.MessageToMessageEncoder.write(MessageToMessageEncoder.java:89)

... 7 more

Shantanu

[Zach Tellman]

I'll look into that, you shouldn't be seeing any exceptions.