@tycho.tatitscheff have you ever solved this? I'm experiencing the very same issue...

To clarify: I certainly don't this dependency to be simply swapped for another dependency. Also having 2 server implementations isn't desirable either. I can't judge whether a PHP implementation can challenge the NodeJS implementation because I'm lacking the experience in PHP.

This is very unlikely to happen.

I'd really like to see this happen. So far I haven't used Aphlict simply because I don't want to manage the extra dependency.

See also T7004, although I'm generally not hopeful about being able to build a version of that which feels like it works well.

To restate @PeteA from T9384, the use case we have is "web interface whenever available, emails otherwise."

Ran into the same problem.

D13878 makes bin/mail volume look like this instead:

In T7013#130406, @cburroughs wrote:

• As an admin being able to see people's email settings would be nice, but probably has thorny security issues and I think I can just go figure this out from the DB anyway without too much trouble anyway.

(This command may take a while to run since I was extremely lazy about loading the data.)

We don't actually store the outcome of preference filtering at the time we sent the mail right now (we will after T5791) so I can only report an "Unfiltered" column, which is the maximum number of messages we may have sent (I could do a little better than this now, but it's probably better to hold it until T5791 for a more complete picture). Users with any settings which disable mail will have received less mail than the "unfiltered" number.

I agree that too much email is often a mostly cultural problem. I'm personally only moderately annoyed by email volume, and usually only in cases where a bunch of things happened at around the same time. But I also have 30k unread emails sorted from mailing lists to read on train trips and I suspect most would view that as a bizarre edge case. Batching felt like it might be a salve of sorts for legitimately annoying cases, but I'm not particularly attached to it. Anecdotally some users have reported things along the lines of 'I have used a bunch of other systems and phabricator is the only one I have felt overwhelmed by email with' (I know that feedback is too general to be of much use here.)

Some perspectives from what my users complain about to me w.r.t. mail:

Yeah, I'd group the problems into two spaces. The "email storm", when one action triggers multiple emails (closed a revisions, which closes a task, which unblocks other tasks). Storms also occur when a users wants to take multiple actions on an object, but needs to use multiple interfaces (columns, comments, priority, etc).

Well, no level other than 0.

Yeah -- we can pursue that stuff, but I'm strongly suspicious that user complaints about mail volume aren't meaningfully correlated to actual mail volume and that there is no level we can drive it down to which will meaningfully reduce user frustration.

Another interesting possible solution would looking at T4316, T6027, and M1430. If the specific issue if a user has to go to 5 places to do a basic edit/comment, reducing that into 1 action, 1 email benefits everyone who uses Phabricator.

@chad, do you have any particular objections to disabling all mail (other than welcome / password reset mail, which we obviously need to send) by default-default after we give administrators tools to selectively adjust the defaults in T5791 / T4103? It feels a little extreme to me, but I think we're going to be dealing with this forever if we don't do it.

Put another way, the one case of this which I've conclusively pinned on a root cause was "user is wildly sensitive about email and also would rather complain about it over and over again than spend much less energy fixing the problem", and the fix was "look up volume statistics, roll eyes out of sockets".

Product reasons normally, although technical reasons if metamta.one-mail-per-recipient is enabled (we can't batch mail which must be delivered to multiple distinct recipients).

In T7013#92738, @epriestley wrote:

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.

We do not currently plan to ever batch email.

I added a diff that is way better than what is proposed in description.

Going to close out this out for lack of feedback. Feel free to reopen with specific questions: https://secure.phabricator.com/book/phabricator/article/feedback/

Thank you ~

See Phacility Cluster Network and Phacility Cluster Devices.

Oh, actually, our setup isn't quite like yours. There's one notification LB which sends traffic to one box. Instances just have nlb.phacility.com configured. So no web-tier proxying.

Yeah, this is what we do in the Phacility cluster. We have every instance sharing one notification server with software instancing right now and the box is <1% utilized.

Actually, I think you are correct.

Yes, but are you sure you need it? What are you seeing which indicates a notification server scaling issue?

Would this task be available for paid prioritization?

Yoinking this. If you've made any progress on this, feel free to post a diff, otherwise I'm on it.

I didn't think it would require so much time/help but oki.

We aren't interested in supporting IPv6 in the upstream at this time, and don't have the time or resources to help you develop a patch.

I think people over the net got alse problème behind nginx and proxy when using socket io and only websockets.
Once the connection is etablished, the problems disapeared.
So they configure socket.io to first make long term polling then degrade to websocket .
However I was on public computer when I browse this but I can try to found the link again ?

So some more information.
On the web server :

Ok. Is there some debug log I can activate (nginx or phabricator side ) ?

I don't currently anticipate ever pursuing T6889.

This has magically fixed itself.

I just set up notifications fine here on d8ab5f594c7f9cd05e333f507f2ae26e55c6b411

He uses Doge because of my awesome translations, right @epriestley ;)

Weird, the notifications did come through on my phone.

In T7880#108099, @epriestley wrote:

Do you have the durable chat column open?

haha

Hmm, looking in the network tab in Chrome and I can't actually see a websocket connection.

Do you have a setup warning?

Do you have the durable chat column open?

Could be related to this?

In T7880#108096, @joshuaspence wrote:

Actually, our firewall might be blocking port 22280... that's one of the reasons that I run Aphlict over port 443.

Actually, our firewall might be blocking port 22280... that's one of the reasons that I run Aphlict over port 443.

In T7880#108085, @chad wrote:

I have no idea what "this morning" means time wise in NZ to CA, haha

of course, it is the best

really, @epriestley runs doge on production?

I have no idea what "this morning" means time wise in NZ to CA, haha

I can't immediately reproduce this (see lower left corner):

To copy the globally installed modules, I run the following on boot in the docker image:

Ironically for the docker image I built, it has to install WS from the system package manager because NPM doesn't work right. On boot it then copies the globally installed ws underneath the server folder.

So we are not really unable to rely on a packager manager for such ?

Just like how global variables are kind of gross, but also necessary in some cases, global packages are important, but best avoided if not needed.
In general, the rule of thumb is:
If you’re installing something that you want to use in your program, using require('whatever'), then install it locally, at the root of your project.

Regarding use cases, I have TLS locked down in Nginx and neither want to maintain a TLS configuration in multiple places nor even understand how to properly configure cipher suites, stapling, and other such things in the aphlict daemon (if it's even possible). A reverse proxy allows me to re-use my known good TLS configuration.