Perhaps something like, "Peak Load" would be a better metric.

Yeah... I guess it would be good to have other time frames as well. The daemons could be running at 100% for a few hours in a day but then sitting idle for the rest.

That's only over the previous 15 minutes though right?

Is this still happening? The SWF has changed a lot since this was opened.

I'm reasonably satisfied that this is complete now. Feel free to re-open (or file a new ticket) if there is anything clearly missing.

Gotcha, thanks for clarifying.

Thanks @epriestley... do you know what slam defense is? I can't quite get my head around it.

It's probably related to this PHP bug.

Things left to do here

• Implement unsubscription.
  • The AphlictClient should unsubscribe (probably implicitly) from all PHIDs when the client is closed.
  • The AphlictMaster should unsubscribe from a given PHID when there are no more clients subscribe to that PHID.
• Clients need to re-send their subscriptions when a new master is created. I think that all subscriptions will basically be lost at the moment if the master dies or is ended. The clients should probably re-send all of their subscriptions when a new master comes alive.
• General maintenance and cleaning up.

@fzhan, usually this is a firewall issue. Are you able to connect to port 843 on the host?

Closed by commit rARC02e3905cf50a.

Let me see if I can come up with something.

If differential.getrevisioncomments has been deprecated... then shouldn't the arc inlines workflow be deprecated too?

A few links for reference:

Possibly, one real issue at the moment however, is that arc lint will fail to lint these files altogether (none of the linters will be able to read the contents of such a file).

I'm happy to work on this, but have one question... Would you rather that this be done as a binary (like xhpast is) or using PhutilParserGenerator?

Closed by commit rARC86eec5b44c71.

In T5297#4, @epriestley wrote:

I'm a bit hesitant about making the formats we parse more flexible (with comments, trailing commas, optional quotes / single quotes, ...), since I think that's a bit of a dangerous road to walk down (and, e.g., that T5260 isn't a great argument for it: high-complexity use cases should reasonably use Engines or generator scripts), but I'm not completely against it.

In T5297#4, @epriestley wrote:

The major desirable result to me would be raising better parsing errors, e.g. "unexpected comma on line 23 in .arclint" instead of "this is not a JSON file". The errors we raise are quite bad/unhelpful right now.

(I think the underlying cause of the security error is that the Aphlict server isn't running on port 843, so the client isn't able to read the policy file)

In T5258#20, @epriestley wrote:

They should be able to upload it, we just won't thumbnail it. In cases where we need a thumbnail we would probably substitute a generic thumbnail ("this enormous image has too much beauty to contain, click to view it" rendered over a pastoral scene or something).

What is the expected behavior when a user uploads an image that is "too large" for a thumbnail to be generated? I feel as if users should be free to upload any image (so long as its size is less than storage.upload-size-limit or whatever). My understanding, now, is that there are two competing limits here:

In T5097#14, @epriestley wrote:

Well, you can fake chunking with something like this, instead of running --everything directly:

git ls-tree -r --name-only HEAD | xargs -n128 arc lint --lintall --never-apply-patches

Perhaps that 30sec timeout should/can be made configurable?

In T5258#13, @epriestley wrote:

They're on-demand, but cached after the first request.

I think there are a couple of issues with the {meme, src=...} form specifically -- like if you don't specify any text, we don't reuse the raw file and instead split out all the frames, put "no text" on them, and then covert them back to a GIF. This is pointless and silly.

OK, quite possibly. Surely, however, paying a significant performance penalty is better than exhausting all available RAM?

Oh OK, that makes sense...

@epriestley, I guess a way to describe the way things are currently working is as linter-first (lint all paths through a single linter and then progress to the next linter).

Just bringing in these related comments:

Also, this explains why users have been reporting that Aphlict was generating an "Error #2048" error. This was largely fixed by D9418, but the root cause was that the Aphlict client was being created (even though notifications were disabled) and failing to connect to the (non-running) Aphlict server.

This might be tricky to handle correctly.

Some info here: https://lists.debian.org/debian-devel-announce/2012/07/msg00002.html

A more difficult problem would be determining if the node/nodejs binary is actually NodeJS... I believe that the reason that node became nodejs was due to conflicting with an existing package.

In T5288#5, @epriestley wrote:

Add a filter to show only projects that I haven't joined.

This seems different from the task title. :)

(Both filters seem reasonable to me.)

Closed by commit rP0a534d1d1f9b.

@epriestley, I've moved some of your wishlist into T5284 since it's not-quite-related to this ticket. This ticket itself is almost complete IMO.

I think in order to fix this, Aphlict should be moved out of core.pkg.js and it should only be included if PhabricatorEnv::getEnvConfig('notification.enabled') is true.

Some discussion on chatlog.