Summary:
The plan is to add such state annotations around all core sonar tasks, so the diagnostic screen can show a useful up to date picture of what's going on.
This is the first batch of such annotaions, to act as a tracer while putting the rest of the diagnostics code in place.
Reviewed By: passy
Differential Revision: D9150555
fbshipit-source-id: 5c25205ecc690f0101b444681be48b823b0cb052
Summary:
The plan is to get SonarState to take update events and aggregate them into an object, that can be displayed in the UI so you can see what sonar is currently trying to do, and what if anything is failing.
This is pretty rubbish right now, as it just uses a single string to represent state, this is just the initial version I'll iterate on.
I also need to pass the SonarState into the SonarWebSocketImpl, since that's where a lot of the heavy lifting is done, but as long as something is logging state updates here, it proves the concept.
SonarStateUpdateListener is the interface that will be implemented by android and iOS implementations. These implementations will notify an activity or screen that the state has changed and they should reflect that.
Reviewed By: danielbuechele
Differential Revision: D9150551
fbshipit-source-id: 8dd585ca503d32e684ff843d66a59a50a420b4c0
Summary: Releases a new iOS version 0.6.16. After landing this I will release 0.6.16 tag on github
Reviewed By: danielbuechele
Differential Revision: D9194965
fbshipit-source-id: 13d5e346d6d34a7bf7b6dfb568ca622d97660132
Summary:
Prior to this diff the OSS sonar project depended on folly's master branch instead of tags, which is not good as things can break, which broke recently. So this diff adds the folly dependency thru tags to avoid any future failures.
This diff releases a new folly dependency which relies on a tag
Reviewed By: danielbuechele
Differential Revision: D9194966
fbshipit-source-id: 0a0956f0bd457e375fcbb86b3fec412aeb759a47
Summary: These will be displayed in the sonar diagnostics screen, for troubleshooting connection issues.
Reviewed By: passy
Differential Revision: D9117508
fbshipit-source-id: 6481f127b908fa539fe1fed1e268a28fa357d6f8
Summary:
The plan is to add such state annotations around all core sonar tasks, so the diagnostic screen can show a useful up to date picture of what's going on.
This is the first batch of such annotaions, to act as a tracer while putting the rest of the diagnostics code in place.
Reviewed By: passy
Differential Revision: D8954014
fbshipit-source-id: 864156b0d3f51eeb05c2c8916c1765e834f1dc8e
Summary:
The plan is to get SonarState to take update events and aggregate them into an object, that can be displayed in the UI so you can see what sonar is currently trying to do, and what if anything is failing.
This is pretty rubbish right now, as it just uses a single string to represent state, this is just the initial version I'll iterate on.
I also need to pass the SonarState into the SonarWebSocketImpl, since that's where a lot of the heavy lifting is done, but as long as something is logging state updates here, it proves the concept.
SonarStateUpdateListener is the interface that will be implemented by android and iOS implementations. These implementations will notify an activity or screen that the state has changed and they should reflect that.
Reviewed By: passy
Differential Revision: D8932114
fbshipit-source-id: fb03babfe92be53771eb4d8f10de7ecdc7f1a6d8
Summary:
Overall plan to modify Future<T>::then to be r-value qualified and use Future<T>::thenTry or Future<T>::thenValue.
The goal is to disambiguate folly::Future and to improve type and lifetime safety of Future and its methods.
4/n: Codemod:
* rvalue-future<T>.then(callable with operator()(not-a-try)) to rvalue-future<T>.thenValue(callable with operator()(not-a-try)).
* rvalue-future<T>.then(callable with operator()()) to rvalue-future<T>.thenValue(callable with operator()(auto&&)).
* rvalue-future<T>.then(callable with operator()(auto)) to rvalue-future<T>.thenValue(callable with operator()(auto)).
Applied to xplat.
Reviewed By: marshallcline
Differential Revision: D9133114
fbshipit-source-id: 30cc4f0480ca04b3abda54af3aafd9fc4dfdf0e0
Summary:
This PR adds support for using SonarKit clients in Swift apps. Fixes#13, fixes#87
1. Swift can't import Obj-C modules which have C++ headers. For this reason, we use SonarKit as an Obj-C++ wrapper around Sonar, which is written in C++. Due to search path misconfiguration, trying to import SonarKit into a Swift project would import `xplat/Sonar/SonarPlugin.h` instead of `iOS/SonarKit/SonarPlugin.h`, which caused `file not found` errors for C++ stdlib imports like #28 because new projects don't have their search paths set up correctly.
2. The network and layout plugins have C++ definitions (struct methods, classes) in some of their headers. This causes the compiler to get confused for Swift projects, because it only supports importing Objective-C files in umbrella headers, meaning that the `SonarKit` won't build.
1. I updated the `HEADER_SEARCH_PATHS` of SonarKit.podspec's build configuration to include `${PODS_ROOT}/Headers/Private/SonarKit/**` first, which alleviates the search path issue. The Obj-C `Sample` project seems to have worked around this by including a hardcoded `${PODS_ROOT}/SonarKit/**` search path in the pbxproj, which is why Sample works but new projects (like those referenced in #28) don't. I removed this since it's no longer necessary.
2. I added a `SampleSwift` app to demonstrate using Sonar with a Swift project.
3. Because the Podfiles for `Sample` and `SampleSwift` referenced podspecs using `:podspec` instead of a concrete version, Cocoapods wouldn't copy local header files (instead, it downloads them from the source). To enable local development of these sample apps using `:path`, I added a symlink to SonarKit.podspec in the root of the directory.
4. I changed SonarKit.podspec to use a tag-based `source`, since v0.0.1 pulls from the master branch of this repo.
The layout and network plugins still don't work with Swift - in order to fix this, we'll need to work on extracting the C++ out of their headers and writing Obj-C++ wrappers for them. I decided to push this off to a later PR since this one is quite large already.
This means that we need to be able to `import SonarKit` without importing all the network/layout plugin headers. In order to make this work, I made "SonarKit/Core" the spec's `default_subspecs`.
priteshrnandgaonkar, let me know if you have any thoughts on this implementation. You can verify that the SampleSwift app works by checking out this branch, `pod install`ing in the SampleSwift directory, and building it :)
Pull Request resolved: https://github.com/facebook/Sonar/pull/106
Reviewed By: jknoxville
Differential Revision: D8890010
Pulled By: priteshrnandgaonkar
fbshipit-source-id: 449305bcc5cbeb5787c23f51b1ecb80a5cbdad32
Summary: SonarConnection should have an `error` function; this stubs out the mock to have this, allowing creation for tests.
Reviewed By: jknoxville
Differential Revision: D8878130
fbshipit-source-id: 9e0f45dac4ba31ee650dfd46dcee51207cc7a9b4
Summary:
This diff adds the support to automate iOS releases. This diff adds two scripts, one for updating all the `podspecs`, and `podfiles` with updated version number. The script also updates the version used in sample and getting started doc file.
The second script publishes a github tag.
Following will be the process for iOS release:-
1. From `fbobjc/Libraries/SonarKit/Scripts` run `sh public-ios-podspec-update.sh`, it will update all the podspecs, podfiles and docs with updated version number. Commit it and land this
2. Once the above changes are landed and synced to github, run `sh push-new-github-tag.sh` from `fbobjc/Libraries/SonarKit/Scripts` to push the tag on github
As a follow up on this diff, ideally, we should trigger second script automatically when the 1st task changes are synced to github.
Reviewed By: jknoxville
Differential Revision: D8879958
fbshipit-source-id: 8f0dc9200e8f64578af33e1446629f09c16c43f2
Summary:
This moves the native setup to a separate gradle file and unpacks everything outside the build folder. That way we don't throw everything away on every incremental build.
This is an intermediate step to get to a more declarative setup like Fresco has it and get rid of the individual hacks we have for every download.
Pull Request resolved: https://github.com/facebook/Sonar/pull/154
Reviewed By: jknoxville
Differential Revision: D8833812
Pulled By: passy
fbshipit-source-id: 2424c9d6e22e6092c04af344e06939b4a6aba041
Summary:
This diff uses `tag` instead of master branch and also updates the version number to the desktop sdk.
Pull Request resolved: https://github.com/facebook/Sonar/pull/152
Reviewed By: danielbuechele
Differential Revision: D8820016
Pulled By: priteshrnandgaonkar
fbshipit-source-id: ff2e554be55254b77c4e130b35b7299abbafa77d
Summary:
Compile against a static version of OpenSSL for better compatibility
with apps that already use OpenSSL in some fashion.
Pull Request resolved: https://github.com/facebook/Sonar/pull/149
Reviewed By: priteshrnandgaonkar
Differential Revision: D8804169
Pulled By: passy
fbshipit-source-id: 4de66a77806a3b3f01b2cf5f253916f2cf6f48e8
Summary:
One design goal of sonar is to never cause the host app to crash or hang.
For this reason, we do all heavy work in a background thread.
If we detect that it's not running in it's own thread, just return so we don't hold up the caller.
Reviewed By: danielbuechele
Differential Revision: D8767288
fbshipit-source-id: e146cc2cfe5c3e62d12f527ff79f24c74873d4ff
Summary:
Having another attempt at removing this. It's unsafe because it in some cases executes the .then() task in the timekeeper thread, rather than the executor the original future is using.
When that default executor is an InlineExecutor, for example, you can get stack overflow.
I tried to remove this use before, but having the same thread used for both the sonar client itself and rsocket, meant that they entered a deadlock trying to connect.
Now that I've separated those jobs into separate threads, they can execute independently.
Reviewed By: danielbuechele
Differential Revision: D8748356
fbshipit-source-id: a1029ece2c7006ad7642cbf8aa59e692c76b19b2
Summary:
We currently give sonar one event base from java / obj-c code to use for scheduling tasks.
This causes a problem, because we schedule reconnect tasks on the event base, and then these tasks interact with rsocket which schedules it's own tasks.
The problem is that we're passing rsocket the same event base. So the reconnect code executes and blocks waiting for rsocket to connect.
But rsocket can never connect because it never executes because that thread is blocked, so we get deadlock.
This is the first step which just changes the interface to pass two event bases.
The consumers will be changed to pass in different threads next.
Reviewed By: danielbuechele
Differential Revision: D8748350
fbshipit-source-id: 481d6f23644f28fd0f1c786252605287019c999c
Summary:
This uses OpenSSL 1.1.0h to build and link against. The `.so`s are
precompiled and hand-patched from [this
repository](https://github.com/passy/android-database-sqlcipher). The
patching was necessary to fix the `SONAME` and corresponding `NEEDED`
flags to *not* contain a `.1.1` version suffix as Gradle will refuse to
bundle those.
We basically only use the headers for the remaining part.
The precompiled version contains ABI support for `arm64-v8a`, `armeabi`,
`armeabi-v7a`, `x86` and most importantly `x86_64`. HOWEVER, `x86_64` is
still excluded for now because folly fails to compile due to a missing
compiler flag:
```
error: needs target feature pclmul
```
This should be easily fixable by ensuring that `-mpclmul` is added to
the CFLAGS if we're compiling for an `x86_64` target in the
`CMakeLists.txt` for Folly.
Closes#113.
Closes https://github.com/facebook/Sonar/pull/125
Reviewed By: priteshrnandgaonkar
Differential Revision: D8723636
Pulled By: passy
fbshipit-source-id: 41c61047d2793ebaef5793a3c937c4d628471d6a
Summary:
Set up our fbjni sub-project to be published to Maven Central.
This removes a bunch of abiFilters that we no longer make use of, too.
Closes https://github.com/facebook/Sonar/pull/119
Reviewed By: priteshrnandgaonkar
Differential Revision: D8694537
Pulled By: passy
fbshipit-source-id: de246fbda99c02856fbc7806b78df2114cb82acb
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
