>From the Lamina result-channel documentation[1]: A result-channel represents a single potential value, as opposed to a normal channel which represents a stream of values.
The way it works is that the result channel waits for only a single value and then closes. If the connection is closed (you close/reload the tab) then that result channel is also closed. This is why you're only getting that first response. If you want to stream responses, you have to return something that will keep the connection open. This can be a normal lamina channel, but I think you also have input streams, lazy sequences and functions available. Of course, I've only really tested with returning a channel, so I can't confirm the rest. If you want a persistent 2-way connection, look into websockets. You'll end up doing something rather similar with the server-side code, but the clojurescript side can be kinda tricky as the default Closure library didn't include Websocket support. (I believe it's easier to get a later version in more recent releases.) So to wrap up, the channel you get from the handler accepts only a single message. If you want to return multiple messages, enqueue a response map with a new channel as the :body and siphon into that channel. 1: https://github.com/ztellman/lamina/wiki/Result-Channels On Thu, May 3, 2012 at 2:15 AM, Dusan Miloradovic <dusan.milorado...@gmail.com> wrote: > Hmm, > > acording to the aleph documentation: > > A connection to a server is represented by a result-channel. If the > connection is successful, the result-channel will emit a channel that can be > used to communicate with the server. When the connection closes, the channel > will close. > > I thought that the whole point of having the xhr instance in clojurescript > is to have one "persistent" http channel, unlike the regular http. > This is the output from the console after the first(and only) response is > received: > > netstat -a > Active Internet connections (including servers) > Proto Recv-Q Send-Q Local Address Foreign Address (state) > ..the next two are for REPL > tcp4 0 0 localhost.9000 localhost.35075 > ESTABLISHED > tcp4 0 0 localhost.35075 localhost.9000 > ESTABLISHED > ...connection to aleph server remained open, even if the HTTP request iahs > ended: > tcp4 0 0 localhost.8080 localhost.35852 > ESTABLISHED > tcp4 0 0 localhost.35852 localhost.8080 > ESTABLISHED > ... these are for swank > tcp4 0 0 localhost.4005 localhost.51638 > ESTABLISHED > tcp4 0 0 localhost.51638 localhost.4005 > ESTABLISHED > > Also I dont see why this: > > (defn longpoll-new [ch request] > (siphon k ch) ) > > closes the connection, I thought it should safely redirect all the messages > from k. > > What do I miss here? > > Thanks for the help > Dusan > > As you can see the connection from the browser remains. It does close after > 5 minutes though. > > On Thu, May 3, 2012 at 12:36 AM, Daniel Renfer <d...@kronkltd.net> wrote: >> >> I think your issue is, you say you want long polling, but it seems >> like what you're looking for is more of HTTP streaming. The result >> channel you get in the aleph handler is set up to receive only a >> single message and then close. If you want a streaming response, >> create a new channel and a request map with that channel as it's body. >> Enqueue that response map into the result channel and then siphon the >> the messages from your source channel to the "body" channel. >> >> I've found that it's best / you need to put a newline between messages >> so that the response will be properly flushed. >> >> I'm pretty sure I don't need the future, but here's how I've done it. >> >> https://github.com/duck1123/jiksnu/blob/8d66c34f1be8b0b29b0959a18cfdc315346c2bd2/src/jiksnu/actions/stream_actions.clj#L128 >> >> Hope that helps. >> >> On Tue, May 1, 2012 at 7:17 AM, Dusan Miloradovic >> <dusan.milorado...@gmail.com> wrote: >> > Unfortunaltely that does not work either, thank you for the help. It >> > stops >> > receiving after the first message, just like before. Here is the updated >> > version: >> > >> > (defn long-poll-newest >> > ([url callback error-callback] >> > (long-poll-newest url callback error-callback >> > (net/xhr-connection))) >> > ([url callback error-callback xhr1] >> > (do >> > (event/listen xhr1 >> > :success >> > (fn[e] >> > (callback (. xhr1 (getResponseText))) >> > (long-poll-newest url callback error-callback >> > xhr1) >> > >> > )) >> > (event/listen xhr1 >> > :error >> > (fn[e] >> > (when error-callback >> > (println "entered the error callback") >> > (error-callback e) >> > ))) >> > (event/listen xhr1 >> > :timeout >> > (fn[e] >> > (long-poll-newest url callback error-callback >> > xhr1) >> > )) >> > (net/transmit xhr1 url)))) >> > >> > Here is the working version with opening and closing of the connection >> > on >> > every call, at least it should not leak xhr connections: >> > (defn long-poll >> > ([url callback error-callback] >> > (let [kk (net/xhr-connection)] >> > (do >> > (event/listen-once kk >> > :complete >> > (fn[e] >> > (let [isSucc (. kk (isSuccess)) >> > ek (. kk (getLastErrorCode)) >> > isErr (or (= ek ec/EXCEPTION) (= ek >> > ec/HTTP_ERROR))] >> > (do >> > (when isSucc >> > (callback (. kk (getResponseText)))) >> > (. kk (dispose)) >> > (if isErr >> > (error-callback e) >> > (long-poll url callback >> > error-callback)) >> > )))) >> > (net/transmit kk url))) >> > )) >> > >> > Thx >> > >> > >> > >> > >> > On Tue, May 1, 2012 at 2:17 PM, Gijs S. <gijsstuur...@gmail.com> wrote: >> >> >> >> The order of arguments you pass to long-poll-newest doesn't look >> >> right. >> >> >> >> You defined long-poll-newest to optionally take a fourth parameter for >> >> the existing xhr connection. However, when calling long-poll-newest >> >> you pass the existing xhr connection as the first argument. >> >> >> >> Replace >> >> (long-poll-newest xhr1 url callback error-callback) >> >> with >> >> (long-poll-newest url callback error-callback xhr1) >> >> >> >> Also, all of the (do ..)'s are unnecessary. 'let', 'fn' and 'when' >> >> evaluate the body in an implicit 'do' themselves. >> >> >> >> The overall approach to reuse the connection looks fine otherwise. >> >> >> >> -Gijs >> >> >> >> On Apr 30, 12:00 pm, Dusan <dusan.milorado...@gmail.com> wrote: >> >> > I am trying to figure out how to setup the long polling from the >> >> > clojurescript. >> >> > >> >> > I use aleph on the server side. Here is the trivial aleph handler and >> >> > related code: >> >> > >> >> > (def k (permanent-channel)) >> >> > >> >> > (receive-all k (fn[x] (println "got " x))) >> >> > >> >> > (defn longpoll-new [ch request] >> >> > (siphon k ch) >> >> > ) >> >> > >> >> > (defn send-mes [k mes] >> >> > (enqueue k ((comp r/response pr-str) mes))) >> >> > >> >> > On the clojurescript side I am trying to open one xhr connection, and >> >> > use >> >> > it for all subsequent calls: >> >> > >> >> > (defn long-poll-newest >> >> > ([url callback error-callback] >> >> > (long-poll-newest url callback error-callback >> >> > (net/xhr-connection))) >> >> > ([url callback error-callback xhr1] >> >> > (do >> >> > (event/listen xhr1 >> >> > :success >> >> > (fn[e] >> >> > (do >> >> > (callback (. xhr1 (getResponseText))) >> >> > (long-poll-newest xhr1 url callback >> >> > error-callback) >> >> > ))) >> >> > (event/listen xhr1 >> >> > :error >> >> > (fn[e] >> >> > (when error-callback >> >> > (do >> >> > (println "entered the error callback") >> >> > (error-callback e) >> >> > ) >> >> > ))) >> >> > (event/listen xhr1 >> >> > :timeout >> >> > (fn[e] >> >> > (do >> >> > (long-poll-newest xhr1 url callback >> >> > error-callback) >> >> > ) >> >> > )) >> >> > (net/transmit xhr1 url)) >> >> > )) >> >> > >> >> > Unfiortunatelly, this receives just the first message from server, >> >> > and >> >> > then >> >> > it stops. >> >> > >> >> > This is the version that is working: >> >> > (defn long-poll [url callback error-callback] >> >> > (let [xhr1 (net/xhr-connection)] >> >> > (do >> >> > (event/listen xhr1 >> >> > :success >> >> > (fn[e] >> >> > (do >> >> > (callback (. xhr1 (getResponseText))) >> >> > (long-poll url callback error-callback) >> >> > ))) >> >> > (event/listen xhr1 >> >> > :error >> >> > (fn[e] >> >> > (when error-callback >> >> > (do >> >> > (println "entered the error callback") >> >> > (error-callback e) >> >> > ) >> >> > ))) >> >> > (event/listen xhr1 >> >> > :timeout >> >> > (fn[e] >> >> > (do >> >> > (long-poll url callback error-callback) >> >> > ) >> >> > )) >> >> > (net/transmit xhr1 url)))) >> >> > >> >> > In this version I am closing the original xhr, I am creating the new >> >> > one >> >> > for each request. >> >> > How can I make the first version functional, what do I miss? >> >> > >> >> > Dusan >> >> >> >> -- >> >> You received this message because you are subscribed to the Google >> >> Groups "Clojure" group. >> >> To post to this group, send email to clojure@googlegroups.com >> >> Note that posts from new members are moderated - please be patient with >> >> your first post. >> >> To unsubscribe from this group, send email to >> >> clojure+unsubscr...@googlegroups.com >> >> For more options, visit this group at >> >> http://groups.google.com/group/clojure?hl=en >> > >> > >> > -- >> > You received this message because you are subscribed to the Google >> > Groups "Clojure" group. >> > To post to this group, send email to clojure@googlegroups.com >> > Note that posts from new members are moderated - please be patient with >> > your >> > first post. >> > To unsubscribe from this group, send email to >> > clojure+unsubscr...@googlegroups.com >> > For more options, visit this group at >> > http://groups.google.com/group/clojure?hl=en >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clojure@googlegroups.com >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+unsubscr...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en > > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
