[ring-jetty-adapter] No control over exceptions thrown when obtaining item from ISeq response body

[kumarshantanu]

Consider the following code returning an ISeq body that throws after some iterations:

(defn now-millis [] (str "data:" (System/currentTimeMillis) "\n\n"))

(def counter (atom 0))

(defn now-throw []
  (swap! counter inc)
  (if (< @counter 5000) "" (throw (ex-info "Test exception" {}))))

(def body (->> (repeat now-millis)
               (interpose now-throw)
               (map (fn [f] (f)))
               lazy-seq))

(defn handler [request]
  {:status 200
   :headers {"Content-Type" "text/event-stream"
             "Cache-Control" "no-cache"
             "Connection" "keep-alive"}
   :body body})

When I use Curl (acceptable result):

$ curl localhost:8082

data:1751448129717

data:1751448129717
...
...
curl: (18) transfer closed with outstanding read data remaining

At the server end, I see this exception logged (acceptable result):

[qtp1107779742-52] WARN org.eclipse.jetty.ee9.nested.HttpChannel - /
clojure.lang.ExceptionInfo: Test exception {}
    <stack-trace>

The issue is: I do not have control over how to perform cleanup actions when such an exception is thrown.

[weavejester]

Have you considered writing middleware or a custom StreamableResponsebody to catch the exception?

[kumarshantanu]

I have considered middleware/StreamableResponseBody approaches - below are the challenges I realized:

1. Once a lazy-sequence (of values) is produced, any associated exception won't surface until a value is produced/obtained. This forces a middleware to operate in eager mode as opposed to lazy mode, which prevents it from streaming the body without resorting to StreamableResponseBody.
2. A lazy-sequence of functions is amenable to be treated with a middleware, because a function may be produced/obtained without exception and only its invocation throws an exception. However, it only works on a sequence of functions.
3. Though StreamableResponseBody is the recommended way to return a streamable body, its uptake is not high yet - I have found only ring-jetty-adapter to be supporting it as of now. The ISeq body type has a wider support as an alternative. Code targeting multiple adapters is constrained to opt for wider support.

The above points are applicable when the entire application (how the body is produced, or which adapter is used) is not under one person's or team's control.

[weavejester]

As well as Ring itself, rj9a also supports StreamableResponseBody, and I'm currently working on adding support to http-kit. If you know of any other Ring adapters in active development, please let me know, or open up an issue on their repository.

However, on this repository in particular your problem already has a solution that's been implemented and released. I don't know what more I can do to solve this issue, short of continuing to help third-party adapters fully implement the Ring spec.

If you're writing a third-party library, my advice would be to use StreamableResponseBody. If people say "I want to use your library with adapter X but it doesn't support that protocol", then that sounds to me like an issue with the adapter.

[kumarshantanu]

Issues filed to support StreamableResponseBody:

• Add support for async handlers and StreamableResponseBody igrishaev/ring-jdk-adapter#2
• Add support for StreamableResponseBody clj-commons/aleph#758

@weavejester Thank you for your work on Ring and http-kit/http-kit#587 (that you linked above) - I really appreciate it.