Re: Unexpected core.async timeout behaviour

2014-04-15 Thread Ghadi Shayban
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

Re: Unexpected core.async timeout behaviour

2014-03-28 Thread Timothy Baldridge
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.

Re: Unexpected core.async timeout behaviour

2014-03-28 Thread Peter Taoussanis
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 thi

Re: Unexpected core.async timeout behaviour

2014-03-28 Thread Peter Taoussanis
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

Re: Unexpected core.async timeout behaviour

2014-03-28 Thread Peter Taoussanis
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 uns

Re: Unexpected core.async timeout behaviour

2014-03-28 Thread Tim Visher
On Fri, Mar 28, 2014 at 8:08 AM, Peter Taoussanis 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 tak

Re: Unexpected core.async timeout behaviour

2014-03-28 Thread Peter Taoussanis
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 lo

Re: Unexpected core.async timeout behaviour

2014-03-28 Thread Tim Visher
Hi Peter, On Fri, Mar 28, 2014 at 2:48 AM, Peter Taoussanis wrote: > Hi all, quick question: > > `(dotimes [_ 5] (go ( `(dotimes [_ 5] (go ( produces an error: > > (< (.size takes) impl/MAX-QUEUE-SIZE)> java.lang.AssertionError: Assert > failed: No more than 1024 pending takes are allowed

Unexpected core.async timeout behaviour

2014-03-27 Thread Peter Taoussanis
Hi all, quick question: `(dotimes [_ 5] (go ( 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