alda-lang / alda-core

The core machinery of Alda

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Alda not starting - Need to "Disable Networking"

aktopus opened this issue · comments

In issue #271 I saw that @0atman had an identical issue as I do starting workers. His error copied verbatim below:

λ alda up
[27713] Starting Alda server...
[27713] Server up ?
[27713] Starting worker processes...
[ this hangs, I waited for 5 minutes ]
^C

λ alda status
[27713] Server up (0/2 workers available)

I see from the comments in that thread this is a network issue, and that "disabling networking" can resolve. I'm not entirely sure how to do that and I tried Googling that precise phrase. Can someone let me know the best way to do this?

I would try disabling wifi and disconnecting from ethernet and trying it out. I'm not sure though, I've never seen this issue before, sorry 😢
What operating system are you on? Your on windows 10 per #271.
Can you provide the results of alda version?

Tried disabling wifi and disconnecting from ethernet without success. To your questions: I'm on Windows 10, and alda version gives the following:

Client version: 1.0.0-rc56

Server version:
[27713] 1.0.0-rc56

But let me back up a moment - the root of the issue is the fact that I'm unable to play alda files with command alda play --file <filename> which gives the error:

[27713] ERROR No worker processes are ready yet. Please wait a minute.

But it all seems to be part of the same problem, since running alda up is supposed to start worker processes. Meanwhile, the below version of Alda does successfully play music:

Client version: 1.0.0-rc31

Server version:
[27713] 1.0.0-rc31

@aktopus Could you try the following?

  1. Find the backend port of the server you have running:

    $ alda status
    [27713] Server up (2/2 workers available, backend port: 56992)
    
  2. Run a new worker process in the foreground and try to connect to the backend port:

    $ alda -v -p 56992 worker
    

    If everything is working properly, you should see the worker receiving heartbeats from the server:

    $ alda -v -p 56992 worker
    Jan 30, 2017 10:58:17 AM com.jsyn.engine.SynthesisEngine start
    INFO: Pure Java JSyn from www.softsynth.com, rate = 44100, RT, V16.7.3 (build 457, 2014-12-25)
    17-01-30 15:58:18 skeggox.local INFO [alda.worker:152] - Worker reporting for duty!
    17-01-30 15:58:18 skeggox.local INFO [alda.worker:153] - Connecting to socket on port 56992...
    17-01-30 15:58:18 skeggox.local INFO [alda.worker:162] - Sending READY signal.
    17-01-30 15:58:19 skeggox.local DEBUG [alda.worker:177] - Got HEARTBEAT from server.
    17-01-30 15:58:20 skeggox.local DEBUG [alda.worker:177] - Got HEARTBEAT from server.
    17-01-30 15:58:21 skeggox.local DEBUG [alda.worker:177] - Got HEARTBEAT from server.
    17-01-30 15:58:22 skeggox.local DEBUG [alda.worker:177] - Got HEARTBEAT from server.
    17-01-30 15:58:23 skeggox.local DEBUG [alda.worker:177] - Got HEARTBEAT from server.
    17-01-30 15:58:24 skeggox.local DEBUG [alda.worker:177] - Got HEARTBEAT from server.
    17-01-30 15:58:25 skeggox.local DEBUG [alda.worker:177] - Got HEARTBEAT from server.
    17-01-30 15:58:26 skeggox.local DEBUG [alda.worker:177] - Got HEARTBEAT from server.
    

I'm hoping that your worker's output might help us figure out where the problem is.

Hi @daveyarwood! Here's what I'm seeing:

  1. Find the backend port of the server you have running:
$ alda status
[27713] Server down ?

$ alda up
[27713] Starting Alda server...
[27713] Server up ?
[27713] Starting worker processes...

Process hangs, so I interrupt, and try getting the status again.

$ ^C

$ alda status
[27713] Server up (0/2 workers available, backend port: 51355)
  1. Run a new worker process in the foreground and try to connect to the backend port:
$ alda -v -p 51355 worker
Jan 30, 2017 11:21:05 AM com.jsyn.devices.javasound.JavaSoundAudioDevice <init>
INFO: JSyn: default output latency set to 80 msec for Windows 10
Jan 30, 2017 11:21:06 AM com.jsyn.engine.SynthesisEngine start
INFO: Pure Java JSyn from www.softsynth.com, rate = 44100, RT, V16.7.3 (build 457, 2014-12-25)
17-01-30 16:21:06 LPNYC1008332 INFO [alda.worker:152] - Worker reporting for duty!
17-01-30 16:21:06 LPNYC1008332 INFO [alda.worker:153] - Connecting to socket on port 51355...
17-01-30 16:21:06 LPNYC1008332 INFO [alda.worker:162] - Sending READY signal.
17-01-30 16:21:08 LPNYC1008332 DEBUG [alda.worker:177] - Got HEARTBEAT from server.
17-01-30 16:21:09 LPNYC1008332 DEBUG [alda.worker:177] - Got HEARTBEAT from server.
17-01-30 16:21:10 LPNYC1008332 DEBUG [alda.worker:177] - Got HEARTBEAT from server.
17-01-30 16:21:11 LPNYC1008332 DEBUG [alda.worker:177] - Got HEARTBEAT from server.
17-01-30 16:21:12 LPNYC1008332 DEBUG [alda.worker:177] - Got HEARTBEAT from server.
17-01-30 16:21:13 LPNYC1008332 DEBUG [alda.worker:177] - Got HEARTBEAT from server.
17-01-30 16:21:14 LPNYC1008332 DEBUG [alda.worker:177] - Got HEARTBEAT from server.
$^C

So I am getting heartbeats, but I still see zero workers available when I run alda status again. After having run the above, trying the command alda play --file <filename> now gives the following error:

[27713] ERROR Unable to read file: <filename>

In which the file is a .alda file with the following sample code:

piano: o3
g8 a b > c d e f+ g | a b > c d e f+ g4
g8 f+ e d c < b a g | f+ e d c < b a g4
<< g1/>g/>g/b/>d/g

Interesting. This seems like it might be a permissions issue.

When you start a worker process in the foreground (the key being that you start the process), it is able to talk to the server fine. However, when you start the server, the server is apparently not able to start its own worker processes.

So I am getting heartbeats, but I still see zero workers available when I run alda status again.

Just to clarify -- did you run alda status in another terminal before killing the worker process?

I'm not sure what's going on with the "Unable to read file" part... that typically means the file you're referring to doesn't exist:

$ alda play -f examples/hello_world.alda
[27713] Parsing/evaluating...
[27713] Playing...

$ alda play -f nonexistent_file.alda
[27713] ERROR Unable to read file: /Users/dave/Code/alda-core/nonexistent_file.alda

If the relative path isn't working, maybe try the full path? Just a stab in the dark, but that could be a Windows-specific issue, or perhaps an issue specific to whichever terminal program you are using (e.g. Cygwin vs. PowerShell vs the terminal program that comes with Windows etc.).

I did not run alda status in another terminal before killing the worker process (i.e. alda up followed by alda status in a separate terminal) but on trying it now, I'm getting the same result:

[27713] Server up (0/2 workers available, backend port: 55964)

in the second window while the first window is stuck on:

[27713] Starting worker processes...

Let's not worry about the file-playing aspect for the time being since I'm having trouble replicating.

Do you see any error logs in $HOME/.alda/logs/? (I'm not sure what the $HOME path would be on Windows 10)

I would try C:/Users/<username>/AppData/ (or the roaming folder in the previous path).

AppData is a hidden folder unfortunately though.

The folder /.alda does not exist in my home directory (though I do see other folders like ./ipython for other languages. Similarly, Alda does not show up in AppData or Appdata/Roaming, though I see other folders like like Spotify and Slack within Roaming.

Aha -- so maybe some kind of error is occurring when the Alda worker process attempts to access $HOME/.alda to write logs.

When run in verbose mode (-v), a worker does not attempt to access this directory, which might explain why nothing looked out of the ordinary when you ran a worker in the foreground earlier.

@aktopus Would you mind trying again, but without the verbose flag (alda -p <backend-port-here> worker) and see if there is an error?

$ alda status
[27713] Server up (0/2 workers available, backend port: 58737)
$ alda -p 58737 worker
17-01-30 21:02:39 LPNYC1008332 INFO [alda.worker:148] - Logging errors to C:\Users\aetteh\.alda\logs\error.log
Jan 30, 2017 4:02:39 PM com.jsyn.devices.javasound.JavaSoundAudioDevice <init>
INFO: JSyn: default output latency set to 80 msec for Windows 10
Jan 30, 2017 4:02:39 PM com.jsyn.engine.SynthesisEngine start
INFO: Pure Java JSyn from www.softsynth.com, rate = 44100, RT, V16.7.3 (build 457, 2014-12-25)

The above never tells me it's receiving heartbeats and just hangs at the above. I forgot I'd left it open, and when I opened a new terminal window and entered $ alda status I then get [27713] Server up (1/2 workers available, backend port: 58737), and then on trying to run....

$ alda play --file <filename>
[27713] Parsing/evaluating...
[27713] Playing...

It actually plays the file, finally! So obviously, it's ideal to not have to run alda up, alda status, open a new terminal, run alda play just to play a song. Does the combination of things your seeing give you a better sense of what's going on? Happy to run some other tests.

So I had to leave my laptop at work for unrelated reasons and can't post the log for you to look at, but will update this tomorrow.

I closed my terminal, which never went past the following (also above):

$ alda status
[27713] Server up (0/2 workers available, backend port: 58737)
$ alda -p 58737 worker
17-01-30 21:02:39 LPNYC1008332 INFO [alda.worker:148] - Logging errors to C:\Users\aetteh\.alda\logs\error.log
Jan 30, 2017 4:02:39 PM com.jsyn.devices.javasound.JavaSoundAudioDevice <init>
INFO: JSyn: default output latency set to 80 msec for Windows 10
Jan 30, 2017 4:02:39 PM com.jsyn.engine.SynthesisEngine start
INFO: Pure Java JSyn from www.softsynth.com, rate = 44100, RT, V16.7.3 (build 457, 2014-12-25)

When I looked for C:\Users\aetteh\.alda\logs\error.log I still don't see a folder called \.alda, so I unfortunately don't have anything else to pass along. I'm guessing it's because the process didn't get any further.

I just switched from Mac OS to Windows 10; Still an issue in 1.0.0rc59.

I have a laptop with windows 10 temporarily and can repro this, so I might be able to try and take a stab at it. Not sure how far I will be able to get though.

I'd been using 1.0.0-rc31 since 56 wasn't working. On a new laptop (still Windows 10) with 66, and the issue persists.

@aktopus I don't have a windows computer anymore, so I can't verify this, but I think I was able to workaround this problem by placing the alda excutable in a non-privleged place (eg: Downloads) and calling it from there (instead of putting it on the path, per the readme). Does it work in that case?

Unfortunately not; I have the same issue.

In 1.0.0rc67 the worker processes do not persist long if they aren't working. This makes the REPL virtually impossible to use.

Windows PowerShell
Copyright (C) 2016 Microsoft Corporation. All rights reserved.

PS C:\Users\elyis> alda status
[27713] Server up (0/2 workers available, backend port: 62646)
PS C:\Users\elyis> alda -v -p 62646 worker
Sep 29, 2017 2:53:22 PM com.jsyn.devices.javasound.JavaSoundAudioDevice <init>
INFO: JSyn: default output latency set to 80 msec for Windows 10
Sep 29, 2017 2:53:22 PM com.jsyn.engine.SynthesisEngine start
INFO: Pure Java JSyn from www.softsynth.com, rate = 44100, RT, V16.7.8 (build 462, 2016-11-30)
Sep 29, 2017 2:53:22 PM java.util.prefs.WindowsPreferences <init>
WARNING: Could not open/create prefs root node Software\JavaSoft\Prefs at root 0x80000002. Windows RegCreateKeyEx(...) r
eturned error code 5.
17-09-29 18:53:23 ELYS-COMPUTER-WINDOWS-EDITION DEBUG [alda.worker:27] - Requiring alda.lisp...
17-09-29 18:53:23 ELYS-COMPUTER-WINDOWS-EDITION INFO [alda.worker:225] - Worker reporting for duty!
17-09-29 18:53:23 ELYS-COMPUTER-WINDOWS-EDITION INFO [alda.worker:226] - Connecting to socket on port 62646...
17-09-29 18:53:23 ELYS-COMPUTER-WINDOWS-EDITION INFO [alda.worker:237] - Sending READY signal.
17-09-29 18:53:24 ELYS-COMPUTER-WINDOWS-EDITION DEBUG [alda.worker:255] - Got HEARTBEAT from server.
17-09-29 18:53:25 ELYS-COMPUTER-WINDOWS-EDITION DEBUG [alda.worker:255] - Got HEARTBEAT from server.
17-09-29 18:53:26 ELYS-COMPUTER-WINDOWS-EDITION DEBUG [alda.worker:255] - Got HEARTBEAT from server.
17-09-29 18:53:27 ELYS-COMPUTER-WINDOWS-EDITION DEBUG [alda.worker:255] - Got HEARTBEAT from server.
17-09-29 18:53:28 ELYS-COMPUTER-WINDOWS-EDITION DEBUG [alda.worker:255] - Got HEARTBEAT from server.
17-09-29 18:53:29 ELYS-COMPUTER-WINDOWS-EDITION DEBUG [alda.worker:255] - Got HEARTBEAT from server.
17-09-29 18:53:30 ELYS-COMPUTER-WINDOWS-EDITION DEBUG [alda.worker:255] - Got HEARTBEAT from server.
17-09-29 18:53:31 ELYS-COMPUTER-WINDOWS-EDITION DEBUG [alda.worker:255] - Got HEARTBEAT from server.
17-09-29 18:53:41 ELYS-COMPUTER-WINDOWS-EDITION ERROR [alda.worker:324] - Unable to reach the server.
17-09-29 18:53:41 ELYS-COMPUTER-WINDOWS-EDITION INFO [alda.worker:235] - Shutting down.
PS C:\Users\elyis>

@elyisgreat Thanks for posting those logs -- it's very helpful for me to see what the worker is doing on a Windows machine.

It actually looks like the worker is successfully communicating with the server. I realize this isn't obvious, but the server has a routine that it runs periodically where it checks to see how many workers are talking to it; if it has too many, it drops one of them, i.e. stops sending it heartbeats. I believe that's what we're seeing in the logs above, so AFAICT, everything is working OK there.

The 0/2 workers thing is disconcerting... I've seen it occasionally, myself, and I don't understand yet why it happens. Restarting the server with alda downup does fix it for me. @elyisgreat: does that fix it for you?

It might be helpful if we can get server logs as well, i.e. run a server in the foreground via the following command:

ALDA_DISABLE_SUPERVISOR=yes alda -v -p 27714 server

and then noting the backend port in the server logs and starting a worker to try to connect to it.

(ALDA_DISABLE_SUPERVISOR=yes keeps the server from dropping extra workers. Also note the frontend port of 27714, so to test this setup, you could run e.g. alda -p 27714 repl)

Here's what happens when trying to start the server

Windows PowerShell
Copyright (C) 2016 Microsoft Corporation. All rights reserved.

PS C:\Users\elyis> alda up
[27713] Starting Alda server...
[27713] Server up ?
[27713] Starting worker processes...
#after hanging for five minutes I interrupted the process
PS C:\Users\elyis> alda status
[27713] Server up (0/2 workers available, backend port: 54770)
PS C:\Users\elyis>

After attempting alda downup

PS C:\Users\elyis> alda downup
[27713] Stopping Alda server...
[27713] Server down ?

[27713] Starting Alda server...
[27713] Server up ?
[27713] Starting worker processes...
#still hangs
PS C:\Users\elyis> alda status
[27713] Server up (0/2 workers available, backend port: 63180)

Running ALDA_DISABLE_SUPERVISOR=yes alda -v -p 27714 server does this:

PS C:\Users\elyis> alda down
[27713] Stopping Alda server...
[27713] Server down ?
PS C:\Users\elyis> ALDA_DISABLE_SUPERVISOR=yes alda -v -p 27714 server
ALDA_DISABLE_SUPERVISOR=yes : The term 'ALDA_DISABLE_SUPERVISOR=yes' is not recognized as the name of a cmdlet,
function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the
path is correct and try again.
At line:1 char:1
+ ALDA_DISABLE_SUPERVISOR=yes alda -v -p 27714 server
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (ALDA_DISABLE_SUPERVISOR=yes:String) [], CommandNotFoundException
    + FullyQualifiedErrorId : CommandNotFoundException

PS C:\Users\elyis>

Just running alda -v -p 27714 server behaves interestingly...

PS C:\Users\elyis> alda -v -p 27714 server
17-09-30 03:25:58 ELYS-COMPUTER-WINDOWS-EDITION INFO [alda.server:242] - Binding frontend socket on port 27714...
17-09-30 03:25:58 ELYS-COMPUTER-WINDOWS-EDITION INFO [alda.server:255] - Binding backend socket on port 53665...
17-09-30 03:25:58 ELYS-COMPUTER-WINDOWS-EDITION INFO [alda.server:269] - Spawning 2 workers...
17-09-30 03:26:58 ELYS-COMPUTER-WINDOWS-EDITION INFO [alda.server:189] - Supervisor says we need more workers.
17-09-30 03:26:58 ELYS-COMPUTER-WINDOWS-EDITION INFO [alda.server:190] - Starting 2 more worker(s)...
17-09-30 03:27:58 ELYS-COMPUTER-WINDOWS-EDITION INFO [alda.server:189] - Supervisor says we need more workers.
17-09-30 03:27:58 ELYS-COMPUTER-WINDOWS-EDITION INFO [alda.server:190] - Starting 2 more worker(s)...
17-09-30 03:28:58 ELYS-COMPUTER-WINDOWS-EDITION INFO [alda.server:189] - Supervisor says we need more workers.
17-09-30 03:28:58 ELYS-COMPUTER-WINDOWS-EDITION INFO [alda.server:190] - Starting 2 more worker(s)...
17-09-30 03:29:58 ELYS-COMPUTER-WINDOWS-EDITION INFO [alda.server:189] - Supervisor says we need more workers.
17-09-30 03:29:58 ELYS-COMPUTER-WINDOWS-EDITION INFO [alda.server:190] - Starting 2 more worker(s)...
17-09-30 03:30:58 ELYS-COMPUTER-WINDOWS-EDITION INFO [alda.server:189] - Supervisor says we need more workers.
17-09-30 03:30:58 ELYS-COMPUTER-WINDOWS-EDITION INFO [alda.server:190] - Starting 2 more worker(s)...
#Seems to loop through this forever until I send an interrupt
17-09-30 03:31:51 ELYS-COMPUTER-WINDOWS-EDITION INFO [alda.server:262] - Interrupt (e.g. Ctrl-C) received.
17-09-30 03:31:51 ELYS-COMPUTER-WINDOWS-EDITION INFO [alda.server:231] - Murdering workers...
17-09-30 03:31:51 ELYS-COMPUTER-WINDOWS-EDITION INFO [alda.server:264] - Shutting down...
17-09-30 03:31:51 ELYS-COMPUTER-WINDOWS-EDITION INFO [alda.server:267] - Exiting.
PS C:\Users\elyis> alda status
[27713] Server down ?
PS C:\Users\elyis>

However, when I connect a worker to the backend...

PS C:\Users\elyis> alda -v -p 27714 server
17-09-30 03:34:31 ELYS-COMPUTER-WINDOWS-EDITION INFO [alda.server:242] - Binding frontend socket on port 27714...
17-09-30 03:34:32 ELYS-COMPUTER-WINDOWS-EDITION INFO [alda.server:255] - Binding backend socket on port 53808...
#in a new window
PS C:\Users\elyis> alda status
[27713] Server down ?
#still seems to think the server is down
PS C:\Users\elyis> alda -v -p 53808 worker
Sep 29, 2017 11:36:13 PM com.jsyn.devices.javasound.JavaSoundAudioDevice <init>
INFO: JSyn: default output latency set to 80 msec for Windows 10
Sep 29, 2017 11:36:13 PM com.jsyn.engine.SynthesisEngine start
INFO: Pure Java JSyn from www.softsynth.com, rate = 44100, RT, V16.7.8 (build 462, 2016-11-30)
Sep 29, 2017 11:36:13 PM java.util.prefs.WindowsPreferences <init>
WARNING: Could not open/create prefs root node Software\JavaSoft\Prefs at root 0x80000002. Windows RegCreateKeyEx(...) r
eturned error code 5.
17-09-30 03:36:15 ELYS-COMPUTER-WINDOWS-EDITION DEBUG [alda.worker:27] - Requiring alda.lisp...
17-09-30 03:36:15 ELYS-COMPUTER-WINDOWS-EDITION INFO [alda.worker:225] - Worker reporting for duty!
17-09-30 03:36:15 ELYS-COMPUTER-WINDOWS-EDITION INFO [alda.worker:226] - Connecting to socket on port 53808...
17-09-30 03:36:15 ELYS-COMPUTER-WINDOWS-EDITION INFO [alda.worker:237] - Sending READY signal.
17-09-30 03:36:16 ELYS-COMPUTER-WINDOWS-EDITION DEBUG [alda.worker:255] - Got HEARTBEAT from server.
17-09-30 03:36:17 ELYS-COMPUTER-WINDOWS-EDITION DEBUG [alda.worker:255] - Got HEARTBEAT from server.
17-09-30 03:36:18 ELYS-COMPUTER-WINDOWS-EDITION DEBUG [alda.worker:255] - Got HEARTBEAT from server.
17-09-30 03:36:19 ELYS-COMPUTER-WINDOWS-EDITION DEBUG [alda.worker:255] - Got HEARTBEAT from server.
#this continues indefinitely. Again, in a new window
PS C:\Users\elyis> alda status
[27713] Server down ?
PS C:\Users\elyis> alda play -f "C:\Users\elyis\Dropbox\Documents\Developer\Personal Projects\Alda\13days.alda"
[27713] ERROR Alda server is down. To start the server, run `alda up`.
#still seems to think the server is down, however when I specify the port
PS C:\Users\elyis> alda -p 27714 play -f "C:\Users\elyis\Dropbox\Documents\Developer\Personal Projects\Alda\13days.alda"
[27714] Parsing/evaluating...
[27714] Playing...
PS C:\Users\elyis>

Odd... I don't know much about how the server works behind the scenes, so take from that what you will...

A couple small things to note:

  • When you run the server without the verbose (-v) flag, it is not necessarily "hanging," just quietly doing its work.

  • The MY_ENV_VARIABLE=myvalue somecommand syntax doesn't appear to work in PowerShell. In Unix, when you do that, it temporarily sets MY_ENV_VARIABLE to myvalue only for the program that is running. It's a convenient way to run a command with certain options specified via environment variables. Disabling the supervisor routine in the server is not something Alda users will typically need to do, but it's useful for debugging and development, so that's why I added a check for the ALDA_DISABLE_SUPERVISOR environment variable.

From your last two logs, the server and worker appear to be working correctly on your system.

Note that when you ran alda status, it said [27713] Server down because I presume there was no server running on port 27713. alda play ... similarly failed because it was attempting to use a nonexistent server on port 27713.

Then when you added -p 27714, it started working because you had a server running on that port.

I had a thought: I think the worker processes might be timing out a little too soon in some cases. If a worker process hasn't heard from the server after a certain amount of time, it gives up and shuts down. It occurred to me that maybe in some environments, 10 seconds is not enough time for the server to start communicating with a worker once the worker starts. So, to be on the safe side, I've increased the timeout to 30 seconds as of Alda 1.0.0-rc70. I think this might help quite a bit.

@aktopus: Would you mind updating to 1.0.0-rc70 and running alda downup and see if that resolves your issue?

Still hangs

PS C:\Program Files (x86)\Alda> alda version
Client version: 1.0.0-rc70
PS C:\Program Files (x86)\Alda> alda downup
[27713] Server already down.

[27713] Starting Alda server...
[27713] Server up ?
[27713] Starting worker processes...

"Hangs" is kind of a weird term. It basically means "I didn't see anything change after I waited what I thought was a reasonable amount of time," but it could actually be the case that work is being done silently.

On my machine, it takes a good while for worker processes to start, maybe about 30 seconds or so. I would say that if it takes longer than 5 minutes, then something could be wrong, most likely the worker processes are failing to start. I wouldn't jump to that conclusion right away, though. Looking at the logs in ~/.alda/logs/error.log can be helpful: if something goes wrong while a worker is trying to start, it should append to that file.

Because it takes so long for the workers to start, one thing that I've thought about, to try and improve the experience a little, is to print some sort of indication that the process is still running and isn't frozen/hanging. Maybe we could print a . every few seconds, or something. Or maybe, every 15 seconds or so, we could print "Still working..." or something like that. In general, I'm not particularly fond of doing that, but I'm open to it, if it makes it easier to tell that the process isn't hanging.

Manually starting worker processes solved the situation where they were not starting automatically for me. Created a pull request to add instructions to the windows-troubleshooting.md file: alda-lang/alda#300.

Thanks for the PR, @Hemaolle -- I've merged it, in case this workaround is helpful to newcomers.

I'd still love to fix the issue, if we can figure out what exactly is happening. It's interesting that a worker is able to connect if you start it manually, but somehow the workers that the server starts are not able to connect.

Maybe a good thing to verify would be whether the 2 workers that the server starts are actually starting up, and if so, how long they hang around. Is there a way somebody with Windows could do this by e.g. running alda up and watching the Task Manager?

When I run alda up I get 2 alda processes in the Task Manager, I believe it's the server and the client probably (the alda up command doesn't return after the Starting worker processes... message). When I run 2 workers manually and have the server running on the background I have 3 processes, or 4 if I start the repl.

OK, so that's helpful to know. It sounds like the server is not able to even start the worker processes. But the client is able to start the server process.

So, I'm wondering if this is a Windows-specific permissions issue. It could be the case that the client has permission to start a new process (the server), but that sub-process does not have itself have permission to start more processes (the workers).

@Hemaolle To test my theory, could you try just running alda -v server and watch Task Manager to see if the worker processes start? This is like running alda up, but the server is running in the foreground instead of as a spawned process.

Just 1 process starting with alda -v server.

I thought I could try inserting more logging in the code to debug, but can't figure out how to make a working standalone build of the alda-client-java project with boot. I was able to make a jar and package in some depenencies with the (uber) boot task but still getting Exception in thread "main" java.lang.NoClassDefFoundError: clojure/lang/ISeq. The boot dev task was working but it has the permission problem where it can't even start the server on background.

Well got rid of java.lang.NoClassDefFoundError: clojure/lang/ISeq by adding [org.clojure/clojure "1.8.0"] to the dependencies.

@Hemaolle: I have some information about how to build the alda executable here: https://github.com/alda-lang/alda/blob/master/doc/building-the-alda-executable.md

Basically, you make changes to the subproject (in this case, you're making changes to alda-server-clj to add logging) and in the subproject, run boot package install to install the subproject locally. Then, in the alda-lang/alda repo, run boot build -o /path/to/output-dir/. This does require a Java 8 JDK and launch4j to build the Windows alda.exe.

Let me know if you run into any trouble!

Thanks @daveyarwood, that's really helpful.

I got this error when trying to run the boot build -o /path/to/output-dir/ command.

Writing pom.xml and pom.properties...
Adding uberjar entries...
Writing alda.jar...
Creating alda binary...
Writing E:\Workspace\Ohjelmointi\clojure\alda\build\alda...
Merge conflict: not adding alda
                              java.lang.Thread.run              Thread.java:  748
java.util.concurrent.ThreadPoolExecutor$Worker.run  ThreadPoolExecutor.java:  624
 java.util.concurrent.ThreadPoolExecutor.runWorker  ThreadPoolExecutor.java: 1149
               java.util.concurrent.FutureTask.run          FutureTask.java:  266
                                               ...
               clojure.core/binding-conveyor-fn/fn                 core.clj: 1938
                                 boot.core/boot/fn                 core.clj: 1031
                               boot.core/run-tasks                 core.clj: 1021
                    boot.task.built-in/fn/fn/fn/fn             built_in.clj:  567
                    boot.task.built-in/fn/fn/fn/fn             built_in.clj:  729
                    boot.task.built-in/fn/fn/fn/fn             built_in.clj:  864
              adzerk.boot-jar2bin/eval488/fn/fn/fn         boot_jar2bin.clj:   36
              adzerk.boot-jar2bin/eval540/fn/fn/fn         boot_jar2bin.clj:   90
           adzerk.boot-jar2bin/eval540/fn/fn/fn/fn         boot_jar2bin.clj:   91
adzerk.boot-jar2bin.launch4j/write-launch4j-config             launch4j.clj:   53
                                               ...
                             clojure.data.xml/emit                  xml.clj:  366
                             clojure.data.xml/emit                  xml.clj:  375
            clojure.data.xml/check-stream-encoding                  xml.clj:  362
       java.lang.Exception: Output encoding of stream (UTF-8) doesn't match declaration (Cp1252)
clojure.lang.ExceptionInfo: Output encoding of stream (UTF-8) doesn't match declaration (Cp1252)
    line: 124

Probably some Windows encoding issue.

⬆️ Got the build working with this change in the boot-jar2bin plugin 🙂

Awesome, thanks for the fix! I've merged it and released boot-jar2bin 1.1.1, which Alda is now using.

You are all awesome 👌

Just to be clear, the fix I mentioned above is just so that alda.exe can be built on Windows. There is still some issue with worker processes not starting on Windows.

Oh I see it now.

My comment stands.

Correct, I didn't have time to debug the original issue yet :(

Ok, this ⬆️ seemed to solve the problem for me at least 🙂 Seems that the problem manifested if the alda binary path had spaces in it. Could possibly be reproducable on other OSs too.

Excellent -- this looks promising.

I've released alda 1.0.0-rc76 with the program path fix above. This should allow workers to start if your path to alda or alda.exe contains spaces.

@aktopus @elyisgreat Would you mind running alda update to get the latest version, and then alda up to see if the issue is fixed? The "Starting worker processes..." part shouldn't take longer than a couple minutes at the most. On my machine, it takes about 17 seconds.

Hi Guys!

I've been following this, though I've been relatively quiet since there wasn't much I could personally contribute to it at the time. Thanks for keeping on this! Here's what I'm seeing.

alda update
Your version of alda (1.0.0-rc76) is up to date!

alda up
[27713] Starting Alda server...
[27713] Server up ?
[27713] Starting worker processes...
[27713] Ready ?

I'm finally able to play music with the latest version of Alda again. Thanks so much!

Best,
Ak

Great! And @elyisgreat confirmed in Slack that it's working for him, too.

So, I'll consider this issue resolved. 🏆

🎉 🎉 🎉 🎉 🎉