Thanks for great answers Daniel and Zach Dusan
On Fri, May 4, 2012 at 3:28 PM, Zach Tellman <ztell...@gmail.com> wrote: > That documentation is for the Lamina library, and describes how > full-duplex client connections are represented. If you created a TCP > client, all that would be true. > > However, you are writing a server, and using HTTP, which is a much more > structured protocol. Each request takes only a single response, which > means that the 'ch' given to the handler function can only accept a single > response value. The XHR mechanism exists to allow long gaps between > request and response, but still only supports single messages back and > forth. There exist protocols that emulate a full-duplex mechanism on top > of HTTP, such as socket.io, but Aleph doesn't currently support that. > > However, if you opened a WebSocket connection to the server, and set > :websocket to true in the server parameters, the 'ch' *would* be a > full-duplex connection. Based on my understanding of what you're trying to > do, that may be a good solution. > > Zach > > > On Thursday, May 3, 2012 11:45:50 AM UTC+5:30, Dusan wrote: >> >> Hmm, >> >> acording to the aleph documentation: >> >> A connection to a server is represented by a >> result-channel<https://github.com/ztellman/lamina/wiki/Result-Channels>. >> 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/** >>> 8d66c34f1be8b0b29b0959a18cfdc3**15346c2bd2/src/jiksnu/actions/** >>> stream_actions.clj#L128<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+unsubscribe@**googlegroups.com<clojure%2bunsubscr...@googlegroups.com> >>> >> For more options, visit this group at >>> >> http://groups.google.com/**group/clojure?hl=en<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+unsubscribe@**googlegroups.com<clojure%2bunsubscr...@googlegroups.com> >>> > For more options, visit this group at >>> > http://groups.google.com/**group/clojure?hl=en<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+unsubscribe@**googlegroups.com<clojure%2bunsubscr...@googlegroups.com> >>> For more options, visit this group at >>> http://groups.google.com/**group/clojure?hl=en<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
