3.5.7 3 - commits #932
Merged
3.5.7 3 - commits #932
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Summary Always send initial event on subscription. Details This removes a check from the subscription logic for internal communication which prevented notifications from being sent if a client re-subscribed to an active subscription. The issue was that in the case where the subscription was not properly canceled, such as during a suspend cycle, the new subscription would not trigger the initial events that the client was expecting. Since the client is the one interested in maintaining the subscription, we should consider it the authority regarding the subscription status and treat its requests accordingly.
Summary Applications that use vsomeip as inter thread mechanism receive multiple times ADD_CLIENT command from routingmanager since they are the provider of the service they consume. Moreover, this PR also introduces a minor refactor concerning the registration order. Details Applications that use vsomeip as inter thread communication mechanism will receive the ON_ROUTING_INFO ADD_CLIENT message from the registration process and an additional message for each time it consumes a service that itself provides: AAAA BBBB VSIP 336 log info verbose 1 Application/Client 6102 (..Service) is registered. AAAA BBBB VSIP 336 log info verbose 1 Application/Client 6102 (..Service) is registered. AAAA BBBB VSIP 336 log info verbose 1 Application/Client 6102 (..Service) is registered. AAAA BBBB VSIP 336 log info verbose 1 Client [6102] @ xxx.xx.xxx.xxx:10501 is connecting to [6102] @ xxx.xx.xxx.xxx:10500 endpoint > 0xaaaaebc14820 Alternative: Ensure routing manager doesn't send ROUTING_INFO ADD_CLIENT command when provider and consumer ids match. The registration order is updated so that the registered state change only occurs when the registered_ack and pending offers are successfully sent to the routing manager.
Details In short: a) decrease frequency (logging every 10s is fine!) b) use server logging c) decrease threshold (64KB is already massive!) It would be invaluable in cases where UDP queues are definitely filling up
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.