-
Notifications
You must be signed in to change notification settings - Fork 28.6k
[SPARK-11572] Process outstanding requests after seeing stop flag #9723
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
Conversation
Test build #45961 has finished for PR 9723 at commit
|
Test build #45966 has finished for PR 9723 at commit
|
I'd like @zsxwing to help take a look at this and figure out whether this is a sufficient fix or whether we should revert your original patch and go back to the drawing board. |
It's possible that there's a cleaner way to fix the original bug that motivated the incorrect patch vs. trying to patch up the problems introduced by the fix by layering more fixes on top. Let's see. |
Test build #45962 has finished for PR 9723 at commit
|
Test build #45968 has finished for PR 9723 at commit
|
Test build #45973 has finished for PR 9723 at commit
|
I think the above was not related to change in AsynchronousListenerBus |
IMO, we should revert 3e0a6cf The user should not call I cannot see an approach since we need to stop the listener bus's thread before stopping SparkContext/StreamingContext totally. |
I'm going to revert those commits now to try to unbreak the SBT builds. |
Sounds like we should prevent the call to StreamingContext#stop() in the listener bus's thread. |
Sound like a good idea. Ping @tdas, what do you think? |
…ener bus's thread See discussion toward the tail of #9723 From zsxwing : ``` The user should not call stop or other long-time work in a listener since it will block the listener thread, and prevent from stopping SparkContext/StreamingContext. I cannot see an approach since we need to stop the listener bus's thread before stopping SparkContext/StreamingContext totally. ``` Proposed solution is to prevent the call to StreamingContext#stop() in the listener bus's thread. Author: tedyu <yuzhihong@gmail.com> Closes #9741 from tedyu/master. (cherry picked from commit 446738e) Signed-off-by: Tathagata Das <tathagata.das1565@gmail.com>
…ener bus's thread See discussion toward the tail of #9723 From zsxwing : ``` The user should not call stop or other long-time work in a listener since it will block the listener thread, and prevent from stopping SparkContext/StreamingContext. I cannot see an approach since we need to stop the listener bus's thread before stopping SparkContext/StreamingContext totally. ``` Proposed solution is to prevent the call to StreamingContext#stop() in the listener bus's thread. Author: tedyu <yuzhihong@gmail.com> Closes #9741 from tedyu/master.
…ener bus's thread See discussion toward the tail of apache/spark#9723 From zsxwing : ``` The user should not call stop or other long-time work in a listener since it will block the listener thread, and prevent from stopping SparkContext/StreamingContext. I cannot see an approach since we need to stop the listener bus's thread before stopping SparkContext/StreamingContext totally. ``` Proposed solution is to prevent the call to StreamingContext#stop() in the listener bus's thread. Author: tedyu <yuzhihong@gmail.com> Closes #9741 from tedyu/master.
This is to address the regression Josh discovered.