:server-ready takes too long to be satisfied #85

Closed
technomancy opened this Issue Apr 11, 2012 · 13 comments

Projects

None yet

4 participants

@technomancy

Loading overtone.live from lein2 repl in a checkout of overtone 0.7.0-SNAPSHOT fails with The following deps took too long to be satisfied: :server-ready overtone.libs.deps/wait-until-deps-satisfied (deps.clj:148): https://refheap.com/paste/2010

Calling (use 'overtone.live) again allows it to succeed and show the welcome message, but loading an example after that's loaded fails with CompilerException java.util.concurrent.TimeoutException: deref! timeout error. Dereference took longer than 5000 ms, compiling:(basic.clj:266). No sound is generated, though that could be a problem with jackd.

@technomancy

This must be caused by the same issue as trptcolin/reply#49 since I can't reproduce using lein run.

@samaaron
Member

I believe this is a known issue with the latest builds of Overtone on linux. The timeout is Overtone waiting for the server to send an ack which is somehow lost. It might be due to the server not booting properly.

I'll try and get a linux VM setup to start debugging these issues. For now, 0.6.0 should work fine.

@trptcolin

I'm actually seeing the first part (overtone.libs.deps/wait-until-deps-satisfied timeout) on OSX (10.6.8): https://refheap.com/paste/2011

But I'm like 90% sure I saw this working totally fine with the same repl code yesterday.

@technomancy

Just as another data point, I'm getting sound now; not sure what was up earlier.

@trptcolin

OK, I dug in a little on overtone master, adding some print statements here and there in overtone, and got this from the wait-sleep loop in wait-until-deps-satisfied:

deps: :server-ready
dep-state: {:satisfied #{:server-connected :internal-server-booted}, :done [[:overtone.sc.machinery.server.connection/connect-internal #{:internal-server-booted} #<connection$connect_internal overtone.sc.machinery.server.connection$connect_internal@329fefc3>]], :todo []}
Exception The following deps took too long to be satisfied: :server-ready  overtone.libs.deps/wait-until-deps-satisfied (deps.clj:143)

So it looks like :server-connected is being received, but none of the callbacks set up in the (on-deps ...) calls for :server-connected (set up in src/overtone/sc/server.clj) are actually firing. I added print statements to those callbacks to make sure.

Interestingly, it also looks like on-deps* is only being called once in the bad case, multiple times in the good case (reply --standalone): https://refheap.com/paste/2015.

@samaaron
Member

on-deps* is part of Overtone's dependency-based event-triggering mechanism. Essentially we associate fns to be called the first time certain dependencies have been met. on-deps* is part of the mechanism that associates a fn with a given dependency list. As there are a number of these fns which are registered, it is expected that on-deps* is called multiple times in the good case.

Out of interest, do you know where the "key unknown" comes from in your pastie?

@trptcolin

Yeah, that was logging I'd added in on-deps* (i added it to both branches of the if expression there). Here's something interesting: if I wrap the send-off call within on-deps in a thread, it works! There must be something tricky I don't understand about sending off to an agent while you're already on another agent thread? nrepl uses agents internally to do execution.

@samaaron
Member

Aha!

Sends/send-offs within an agent block until the state has been
updated. This is probably the issue right here.

Agents are probably the wrong solution for this task within REPL-y -
you'll run into these issues whenever other code assumes to be the
"top-level" agent. If you're trying to serialise asynchronous
execution then a java blocking queue and a separate worker thread/pool
is probably your friend.

Sam


http://sam.aaron.name

On 12 April 2012 14:06, Colin Jones
reply@reply.github.com
wrote:

Yeah, that was logging I'd added in on-deps* (i added it to both branches of the if expression there). Here's something interesting: if I wrap the send-off call within on-deps in a thread, it works! There must be something tricky I don't understand about sending off to an agent while you're already on another agent thread? nrepl uses agents internally to do execution.


Reply to this email directly or view it on GitHub:
#85 (comment)

@samaaron
Member

Perhaps something simple like this might help:

https://github.com/samaaron/spirit-worker

@trptcolin

Sounds on IRC (via @cemerick) like this is a known thing (https://refheap.com/paste/2034), that an send/send-off within an agent action is delayed until the agent action finishes.

One workaround is adding (release-pending-sends) just after the send-off in on-deps to force those jobs out (tested it locally, seems to work). That doesn't help overtone 0.6.0 users, and other cases like this may come up, so this may just force nrepl to avoid using agents for sessions altogether, unless there are other crafty ideas we can come up with.

@trptcolin

Oops, missed your notes. Yeah, seems reasonable, thanks!

@samaaron
Member

Fixed for me with latest builds of lein :-)

@samaaron samaaron closed this Apr 23, 2012
@cemerick

Beautiful, thanks for the confirmation! :-D

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment