-
Notifications
You must be signed in to change notification settings - Fork 130
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Replaced spawn of multiple queues in subscriptions for a single queue… #28
Replaced spawn of multiple queues in subscriptions for a single queue… #28
Conversation
Thanks for the PR @MarioBajr ! I am looking into this and will reply back. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks again for the PR! The changes look good to me. I will do some testing on my side to validate some real-world scenarios and will approve once I am done validating those.
Awesome, thank you too. |
self.subscriptionsQueue.async { [weak self] in | ||
let semaphore = DispatchSemaphore(value: 0) | ||
|
||
self?.performSubscriptionRequest(completionHandler: { (success, error) in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I applied this pr in my personal repo and it improved a lot. only small question about the weak self. Tested and found that I have to manually keep a strong reference of the watcher otherwise the performSubscriptionRequest method won't be called because self is nil and the semaphore will wait forever which will affect all other subscriptions. That is what I found, not sure whether I'm using it correctly,
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're absolutely right, it should bail out on self = nil
before acquiring the semaphore. Will submit a fix. The behaviour of not performing the subscription if the watcher gets dealloc is correct though. You should retain the watcher if you have interest in the subscription, releasing it to unsubscribe as you can see in the deinit
.
Hello @MarioBajr Could you please rebase the changes before I could merge them? Thanks, |
… provided by AppSyncClient. Added a small cancellable delay in MQTTClient to avoid sequential disconnections and reconnections socket requests while subscribing to multiple topics.
…acquiring the semaphore while starting the subscription.
… init and removing the requirement of retaining subscriptionQueue - Guaranteeing management of all AppSyncMQTTClient ivars in the same internal background queue.
Done 👍 |
Great! Will merge this soon 😄 |
…TTClient - Fixed AppSyncMQTTClient holding MQTTSubscritionWatcher strongly - Added unit tests to AppSyncMQTTClient - Configured travis to run unit tests
@MarioBajr Sorry for the delayed response. Can you resolve the conflicts and update the PR? |
Hi @kvasukib, sorry for the delay, was on holidays :) |
- Fixed AppSyncMQTTClient merge error - Fixed AppSyncMQTTClient calling unsubscribe on AWSIoTMQTTClient in unstable states - Disabled AWSAppSyncTests because it requires some work to be able to run within a CI
Done, had to skip |
@MarioBajr I was trying to integrate these changes, but I am running into issues while testing on my side. Whenever I have more than 1 subscription, it was not working. Have you seen any such behavior on your side? I want to get the improvements in too so want to determine the best path ahead. To be more specific: In the functional tests, the subscription tests do not pass(but they can be attributed to the way they are written and need to be updated to be correctly threaded.) But when I use a sample app where I have 3 subscriptions, and I cancel 1, all 3 seem to get cancelled. |
func remove(subscription: MQTTSubscritionWatcher) { | ||
synchronized() { | ||
dictionary.forEach({ (element) in | ||
element.value.allObjects.filter({ $0.getIdentifier() != subscription.getIdentifier() }).forEach({ (watcher) in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this should be ==
instead of !=
element.value.allObjects.filter({ $0.getIdentifier() == subscription.getIdentifier() }).forEach({ (watcher) in
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I identified a bug which needs to be fixed, it is pretty easy so I might do it if you don't get a chance. Needs additional validation though. I made the above mentioned fix and everything looks good after those changes. I will keep doing some additional validations to make sure there is no breaking behavior.
.travis.yml
Outdated
@@ -13,17 +13,17 @@ before_deploy: | |||
- carthage build --no-skip-current | |||
- carthage archive $FRAMEWORK_NAME | |||
script: | |||
- xcodebuild -workspace AWSAppSyncClient.xcworkspace -scheme AWSAppSync build test -destination 'platform=iOS Simulator,name=iPhone 6,OS=latest' | |||
- xcodebuild -workspace AWSAppSyncClient.xcworkspace -scheme AWSAppSync build |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any reason to remove tests from running in travis to validade PRs?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is definitely a good idea to run the tests on travis. I am working to add some encrypted variables(API URL info, auth information) which would help run the functional tests as well. I will enable along with them 😃
Nice catch, will add some tests covering this before submitting the fix. |
Awesome! I also identified an issue with the existing integration(functional) tests: Here since we are doing |
- Added tests covering the bug above - Fixed integration test that were canceling AppSync subscription before fulfilling tests expectations
Currently batch subscriptions spawn multiple background queues, and apart from the running subscription request, all others sit in the wait state, consuming unnecessary resources and affecting requests from other
AWSAppSyncClient
instances.Also for every subscription request,
AppSyncMQTTClient
disconnects all previously connected sockets and connects to the new endpoints, consuming unnecessary resources in case of a batch subscription request.Description of changes:
SubscriptionsOrderHelper
to coordinate sequencial subscription requests with a single queue owned byAWSAppSyncClient
MQTTClient
to avoid sequential disconnections and reconnections of the socket while subscribing to multiple topics.