-
Notifications
You must be signed in to change notification settings - Fork 692
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
[BUG]: vsomeip slow to restart with lots of EventGroup #690
Labels
Comments
We came up with 3 possible solutions;
Interested in feedback on what would be most effective |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
vSomeip Version
v3.4.10
Boost Version
1.82
Environment
Android and QNX
Describe the bug
My automotive system has
*.fidl
with ~3500 attributes, one per CAN signal. My*.fdepl
maps each attribute into a unique EventGroup.Especially when resuming from suspend-to-ram it's possible that UDP SOMEIP-SD will be operational but TCP socket will be broken. This leads to tce
restart()
but during this time any Subscribe will receive SubscribeNack in response:as the number of EventGroup scales to a large number, this become catastrophic to performance.
In
service_discovery_impl::handle_eventgroup_subscription_nack()
each EventGroup callsrestart()
:vsomeip/implementation/service_discovery/src/service_discovery_impl.cpp
Lines 2517 to 2521 in cf49723
and in
tcp_client_endpoint_impl::restart()
while::CONNECTING
the code will "early terminate" from maximum 5 restarts:vsomeip/implementation/endpoints/src/tcp_client_endpoint_impl.cpp
Lines 77 to 85 in cf49723
thereafter the code will fall through, calling
shutdown_and_close_socket_unlocked()
and perform the full restart even while a connection is in progress.As the system continues processing 1000s of SubscribeNack this will be a tight loop of 100% cpu load and multiple seconds to plow-through the workload. This can easily exceed a 2s ServiceDiscovery interval and cascade to further problems.
Reproduction Steps
My reproduction was:
but any use-case where tse closes the TCP socket but UDP is functional should be sufficient.
Expected behaviour
Performance should be better.
Logs and Screenshots
No response
The text was updated successfully, but these errors were encountered: