Re: lein repl timeout
Success! I checked the modification times on my hosts files. Apparently some process must have truncated my hosts file a couple days ago. There was a hosts~orig file, which I copied over, and all is well again :-) Cheers, Neil On Sunday, November 23, 2014 9:49:43 PM UTC, Neil Laurance wrote: Thanks Colin. I'll post back here if I make any progress. Cheers Neil -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: lein repl timeout
Thanks Colin. I'll post back here if I make any progress. Cheers Neil -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
lein repl timeout
Hi there. Hope someone can help me with an issue I am having with lein repl. I did post on StackOverflow http://stackoverflow.com/questions/22736952/lein-repl-server-launch-timed-out as well, but no luck there yet. I have been using lein from my home Mac for quite some time, but hadn't started a repl for a couple of days. When I came back to use lein repl again, it now fails with a timeout. *Based on a hunch from another post, I managed to find a workaround of turning off my wifi which seems to resolve things ?!?* But if anyone can help me with a better solution, that would be appreciated. The lein version I am using is: Leiningen 2.5.0 on Java 1.7.0_11 Java HotSpot(TM) 64-Bit Server VM I took a thread dump https://gist.github.com/toolkit/59da0b05931a490253b4, which showed 'Thread-4' attempting to make a socket connection. Thread-4 prio=5 tid=0x7ffb6a0a nid=0x2707 runnable [0x000114aa8000] java.lang.Thread.State: RUNNABLE at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339) - locked 0x0007f80aa8a8 (a java.net.SocksSocketImpl) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:391) at java.net.Socket.connect(Socket.java:579) at java.net.Socket.connect(Socket.java:528) at java.net.Socket.init(Socket.java:425) at java.net.Socket.init(Socket.java:208) at clojure.tools.nrepl$connect.doInvoke(nrepl.clj:184) This thread then throws an exception which is logged to console: Exception in thread Thread-4 java.net.ConnectException: Operation timed out at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java: 339) at java.net.AbstractPlainSocketImpl.connectToAddress( AbstractPlainSocketImpl.java:200) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java: 182) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:391) at java.net.Socket.connect(Socket.java:579) at java.net.Socket.connect(Socket.java:528) at java.net.Socket.init(Socket.java:425) at java.net.Socket.init(Socket.java:208) at clojure.tools.nrepl$connect.doInvoke(nrepl.clj:184) at clojure.lang.RestFn.invoke(RestFn.java:421) at clojure.tools.nrepl.ack$send_ack.invoke(ack.clj:47) at clojure.tools.nrepl.server$start_server.doInvoke(server.clj:153) at clojure.lang.RestFn.invoke(RestFn.java:619) at user$eval2869.invoke(NO_SOURCE_FILE:0) at clojure.lang.Compiler.eval(Compiler.java:6703) at clojure.lang.Compiler.eval(Compiler.java:6693) at clojure.lang.Compiler.eval(Compiler.java:6693) at clojure.lang.Compiler.eval(Compiler.java:) at clojure.core$eval.invoke(core.clj:2927) at leiningen.core.eval$fn__6742.invoke(eval.clj:314) at clojure.lang.MultiFn.invoke(MultiFn.java:231) at leiningen.core.eval$eval_in_project.invoke(eval.clj:337) at leiningen.repl$server$fn__10685.invoke(repl.clj:229) at clojure.lang.AFn.applyToHelper(AFn.java:152) at clojure.lang.AFn.applyTo(AFn.java:144) at clojure.core$apply.invoke(core.clj:624) at clojure.core$with_bindings_STAR_.doInvoke(core.clj:1862) at clojure.lang.RestFn.invoke(RestFn.java:425) at clojure.lang.AFn.applyToHelper(AFn.java:156) at clojure.lang.RestFn.applyTo(RestFn.java:132) at clojure.core$apply.invoke(core.clj:628) at clojure.core$bound_fn_STAR_$fn__4140.doInvoke(core.clj:1884) at clojure.lang.RestFn.invoke(RestFn.java:397) at clojure.lang.AFn.run(AFn.java:22) at java.lang.Thread.run(Thread.java:722) ... some time later ... REPL server launch timed out. Thanks, Neil -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: lein repl timeout
Hi Neil, This looks like an issue a user had with Cursive a while ago, which I never totally got to the bottom of. See https://groups.google.com/d/topic/clojure-tools/lmjCX3AjAfE/discussion and the associated GitHub issue. In particular, guns wrote a really useful mail which for some reason doesn't appear in the Google groups thread, but you can see it in my reply here: https://groups.google.com/d/msg/clojure-tools/lmjCX3AjAfE/PV7W_-oefVYJ Cheers, Colin On 22 November 2014 at 20:23, Neil Laurance neil.laura...@gmail.com wrote: Hi there. Hope someone can help me with an issue I am having with lein repl. I did post on StackOverflow http://stackoverflow.com/questions/22736952/lein-repl-server-launch-timed-out as well, but no luck there yet. I have been using lein from my home Mac for quite some time, but hadn't started a repl for a couple of days. When I came back to use lein repl again, it now fails with a timeout. *Based on a hunch from another post, I managed to find a workaround of turning off my wifi which seems to resolve things ?!?* But if anyone can help me with a better solution, that would be appreciated. The lein version I am using is: Leiningen 2.5.0 on Java 1.7.0_11 Java HotSpot(TM) 64-Bit Server VM I took a thread dump https://gist.github.com/toolkit/59da0b05931a490253b4, which showed 'Thread-4' attempting to make a socket connection. Thread-4 prio=5 tid=0x7ffb6a0a nid=0x2707 runnable [0x000114aa8000] java.lang.Thread.State: RUNNABLE at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339) - locked 0x0007f80aa8a8 (a java.net.SocksSocketImpl) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:391) at java.net.Socket.connect(Socket.java:579) at java.net.Socket.connect(Socket.java:528) at java.net.Socket.init(Socket.java:425) at java.net.Socket.init(Socket.java:208) at clojure.tools.nrepl$connect.doInvoke(nrepl.clj:184) This thread then throws an exception which is logged to console: Exception in thread Thread-4 java.net.ConnectException: Operation timed out at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl. java:339) at java.net.AbstractPlainSocketImpl.connectToAddress( AbstractPlainSocketImpl.java:200) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java: 182) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:391) at java.net.Socket.connect(Socket.java:579) at java.net.Socket.connect(Socket.java:528) at java.net.Socket.init(Socket.java:425) at java.net.Socket.init(Socket.java:208) at clojure.tools.nrepl$connect.doInvoke(nrepl.clj:184) at clojure.lang.RestFn.invoke(RestFn.java:421) at clojure.tools.nrepl.ack$send_ack.invoke(ack.clj:47) at clojure.tools.nrepl.server$start_server.doInvoke(server.clj:153) at clojure.lang.RestFn.invoke(RestFn.java:619) at user$eval2869.invoke(NO_SOURCE_FILE:0) at clojure.lang.Compiler.eval(Compiler.java:6703) at clojure.lang.Compiler.eval(Compiler.java:6693) at clojure.lang.Compiler.eval(Compiler.java:6693) at clojure.lang.Compiler.eval(Compiler.java:) at clojure.core$eval.invoke(core.clj:2927) at leiningen.core.eval$fn__6742.invoke(eval.clj:314) at clojure.lang.MultiFn.invoke(MultiFn.java:231) at leiningen.core.eval$eval_in_project.invoke(eval.clj:337) at leiningen.repl$server$fn__10685.invoke(repl.clj:229) at clojure.lang.AFn.applyToHelper(AFn.java:152) at clojure.lang.AFn.applyTo(AFn.java:144) at clojure.core$apply.invoke(core.clj:624) at clojure.core$with_bindings_STAR_.doInvoke(core.clj:1862) at clojure.lang.RestFn.invoke(RestFn.java:425) at clojure.lang.AFn.applyToHelper(AFn.java:156) at clojure.lang.RestFn.applyTo(RestFn.java:132) at clojure.core$apply.invoke(core.clj:628) at clojure.core$bound_fn_STAR_$fn__4140.doInvoke(core.clj:1884) at clojure.lang.RestFn.invoke(RestFn.java:397) at clojure.lang.AFn.run(AFn.java:22) at java.lang.Thread.run(Thread.java:722) ... some time later ... REPL server launch timed out. Thanks, Neil -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com
Clutch timeout problem
I asked this in the Clutch group, before I realized the last time anyone else had posted there was last year... I have some code that connects to a CouchDB server using Clutch (https://github.com/clojure-clutch/clutch). I recently changed the connection to use a non-local connection, i.e. (def db (clutch/get-database http://ip addres:port/db)) instead of (def db (clutch/get-database db)) Since doing so, I've gotten the following error: ConnectTimeoutException Connect to ip address:port timed out org.apache .http.conn.scheme.PlainSocketFactory.connectSocket(PlainSocketFactory.java: 119) The CouchDB server is on my local home network, which isn't the best (local SSH connections get dropped, etc.) Is there anything I can do to fix my timeout problems? I'd really rather not have to wrap everything in try/catch blocks, if I can possibly avoid it. -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Unexpected core.async timeout behaviour
Dredging this back up, you've read the scenario properly. Timers are coalesced a particular resolution. Use cases needing more than 1024 active handles on a channel can use a mult. For example, if you had to timeout every request at a same time exactly 5 minutes in the future, (mult (timeout 30)) and then give every request a fresh tap of that. The fixed 100 case I think you're getting lucky, whereas the random window you're getting unfavorable coalescing, which seems counterintuitive. On Friday, March 28, 2014 9:52:47 AM UTC-4, Peter Taoussanis wrote: One thing I'm not clear on: if I've understood your explanation correctly, I would expect the 100ms timeout to produce this error _more_ (not less) often. So can I just confirm some things here? 1. `async/timeout` calls can (always?) get cached to the nearest TIMEOUT_RESOLUTION_MS. 2. In this tight loop example, that means that `!` is sometimes getting called against the same (cached) timeout channel. 3. It's happening sufficiently often (do to the high loop count+speed) to overflow the [unbuffered] timeout channel's implicit take buffer. Is that all right? If so, why isn't the fixed `(async/timeout 100)` channel producing the same (or worse) behaviour? Is something preventing it from being cached in the same way? -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Unexpected core.async timeout behaviour
Hi all, quick question: `(dotimes [_ 5] (go (! (async/timeout 100` runs as expected. `(dotimes [_ 5] (go (! (async/timeout (+ 50 (rand-int 100))` produces an error: ( (.size takes) impl/MAX-QUEUE-SIZE) java.lang.AssertionError: Assert failed: No more than 1024 pending takes are allowed on a single channel. It appears (?) that there's a (surprisingly low?) limit to the number of unique timeout timestamps that can be simultaneously queued. Is this the expected behaviour running Clojure 1.6.0, core.async 0.1.278.0-76b25b-alpha? Much appreciated, thanks! Cheers :-) -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Unexpected core.async timeout behaviour
Hi Peter, On Fri, Mar 28, 2014 at 2:48 AM, Peter Taoussanis ptaoussa...@gmail.com wrote: Hi all, quick question: `(dotimes [_ 5] (go (! (async/timeout 100` runs as expected. `(dotimes [_ 5] (go (! (async/timeout (+ 50 (rand-int 100))` produces an error: ( (.size takes) impl/MAX-QUEUE-SIZE) java.lang.AssertionError: Assert failed: No more than 1024 pending takes are allowed on a single channel. It appears (?) that there's a (surprisingly low?) limit to the number of unique timeout timestamps that can be simultaneously queued. Is this the expected behaviour running Clojure 1.6.0, core.async 0.1.278.0-76b25b-alpha? Much appreciated, thanks! Cheers :-) I _still_ have no personal experience with core.async ( :((( ), but I did spot this message coming through recently which answers your question with 'yes' I believe. https://groups.google.com/forum/#!searchin/clojure/1024/clojure/NIPIzJ7l6RA/Idm1_2GMlCMJ It sounds like you need to use a different kind of channel buffer (whatever that means :). -- In Christ, Timmy V. http://blog.twonegatives.com/ http://five.sentenc.es/ -- Spend less time on mail -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Unexpected core.async timeout behaviour
Hi Tim, thanks for the info! It's not clear to me that this is the same issue, unfortunately. (Though I may be missing something obvious). In the example I've provided above, we're actually creating a _new_ channel for each take. The problem appears to be either some interaction between the loop and core.async that I'm not aware of, or something on the _implementation-end_ that is bumping up against the referenced issue (i.e. an insufficiently-buffered channel somewhere). So there's actually no channel here that I could be buffering, since it's not my channel that's overflowing. Again, modulo me missing something obvious :-) Does that make sense? -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Unexpected core.async timeout behaviour
On Fri, Mar 28, 2014 at 8:08 AM, Peter Taoussanis ptaoussa...@gmail.com wrote: Hi Tim, thanks for the info! It's not clear to me that this is the same issue, unfortunately. (Though I may be missing something obvious). In the example I've provided above, we're actually creating a _new_ channel for each take. The problem appears to be either some interaction between the loop and core.async that I'm not aware of, or something on the _implementation-end_ that is bumping up against the referenced issue (i.e. an insufficiently-buffered channel somewhere). So there's actually no channel here that I could be buffering, since it's not my channel that's overflowing. Again, modulo me missing something obvious :-) Does that make sense? Ah, forgive me for not seeing the subtlety and getting excited about being able to help in some small way on a core.async problem. :) Can one of the adults chime in? -- In Christ, Timmy V. http://blog.twonegatives.com/ http://five.sentenc.es/ -- Spend less time on mail -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Unexpected core.async timeout behaviour
Please, not at all! Appreciate any ideas :-) -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Unexpected core.async timeout behaviour
Okay, fantastic - appreciate the detailed info Timothy! This did actually came up in staging today; reduced it to the toy example here. Now that I understand what's happening, let me think about it a little and get back to you. BTW I don't think I've ever thanked you personally for your work on core.async. It's incredible, a real game changer and a pleasure to work with - so thank you. -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Unexpected core.async timeout behaviour
One thing I'm not clear on: if I've understood your explanation correctly, I would expect the 100ms timeout to produce this error _more_ (not less) often. So can I just confirm some things here? 1. `async/timeout` calls can (always?) get cached to the nearest TIMEOUT_RESOLUTION_MS. 2. In this tight loop example, that means that `!` is sometimes getting called against the same (cached) timeout channel. 3. It's happening sufficiently often (do to the high loop count+speed) to overflow the [unbuffered] timeout channel's implicit take buffer. Is that all right? If so, why isn't the fixed `(async/timeout 100)` channel producing the same (or worse) behaviour? Is something preventing it from being cached in the same way? -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Unexpected core.async timeout behaviour
This is a caused by an interesting interaction of two things: 1) channels can have no more than 1024 pending takes at a time. and 2) (timeout) caches it's return value for a given ms + window size of time. At the moment, window is about 5-10ms. This error message is normally the result of a bug. That is to say, if you have 1024 pending (not buffered, but actual blocking) takes/puts, then normally your system is not considering back pressure in some way. So we created an arbitrary limit imposed to keep people from writing bad code. If you think of it, pending takes/puts can create unbounded queues on the input/output of a channel. This is an attempt to make that queue size bounded. However, in your problem you have something else going on as well. In order to make calls to timeout fast inside an inner loop, timeout will often return the same channel from more than one call to the function. So if you call timeout every millisecond, you'll get the same channel about 5-10 times. This increases performance, and since the timeout logic involved isn't highly accurate anyways this performance optimization rarely causes very many problems. If this is causing a problem in an actual system I'd love to hear about it. Neither of these issues are caused by hard limits in the design of core.async. So they could be tweaked, but we'll probably only do so if we have a concrete example of a problem. So a use case would be needed, instead of an arbitrary failing test case. Timothy On Fri, Mar 28, 2014 at 6:21 AM, Peter Taoussanis ptaoussa...@gmail.comwrote: Please, not at all! Appreciate any ideas :-) -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- One of the main causes of the fall of the Roman Empire was that-lacking zero-they had no way to indicate successful termination of their C programs. (Robert Firth) -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Possible core.async timeout issue
Good day everyone, I inadvertently passed a double to a timeout channel and discovered the following behavior: user= (require '[clojure.core.async :as a]) nil user= (a/timeout 100.0) #ManyToManyChannel clojure.core.async.impl.channels.ManyToManyChannel@1009d11d user= Exception in thread clojure.core.async.timers/timeout-daemon java.lang.ClassCastException: java.lang.Double cannot be cast to java.lang.Long at java.lang.Long.compareTo(Long.java:50) at java.util.concurrent.ConcurrentSkipListMap.doRemove(ConcurrentSkipListMap.java:1064) at java.util.concurrent.ConcurrentSkipListMap.remove(ConcurrentSkipListMap.java:1896) at clojure.core.async.impl.timers$timeout_worker.invoke(timers.clj:61) at clojure.lang.AFn.run(AFn.java:24) at java.lang.Thread.run(Thread.java:722) user= (.isAlive clojure.core.async.impl.timers/timeout-daemon) false I'm using 0.1.242.0-44b1e3-alpha. -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
core.async timeout channels are values - is this intended
Hi all,
I ran into a core.async behaviour that confused me a bit the other day. In
some of our systems, we need to fire different timeouts, perform actions
and schedule a new timeout. The problem is, that if the timeouts are of the
same number of ms, we can't distinguish them, and therefore not keep track
of and remove them from a set (at least not easily).
That sounds a bit fuzzy. Hopefully this spike will make it clearer what I'm
trying to say:
(require '[clojure.core.async :refer [chan timeout alts!! alts!]])
(= (chan) (chan))
;; false
(= (timeout 1) (timeout 2))
;; false
(= (timeout 1) (timeout 1))
;; true
(do (loop [ch-v (into {} (for [v [1 2 3]] [(timeout 1000) v]))]
(when-let [chs (keys ch-v)]
(let [[_ ch] (alts!! chs)]
(println (ch-v ch))
(recur (dissoc ch-v ch)
(println done))
;; only fires 3, the last channel in the map
The intended behaviour of the last loop is to print 1, 2 and 3 (not
necessarily in that order). However, the ch-v map will only contain one
key, as timeouts with the same duration are considered the same value. In
the real example, a new timeout with the same value should be scheduled
again, by being put in the map.
So, my questions are:
- Is this intended behaviour?
- Is there a different pattern for achieving the scheduling behaviour I'm
looking for?
Thanks for your help,
Thomas
--
--
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 unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: core.async timeout channels are values - is this intended
The reason = considers you timeout channels to be equal is that they
are, in fact, the same object. In fact, they may end up being the same
object even with different timeout values:
(identical? (timeout 1) (timeout 2))
;= true
Except I got a false just now with a fresh REPL and same timeout
value... All subsequent invocations return true though, and I'm sure
with a little digging the reason for the false would become clear.
The reason for them being the same object is that timeout goes out of
its way to avoid creating to many timeout channels and will reuse
existing ones if their timeouts are due within a small amount of time
(clojure.core.async.impl.timers/TIMEOUT_RESOLUTION_MS, currently 10
ms) of the requested timeout.
Cheers,
Michał
On 20 November 2013 10:08, Thomas G. Kristensen
thomas.g.kristen...@gmail.com wrote:
Hi all,
I ran into a core.async behaviour that confused me a bit the other day. In
some of our systems, we need to fire different timeouts, perform actions and
schedule a new timeout. The problem is, that if the timeouts are of the same
number of ms, we can't distinguish them, and therefore not keep track of and
remove them from a set (at least not easily).
That sounds a bit fuzzy. Hopefully this spike will make it clearer what I'm
trying to say:
(require '[clojure.core.async :refer [chan timeout alts!! alts!]])
(= (chan) (chan))
;; false
(= (timeout 1) (timeout 2))
;; false
(= (timeout 1) (timeout 1))
;; true
(do (loop [ch-v (into {} (for [v [1 2 3]] [(timeout 1000) v]))]
(when-let [chs (keys ch-v)]
(let [[_ ch] (alts!! chs)]
(println (ch-v ch))
(recur (dissoc ch-v ch)
(println done))
;; only fires 3, the last channel in the map
The intended behaviour of the last loop is to print 1, 2 and 3 (not
necessarily in that order). However, the ch-v map will only contain one
key, as timeouts with the same duration are considered the same value. In
the real example, a new timeout with the same value should be scheduled
again, by being put in the map.
So, my questions are:
- Is this intended behaviour?
- Is there a different pattern for achieving the scheduling behaviour I'm
looking for?
Thanks for your help,
Thomas
--
--
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 unsubscribe from this group and stop receiving emails from it, send an
email to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
--
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 unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: core.async timeout channels are values - is this intended
Isn't that not only violating least astonishment, but potentially
introducing a terrible bug into the library? One could use two different
timeout channels in two different alts, and if the timeout channels are
aliased, then perhaps only one of the alts would actually get notified.
On Wed, Nov 20, 2013 at 5:05 AM, Michał Marczyk michal.marc...@gmail.comwrote:
The reason = considers you timeout channels to be equal is that they
are, in fact, the same object. In fact, they may end up being the same
object even with different timeout values:
(identical? (timeout 1) (timeout 2))
;= true
Except I got a false just now with a fresh REPL and same timeout
value... All subsequent invocations return true though, and I'm sure
with a little digging the reason for the false would become clear.
The reason for them being the same object is that timeout goes out of
its way to avoid creating to many timeout channels and will reuse
existing ones if their timeouts are due within a small amount of time
(clojure.core.async.impl.timers/TIMEOUT_RESOLUTION_MS, currently 10
ms) of the requested timeout.
Cheers,
Michał
On 20 November 2013 10:08, Thomas G. Kristensen
thomas.g.kristen...@gmail.com wrote:
Hi all,
I ran into a core.async behaviour that confused me a bit the other day.
In
some of our systems, we need to fire different timeouts, perform actions
and
schedule a new timeout. The problem is, that if the timeouts are of the
same
number of ms, we can't distinguish them, and therefore not keep track of
and
remove them from a set (at least not easily).
That sounds a bit fuzzy. Hopefully this spike will make it clearer what
I'm
trying to say:
(require '[clojure.core.async :refer [chan timeout alts!! alts!]])
(= (chan) (chan))
;; false
(= (timeout 1) (timeout 2))
;; false
(= (timeout 1) (timeout 1))
;; true
(do (loop [ch-v (into {} (for [v [1 2 3]] [(timeout 1000) v]))]
(when-let [chs (keys ch-v)]
(let [[_ ch] (alts!! chs)]
(println (ch-v ch))
(recur (dissoc ch-v ch)
(println done))
;; only fires 3, the last channel in the map
The intended behaviour of the last loop is to print 1, 2 and 3 (not
necessarily in that order). However, the ch-v map will only contain one
key, as timeouts with the same duration are considered the same value. In
the real example, a new timeout with the same value should be scheduled
again, by being put in the map.
So, my questions are:
- Is this intended behaviour?
- Is there a different pattern for achieving the scheduling behaviour I'm
looking for?
Thanks for your help,
Thomas
--
--
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 unsubscribe from this group and stop receiving emails from it, send an
email to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
--
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 unsubscribe from this group and stop receiving emails from it, send an
email to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
--
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 unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: core.async timeout channels are values - is this intended
The behaviour of timeout channels is to close after the timeout
elapses. This will be visible everywhere the channel is used.
Cheers,
Michał
On 20 November 2013 11:22, Cedric Greevey cgree...@gmail.com wrote:
Isn't that not only violating least astonishment, but potentially
introducing a terrible bug into the library? One could use two different
timeout channels in two different alts, and if the timeout channels are
aliased, then perhaps only one of the alts would actually get notified.
On Wed, Nov 20, 2013 at 5:05 AM, Michał Marczyk michal.marc...@gmail.com
wrote:
The reason = considers you timeout channels to be equal is that they
are, in fact, the same object. In fact, they may end up being the same
object even with different timeout values:
(identical? (timeout 1) (timeout 2))
;= true
Except I got a false just now with a fresh REPL and same timeout
value... All subsequent invocations return true though, and I'm sure
with a little digging the reason for the false would become clear.
The reason for them being the same object is that timeout goes out of
its way to avoid creating to many timeout channels and will reuse
existing ones if their timeouts are due within a small amount of time
(clojure.core.async.impl.timers/TIMEOUT_RESOLUTION_MS, currently 10
ms) of the requested timeout.
Cheers,
Michał
On 20 November 2013 10:08, Thomas G. Kristensen
thomas.g.kristen...@gmail.com wrote:
Hi all,
I ran into a core.async behaviour that confused me a bit the other day.
In
some of our systems, we need to fire different timeouts, perform actions
and
schedule a new timeout. The problem is, that if the timeouts are of the
same
number of ms, we can't distinguish them, and therefore not keep track of
and
remove them from a set (at least not easily).
That sounds a bit fuzzy. Hopefully this spike will make it clearer what
I'm
trying to say:
(require '[clojure.core.async :refer [chan timeout alts!! alts!]])
(= (chan) (chan))
;; false
(= (timeout 1) (timeout 2))
;; false
(= (timeout 1) (timeout 1))
;; true
(do (loop [ch-v (into {} (for [v [1 2 3]] [(timeout 1000) v]))]
(when-let [chs (keys ch-v)]
(let [[_ ch] (alts!! chs)]
(println (ch-v ch))
(recur (dissoc ch-v ch)
(println done))
;; only fires 3, the last channel in the map
The intended behaviour of the last loop is to print 1, 2 and 3 (not
necessarily in that order). However, the ch-v map will only contain one
key, as timeouts with the same duration are considered the same value.
In
the real example, a new timeout with the same value should be scheduled
again, by being put in the map.
So, my questions are:
- Is this intended behaviour?
- Is there a different pattern for achieving the scheduling behaviour
I'm
looking for?
Thanks for your help,
Thomas
--
--
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 unsubscribe from this group and stop receiving emails from it, send
an
email to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
--
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 unsubscribe from this group and stop receiving emails from it, send an
email to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
--
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 unsubscribe from this group and stop receiving emails from it, send an
email to clojure+unsubscr
Re: core.async timeout channels are values - is this intended
As for scheduling the printlns, this prints out 1, 2, 3 (in some order):
(let [c (chan)]
(doseq [v [1 2 3]]
(take! (async/timeout 1000) (fn [_] (put! c v
(go-loop [v (! c)]
(println v)
(recur (! c
Cheers,
Michał
On 20 November 2013 11:34, Michał Marczyk michal.marc...@gmail.com wrote:
The behaviour of timeout channels is to close after the timeout
elapses. This will be visible everywhere the channel is used.
Cheers,
Michał
On 20 November 2013 11:22, Cedric Greevey cgree...@gmail.com wrote:
Isn't that not only violating least astonishment, but potentially
introducing a terrible bug into the library? One could use two different
timeout channels in two different alts, and if the timeout channels are
aliased, then perhaps only one of the alts would actually get notified.
On Wed, Nov 20, 2013 at 5:05 AM, Michał Marczyk michal.marc...@gmail.com
wrote:
The reason = considers you timeout channels to be equal is that they
are, in fact, the same object. In fact, they may end up being the same
object even with different timeout values:
(identical? (timeout 1) (timeout 2))
;= true
Except I got a false just now with a fresh REPL and same timeout
value... All subsequent invocations return true though, and I'm sure
with a little digging the reason for the false would become clear.
The reason for them being the same object is that timeout goes out of
its way to avoid creating to many timeout channels and will reuse
existing ones if their timeouts are due within a small amount of time
(clojure.core.async.impl.timers/TIMEOUT_RESOLUTION_MS, currently 10
ms) of the requested timeout.
Cheers,
Michał
On 20 November 2013 10:08, Thomas G. Kristensen
thomas.g.kristen...@gmail.com wrote:
Hi all,
I ran into a core.async behaviour that confused me a bit the other day.
In
some of our systems, we need to fire different timeouts, perform actions
and
schedule a new timeout. The problem is, that if the timeouts are of the
same
number of ms, we can't distinguish them, and therefore not keep track of
and
remove them from a set (at least not easily).
That sounds a bit fuzzy. Hopefully this spike will make it clearer what
I'm
trying to say:
(require '[clojure.core.async :refer [chan timeout alts!! alts!]])
(= (chan) (chan))
;; false
(= (timeout 1) (timeout 2))
;; false
(= (timeout 1) (timeout 1))
;; true
(do (loop [ch-v (into {} (for [v [1 2 3]] [(timeout 1000) v]))]
(when-let [chs (keys ch-v)]
(let [[_ ch] (alts!! chs)]
(println (ch-v ch))
(recur (dissoc ch-v ch)
(println done))
;; only fires 3, the last channel in the map
The intended behaviour of the last loop is to print 1, 2 and 3 (not
necessarily in that order). However, the ch-v map will only contain one
key, as timeouts with the same duration are considered the same value.
In
the real example, a new timeout with the same value should be scheduled
again, by being put in the map.
So, my questions are:
- Is this intended behaviour?
- Is there a different pattern for achieving the scheduling behaviour
I'm
looking for?
Thanks for your help,
Thomas
--
--
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 unsubscribe from this group and stop receiving emails from it, send
an
email to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
--
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 unsubscribe from this group and stop receiving emails from it, send an
email to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
--
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
Re: core.async timeout channels are values - is this intended
Thanks for the response and discussion. Your proposal solves the problem,
but not the general observation: that timeout channels are not usable keys.
A small tweak on your proposal can make a key-safe channel:
(defn unique-timeout
[ms]
(let [c (chan)]
(take! (timeout ms) (fn [_] (close! c)))
c))
(do (loop [ch-v (into {} (for [v [1 2 3]] [(unique-timeout 1000) v]))]
(when-let [chs (keys ch-v)]
(let [[_ ch] (alts!! chs)]
(println (ch-v ch))
(recur (dissoc ch-v ch)
(println done))
I think the lesson learned is, that the implementation of timeout-channels
favours efficiency over the possibility of storing them in maps or sets,
and removing them from these datastructures in a loop.
Once again, thanks for all the feedback!
Thomas
On Wednesday, November 20, 2013 10:53:45 AM UTC, Michał Marczyk wrote:
As for scheduling the printlns, this prints out 1, 2, 3 (in some order):
(let [c (chan)]
(doseq [v [1 2 3]]
(take! (async/timeout 1000) (fn [_] (put! c v
(go-loop [v (! c)]
(println v)
(recur (! c
Cheers,
Michał
On 20 November 2013 11:34, Michał Marczyk michal@gmail.comjavascript:
wrote:
The behaviour of timeout channels is to close after the timeout
elapses. This will be visible everywhere the channel is used.
Cheers,
Michał
On 20 November 2013 11:22, Cedric Greevey cgre...@gmail.comjavascript:
wrote:
Isn't that not only violating least astonishment, but potentially
introducing a terrible bug into the library? One could use two
different
timeout channels in two different alts, and if the timeout channels are
aliased, then perhaps only one of the alts would actually get notified.
On Wed, Nov 20, 2013 at 5:05 AM, Michał Marczyk
michal@gmail.comjavascript:
wrote:
The reason = considers you timeout channels to be equal is that they
are, in fact, the same object. In fact, they may end up being the same
object even with different timeout values:
(identical? (timeout 1) (timeout 2))
;= true
Except I got a false just now with a fresh REPL and same timeout
value... All subsequent invocations return true though, and I'm sure
with a little digging the reason for the false would become clear.
The reason for them being the same object is that timeout goes out of
its way to avoid creating to many timeout channels and will reuse
existing ones if their timeouts are due within a small amount of time
(clojure.core.async.impl.timers/TIMEOUT_RESOLUTION_MS, currently 10
ms) of the requested timeout.
Cheers,
Michał
On 20 November 2013 10:08, Thomas G. Kristensen
thomas.g@gmail.com javascript: wrote:
Hi all,
I ran into a core.async behaviour that confused me a bit the other
day.
In
some of our systems, we need to fire different timeouts, perform
actions
and
schedule a new timeout. The problem is, that if the timeouts are of
the
same
number of ms, we can't distinguish them, and therefore not keep
track of
and
remove them from a set (at least not easily).
That sounds a bit fuzzy. Hopefully this spike will make it clearer
what
I'm
trying to say:
(require '[clojure.core.async :refer [chan timeout alts!! alts!]])
(= (chan) (chan))
;; false
(= (timeout 1) (timeout 2))
;; false
(= (timeout 1) (timeout 1))
;; true
(do (loop [ch-v (into {} (for [v [1 2 3]] [(timeout 1000) v]))]
(when-let [chs (keys ch-v)]
(let [[_ ch] (alts!! chs)]
(println (ch-v ch))
(recur (dissoc ch-v ch)
(println done))
;; only fires 3, the last channel in the map
The intended behaviour of the last loop is to print 1, 2 and 3 (not
necessarily in that order). However, the ch-v map will only contain
one
key, as timeouts with the same duration are considered the same
value.
In
the real example, a new timeout with the same value should be
scheduled
again, by being put in the map.
So, my questions are:
- Is this intended behaviour?
- Is there a different pattern for achieving the scheduling
behaviour
I'm
looking for?
Thanks for your help,
Thomas
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to
clo...@googlegroups.comjavascript:
Note that posts from new members are moderated - please be patient
with
your
first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com javascript:
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 unsubscribe from this group and stop
:peer/timeout Transaction timed out, and excessive logging
I just tried loading a real data file (30M tsv) for the first time (I mean,
instead of just unit tests on my loading program with tiny files), which
resulted in this output:
Exception in thread main clojure.lang.ExceptionInfo: :peer/timeout
Transaction timed out. {:db/error :peer/timeout}
at clojure.core$ex_info.invoke(core.clj:4227)
at datomic.error$raise.invoke(error.clj:24)
(blah blah blah)
Mar 14, 2013 10:11:39 AM org.hornetq.core.logging.impl.JULLogDelegate warn
WARNING: Connection failure has been detected: Did not receive data from
server for
org.hornetq.core.remoting.impl.netty.NettyConnection@76e222eb[local=
/127.0.0.1:59944, remote=localhost/127.0.0.1:4334] [code=3]
More remarkable, the transactor output nearly a million lines of traceback.
Tail shown here, with line numbers
928765 at
datomic.common$interruptible$fn__289.doInvoke(common.clj:383)
[datomic-free-transactor-0.8.3767.jar:na]
928766 at clojure.lang.RestFn.applyTo(RestFn.java:137)
[clojure-1.4.0.jar:na]
928767 at clojure.core$apply.invoke(core.clj:603)
[clojure-1.4.0.jar:na]
928768 at
datomic.common$background$proc__294$fn__295.invoke(common.clj:402)
[datomic-free-transactor-0.8.3767.jar:na]
928769 at
datomic.common$background$proc__294.invoke(common.clj:401)
[datomic-free-transactor-0.8.3767.jar:na]
928770 at clojure.lang.AFn.run(AFn.java:24) [clojure-1.4.0.jar:na]
928771 at java.lang.Thread.run(Thread.java:619) [na:1.6.0_11]
It also exited with this
Critical failure, cannot continue: Agent failed
java.lang.OutOfMemoryError: Java heap space
So, my first thought is perhaps I'm going about this the wrong way. I'm
doing a bulk load by calling d/transact on a lazy sequence of data
structures representing all the facts in the 30M file. Should I be doing
this differently?
My second thought is perhaps datomic should throttle its logging, since a
million lines of traceback is a bit excessive. It's the same traceback
(about 16 lines) repeated, only the timestamp changes.
--
--
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 unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: :peer/timeout Transaction timed out, and excessive logging
Damn, wrong group. Sorry
On Thursday, March 14, 2013 10:37:30 AM UTC-7, Brian Craft wrote:
I just tried loading a real data file (30M tsv) for the first time (I
mean, instead of just unit tests on my loading program with tiny files),
which resulted in this output:
Exception in thread main clojure.lang.ExceptionInfo: :peer/timeout
Transaction timed out. {:db/error :peer/timeout}
at clojure.core$ex_info.invoke(core.clj:4227)
at datomic.error$raise.invoke(error.clj:24)
(blah blah blah)
Mar 14, 2013 10:11:39 AM org.hornetq.core.logging.impl.JULLogDelegate warn
WARNING: Connection failure has been detected: Did not receive data from
server for
org.hornetq.core.remoting.impl.netty.NettyConnection@76e222eb[local= /
127.0.0.1:59944, remote=localhost/127.0.0.1:4334] [code=3]
More remarkable, the transactor output nearly a million lines of
traceback. Tail shown here, with line numbers
928765 at
datomic.common$interruptible$fn__289.doInvoke(common.clj:383)
[datomic-free-transactor-0.8.3767.jar:na]
928766 at clojure.lang.RestFn.applyTo(RestFn.java:137)
[clojure-1.4.0.jar:na]
928767 at clojure.core$apply.invoke(core.clj:603)
[clojure-1.4.0.jar:na]
928768 at
datomic.common$background$proc__294$fn__295.invoke(common.clj:402)
[datomic-free-transactor-0.8.3767.jar:na]
928769 at
datomic.common$background$proc__294.invoke(common.clj:401)
[datomic-free-transactor-0.8.3767.jar:na]
928770 at clojure.lang.AFn.run(AFn.java:24) [clojure-1.4.0.jar:na]
928771 at java.lang.Thread.run(Thread.java:619) [na:1.6.0_11]
It also exited with this
Critical failure, cannot continue: Agent failed
java.lang.OutOfMemoryError: Java heap space
So, my first thought is perhaps I'm going about this the wrong way. I'm
doing a bulk load by calling d/transact on a lazy sequence of data
structures representing all the facts in the 30M file. Should I be doing
this differently?
My second thought is perhaps datomic should throttle its logging, since a
million lines of traceback is a bit excessive. It's the same traceback
(about 16 lines) repeated, only the timestamp changes.
--
--
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 unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Clojure, Heroku and the dreaded R10 Boot Timeout Error
Leonardo Borges writes: Could it be related to new relic? That's the only external service - besides downloading jars - that the app tries to reach upon starting up. If your app is downloading jars on startup that's a bad sign; all your dependencies should be downloaded during git push. If you can track down what's causing this then it should take care of your boot timeouts. If you're having trouble determining where it's coming from feel free to email me directly with your app name and I can help. -Phil -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Clojure, Heroku and the dreaded R10 Boot Timeout Error
Hi all, This one goes to people using heroku for their production Clojure apps. Heroku says that Dynos will be restarted at least once every day - that doesn't seem like a big issue, however this morning I noticed my web dyno has crashed with the aforementioned error (R10). I tried restarting it a couple of times, getting the same error each time - sad panda. Then, with no changes on my part, the web dynos restarted cleanly and have been running now for a couple of hours. This is just scary :( I don't seem to have any guarantees that my app boot won't timeout next time a dyno restarts - what has been your experience with it? Anyone else hitting this problem? Cheers, Leonardo Borges www.leonardoborges.com -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Clojure, Heroku and the dreaded R10 Boot Timeout Error
Hi Leonardo, IIRC, this error comes about when an app takes too long to launch. If you are doing anything interesting during startup, perhaps you can shave some time off of it to increase your chances of success. I highly recommend that you reach out to support and let them know about what you are experiencing. This seems like something they'd like to squash if this is happening on a regular basis. Best, Michael Gorsuch http://twitter.com/michaelgorsuch On Feb 13, 2013, at 7:29 PM, Leonardo Borges leonardoborges...@gmail.com wrote: Hi all, This one goes to people using heroku for their production Clojure apps. Heroku says that Dynos will be restarted at least once every day - that doesn't seem like a big issue, however this morning I noticed my web dyno has crashed with the aforementioned error (R10). I tried restarting it a couple of times, getting the same error each time - sad panda. Then, with no changes on my part, the web dynos restarted cleanly and have been running now for a couple of hours. This is just scary :( I don't seem to have any guarantees that my app boot won't timeout next time a dyno restarts - what has been your experience with it? Anyone else hitting this problem? Cheers, Leonardo Borges www.leonardoborges.com -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Clojure, Heroku and the dreaded R10 Boot Timeout Error
Hi Leonardo, I ran into something similar a while ago. To get around it, I setup :aot compilation. heroku config:add LEIN_BUILD_TASK=compile :all However, in order for config vars to work, I had to install the labs plugin and enable user_env_compile. heroku plugins:install http://github.com/heroku/heroku-labs.git heroku labs:enable user_env_compile -a app-name I am not sure if this info is up-to-date or if it applies to your situation, but I thought I'd mention it. Tim -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Clojure, Heroku and the dreaded R10 Boot Timeout Error
Hi Timothy, I should have mentioned I'm using lein2. Heroku performs AOT compilation for you by default when that's the case. Cheers, Leonardo Borges www.leonardoborges.com On Thu, Feb 14, 2013 at 1:30 PM, Timothy Licata timothy.lic...@gmail.com wrote: Hi Leonardo, I ran into something similar a while ago. To get around it, I setup :aot compilation. heroku config:add LEIN_BUILD_TASK=compile :all However, in order for config vars to work, I had to install the labs plugin and enable user_env_compile. heroku plugins:install http://github.com/heroku/heroku-labs.git heroku labs:enable user_env_compile -a app-name I am not sure if this info is up-to-date or if it applies to your situation, but I thought I'd mention it. Tim -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Clojure, Heroku and the dreaded R10 Boot Timeout Error
Maybe this past post helps https://groups.google.com/d/topic/clojure/tU1LJOXiDc4/discussion D On Thursday, 14 February 2013 14:12:07 UTC+11, Leonardo Borges wrote: Hi Timothy, I should have mentioned I'm using lein2. Heroku performs AOT compilation for you by default when that's the case. Cheers, Leonardo Borges www.leonardoborges.com On Thu, Feb 14, 2013 at 1:30 PM, Timothy Licata timothy...@gmail.com javascript: wrote: Hi Leonardo, I ran into something similar a while ago. To get around it, I setup :aot compilation. heroku config:add LEIN_BUILD_TASK=compile :all However, in order for config vars to work, I had to install the labs plugin and enable user_env_compile. heroku plugins:install http://github.com/heroku/heroku-labs.git heroku labs:enable user_env_compile -a app-name I am not sure if this info is up-to-date or if it applies to your situation, but I thought I'd mention it. Tim -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Clojure, Heroku and the dreaded R10 Boot Timeout Error
Hi Leonardo, On Wed, Feb 13, 2013 at 7:12 PM, Leonardo Borges leonardoborges...@gmail.com wrote: I should have mentioned I'm using lein2. Heroku performs AOT compilation for you by default when that's the case. I had a feeling I was out of date. You have just saved me a configuration step, thank you. Tim -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
nrepl timeout advice needed
I'm using nrepl with a client created as described in the github readme (https://github.com/clojure/tools.nrepl). The nrepl server and client are on the same machine. Everything's working well, except when I try to eval a long-running bit of code. It seems that the timeout defined for the client is causing the output to be truncated. Is there a way to set-up a client with no timeout? Or should I just use an large timeout value? -- 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
Re: nrepl timeout advice needed
Providing a timeout of Long/MAX_VALUE is functionally equivalent to having no timeout. This is what most nREPL clients use by default (including reply [and therefore Leiningen], and the Java Connection class, which Counterclockwise uses). - Chas -- http://cemerick.com [Clojure Programming from O'Reilly](http://www.clojurebook.com) On Jun 11, 2012, at 8:33 AM, MikeM wrote: I'm using nrepl with a client created as described in the github readme (https://github.com/clojure/tools.nrepl). The nrepl server and client are on the same machine. Everything's working well, except when I try to eval a long-running bit of code. It seems that the timeout defined for the client is causing the output to be truncated. Is there a way to set-up a client with no timeout? Or should I just use an large timeout value? -- 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
Re: with-timeout... ?
In Overtone we have the same situation, where we return a promise representing a server response and sometimes we want to timeout if the response never arrives. This is what we use: (defn await-promise! ([prom] (await-promise prom REPLY-TIMEOUT)) ([prom timeout] (.get (future @prom) timeout TimeUnit/MILLISECONDS))) (We have another version without the exclamation mark that returns :timeout rather than throwing an exception when timed out.) I agree with you though, that something along these lines should be built-in. I was surprised to find that there was no way to block on a promise with a timeout, as it seems like such a typical requirement for almost anything you might be promised. -Jeff On Mar 9, 1:12 pm, Sean Allen s...@monkeysnatchbanana.com wrote: Yesterday I was writing a bit of code that needs to wait for an external event to happen but if it doesn't happen with X amount of time, to timeout with an error. Is there a library to handle this? I know you can do it with a future and if you google the general idea, there are a few blog posts, stack overflow questions etc that all have the same basic solution. It seems like such a common thing to do that there would be a standard function/macro out there for it rather than everyone rolling their own. I couldn't however find one. Does one exist? If yes, pointer in the right direction. Thanks, Sean -- 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
with-timeout... ?
Yesterday I was writing a bit of code that needs to wait for an external event to happen but if it doesn't happen with X amount of time, to timeout with an error. Is there a library to handle this? I know you can do it with a future and if you google the general idea, there are a few blog posts, stack overflow questions etc that all have the same basic solution. It seems like such a common thing to do that there would be a standard function/macro out there for it rather than everyone rolling their own. I couldn't however find one. Does one exist? If yes, pointer in the right direction. Thanks, Sean -- 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
Re: with-timeout... ?
Yesterday I was writing a bit of code that needs to wait for an external event to happen but if it doesn't happen with X amount of time, to timeout with an error. Is there a library to handle this? I know you can do it with a future and if you google the general idea, there are a few blog posts, stack overflow questions etc that all have the same basic solution. It seems like such a common thing to do that there would be a standard function/macro out there for it rather than everyone rolling their own. I couldn't however find one. Does one exist? If yes, pointer in the right direction. You can roll your own macro to do this. Example - (defmacro with-timeout [ms body] `(let [f# (future ~@body)] (.get #^java.util.concurrent.Future f# ~ms java.util.concurrent.TimeUnit/MILLISECONDS))) Regards, BG -- Baishampayan Ghose b.ghose at gmail.com -- 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
Re: with-timeout... ?
On Wed, Mar 9, 2011 at 7:25 AM, Baishampayan Ghose b.gh...@gmail.com wrote: Yesterday I was writing a bit of code that needs to wait for an external event to happen but if it doesn't happen with X amount of time, to timeout with an error. Is there a library to handle this? I know you can do it with a future and if you google the general idea, there are a few blog posts, stack overflow questions etc that all have the same basic solution. It seems like such a common thing to do that there would be a standard function/macro out there for it rather than everyone rolling their own. I couldn't however find one. Does one exist? If yes, pointer in the right direction. You can roll your own macro to do this. Example - (defmacro with-timeout [ms body] `(let [f# (future ~@body)] (.get #^java.util.concurrent.Future f# ~ms java.util.concurrent.TimeUnit/MILLISECONDS))) Variation on that macro are what I've seen across the variety of sources I've mentioned in my original message. It just strikes me as odd that something so general hasn't made it into a library. If it really hasn't made a library, ok.. I just wanted to make sure it wasn't in a library somewhere and that keeping the hand rolled macro wasn't something I should still be doing. -- 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
Re: with-timeout... ?
See https://github.com/Raynes/clojail It's a sandboxing library for Clojure, which among other things means it needs to try running an operation and give up after N seconds. You can skip the sandboxing part entirely if you want; it exposes a pretty general thunk-timeout function. On Mar 9, 4:43 am, Sean Allen s...@monkeysnatchbanana.com wrote: On Wed, Mar 9, 2011 at 7:25 AM, Baishampayan Ghose b.gh...@gmail.com wrote: Yesterday I was writing a bit of code that needs to wait for an external event to happen but if it doesn't happen with X amount of time, to timeout with an error. Is there a library to handle this? I know you can do it with a future and if you google the general idea, there are a few blog posts, stack overflow questions etc that all have the same basic solution. It seems like such a common thing to do that there would be a standard function/macro out there for it rather than everyone rolling their own. I couldn't however find one. Does one exist? If yes, pointer in the right direction. You can roll your own macro to do this. Example - (defmacro with-timeout [ms body] `(let [f# (future ~@body)] (.get #^java.util.concurrent.Future f# ~ms java.util.concurrent.TimeUnit/MILLISECONDS))) Variation on that macro are what I've seen across the variety of sources I've mentioned in my original message. It just strikes me as odd that something so general hasn't made it into a library. If it really hasn't made a library, ok.. I just wanted to make sure it wasn't in a library somewhere and that keeping the hand rolled macro wasn't something I should still be doing. -- 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
Re: with-timeout... ?
Or you could just modify the source of promise ... i dont know why
promises dont support timeouts
(defprotocol PWait
(wait-for [this timeout units] [this timeout]))
;;copied from clojure source, but adding timeout wait-for
(defn promise
Alpha - subject to change.
Returns a promise object that can be read with deref/@, and set,
once only, with deliver. Calls to deref/@ prior to delivery will
block. All subsequent derefs will return the same delivered value
without blocking.
{:added 1.1}
[]
(let [d (java.util.concurrent.CountDownLatch. 1)
v (atom nil)]
(reify
clojure.lang.IDeref
(deref [_] (.await d) @v)
PWait
(wait-for [this timeout]
(wait-for this timeout
java.util.concurrent.TimeUnit/MILLISECONDS))
(wait-for [this timeout units]
(if timeout
(.await d timeout units)
(do (.await d) true)))
clojure.lang.IFn
(invoke [this x]
(locking d
(if (pos? (.getCount d))
(do (reset! v x)
(.countDown d)
x)
(throw
(IllegalStateException.
Multiple deliver calls to a promise
--
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
Re: with-timeout... ?
I've been working in this direction with Cljque, for example http://bit.ly/gCtmAl Cljque is still an experiment and has no stable API or documentation. -Stuart Sierra clojure.com -- 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
Re: with-timeout... ?
oooh ... I can definitely find a use for this in my project! Thanks for pointing it out. -- 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
