Stun client transaction re-transmission based on ScheduledThreadPoolExecutor
#153
Conversation
This file contains 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
|
@bbaldino could you please review these changes? |
bbaldino
reviewed
Oct 31, 2018
bbaldino
approved these changes
Oct 31, 2018
|
@bbaldino could you please merge this if no other approvals needed? |
|
was just waiting for the tests to pass |
mstyura
deleted the
stun-client-transaction-retransmit-scheduled-thread-pool
branch
This was referenced Feb 6, 2019
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.
Re-implemented STUN Client transaction re-transmission based on
ScheduledThreadPoolExecutor.This allowed to avoid usage of complicated synchronization primitives and enhanced thread's re-use in the thread pool.
It also fixed test
testMaxWaitIntervalConfigurationParameterinTransactionSupportTests.javawhich counted number of re-transmission attempt.Previous implementation had bug when doubling re-transmission delay - it exceed max allowed delay.
Observed enhancement in my environment:
30conferences with3audio only peers each.Before: 233 threads inside
StunClientTransactionthread pool.After: 1 Thread instance inside
StunClientTransactionthread pool.