Summary:
delayedUnsafe() is unsafe because it disregards the executor you have specified, and uses the default one.
Depending on the context, this can sometimes be an InlineExecutor, and since some of the scheduled jobs, schedule instances of themselves, this can cause infinite recursion to occur.
Fixing this by using the safe variant of delayed, and also using a new instance of IOExecutor.
We need a new Executor for the Sonar loop, because if we use the same worker thread as is provided to RSocket, we get deadlock when we wait for rsocket to connect.
Reviewed By: danielbuechele
Differential Revision: D8617679
fbshipit-source-id: 51ab3224b93e774596a8799338e7391e2eb956cb
Summary:
There's an issue with folly's delayedUnsafe(), where it drops your executor and effectively
runs all futures inline, in this case instead of scheduling tasks for the future, it grows the stack indefinitely.
This fixes the issue by using the safe delayed(), which preserves the executor, so the jobs get shceduled on a different thread as intended.
Reviewed By: LeeHowes
Differential Revision: D8575956
fbshipit-source-id: c5b2ced43a70505c51883281f202ac947ae6723f
Summary:
When an app with sonar is run for the first time, the necessary files don't exist.
This is expected, so don't output an error, only error if they do exist but there's some other problem.
Reviewed By: emilsjolander
Differential Revision: D8350995
fbshipit-source-id: ff0a4f0e7a73848f6172c6108a0caee6efb43553
Summary:
If the app has an old CSR with data that is incompatible with sonar, we can't use it.
An example of this happening is when we moved the package name from organisation to common name in the certificate subject.
To get around this, always create a new one to guarantee it contains what we expect.
Reviewed By: emilsjolander
Differential Revision: D8350247
fbshipit-source-id: e53148fcddc47aa60e3daef5bbf36ce330a3b4e9
