Thanks, I'll get on it.

I'd be happy to play with your patch.

Very interested in this. Willing to contribute code if someone will have time to look at the patch (it doesn't have to be accepted, I just want to know that I am not stepping into something that is unlikely to get merged any time soon).

Effectively merging into T7567.

Thanks, D11906 should fix this.

administrator@ubuntu:/phabricator/phabricator$ ll /var/tmp/
total 12
drwxrwxrwt 3 root root 4096 Feb 27 18:32 ./
drwxr-xr-x 14 root root 4096 Oct 24 18:31 ../
drwxrwxr-x 4 phd-user phd-user 4096 Oct 23 14:46 phd/

haha, thanks @joshuaspence

@anton.vladimirov this should have been resolved by the commits here, not sure what more information you can give us why that didn't occur.

@anton.vladimirov, what are the permissions on the /var/tmp directory?

You are right, systemd does not execute ExecStop when running systemctl restart and it considers the service as stopped for whatever reason. I made it aware of the status of the service by adding PIDFile=/var/tmp/aphlict/pid/aphlict.pid, so it will select the appropriate command.

I can't reproduce this. Can you reproduce this if you don't use systemd? Specifically, does aphlict stop followed by aphlict start fail if run manually?

Pretty sure I caught this.

I think that this is resolved now.

Working at HEAD. Thanks again!

Interesting, the log line placed just before incrementing the messages.in variable is executed (a lot) but the variable stays at 0. I'll have a look.

This was due to _listeners.length being undefined in the getActiveListenerCount() function, I'll post a patch.

This is only used on the status page, so it doesn't actually affect anything.

Some more comments, now that I managed to get it working - aka. the server receives connection from Phabricator, though it creates a new listener every 2 seconds and they never disconnect (due to passing through nginx?).

The client-port parameter is parsed from notification.client-uri and automatically passed as an argument to aphlict start. Could the same behaviour be added to client-host? Maybe I should create a new task for that.

I have a few ideas on how to improve this.

I think I fixed this in D11423, particularly:

Getting through nginx I don't need to open another port in my firewall - I tend to close everything, and use SSH tunnels to connect to my IRC bouncer and so on - and I don't have to authorise aphlict to read my SSL private key as nginx is already configured to use SSL.

Out of curiosity, what's your reasoning for passing this through nginx instead of configuring a direct connection?

No, this refers to real-time notifications only. Users will see no difference in behavior (except an imperceptible delay in some lower-priority real-time notifications). This only improves scalability.

This means that users will also less bugmail, right? Our advanced users are noticing a big increase of email notifications compared to Bugzilla, with a detrimental effect. Maybe we want to wait more than a second in order to merge sequential user actions. There is a related request in Wikimedia Phabricator: Email notifications should bundle events as the web interface does

The master server would only know about the subservers.

As an aside, I still think it would be nice to send the notification contents rather than just the key (to avoid the extra request to /notification/individual/). Possibly this would be easier with WebSockets than it would have been with Flash.

Does that solve the scaling issue though? Essentially, all Aphlict servers need to be aware of (I.e. store in memory) all clients and all subscriptions. Realistically, I wouldn't expect this to cause any issues for any installs today, but possibly as Aphlict receives more usage it might?

I believe no install will encounter issues with this for a very long time, but we can scale it like this:

This has been discussed on the https://groups.google.com/forum/#!topic/nodejs/zF7GEoPccqw as well.

Interesting. So ./bin/aphlict debug exits with 1 but running node './support/aphlict/server/aphlict_server.js' '--client-port=22280' '--admin-port=22281' '--admin-host=localhost' '--log=/var/log/aphlict.log' exits with 0.

Both of the linked fixes landed, so this should now be fixed in HEAD. Thanks for the report!

Also from the logs:

I'm very sneaky.

Didn't realize that @epriestley stole this one.

I forgot about the debug start of service. To confirm your suspicions @epriestley:

Two issues here:

Okay, that sounds reasonable.

This task is about removing an external dependency (for security and simplicity), not really swapping one for another.

There's also a WebSocket framework called Ratchet, which is built upon React. I used it for some small apps in the past and it worked quite well for me.