-
Notifications
You must be signed in to change notification settings - Fork 34
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
Bugsnag prevents JVM from shutting down normally #151
Comments
Hi @smory Thanks for the report. Our team are just discussing the best way forward to resolve this issue. |
Hey, we just encountered this same issue at Robinhood. Is there an update on a fix? |
Hi @bootstraponline thanks for letting us know! We do not currently have an eta for work on this. We will be sure to update back here when we have an update. |
I just got bitten by this issue in a Dataflow project, the Bugsnag logback appender was causing the process to hang. Any updates? |
Hi @nullobject no updates at present. We will be sure to update here when there are. |
The fix to prevent a resource leak in #143 removed the task scheduler running as a daemon thread and so doesn't exit unless the application is explicitly exited (via System.exit) or the thread is explicitly stopped (via bugsnag.close). This fix should be the benefits of both #143 and #121 to gracefully shutdown in both use cases. fixes #151
The fix to prevent a resource leak in #143 removed the task scheduler running as a daemon thread and so doesn't exit unless the application is explicitly exited (via System.exit) or the thread is explicitly stopped (via bugsnag.close). This fix should be the benefits of both #143 and #121 to gracefully shutdown in both use cases. fixes #151
The fix to prevent a resource leak in #143 removed the task scheduler running as a daemon thread and so doesn't exit unless the application is explicitly exited (via System.exit) or the thread is explicitly stopped (via bugsnag.close). This fix should be the benefits of both #143 and #121 to gracefully shutdown in both use cases. fixes #151
The fix to prevent a resource leak in #143 removed the task scheduler running as a daemon thread and so doesn't exit unless the application is explicitly exited (via System.exit) or the thread is explicitly stopped (via bugsnag.close). This fix should be the benefits of both #143 and #121 to gracefully shutdown in both use cases. fixes #151
The fix to prevent a resource leak in #143 removed the task scheduler running as a daemon thread and so doesn't exit unless the application is explicitly exited (via System.exit) or the thread is explicitly stopped (via bugsnag.close). This fix should be the benefits of both #143 and #121 to gracefully shutdown in both use cases. Updated the Spring Boot app test and example to remove explict System.exit call as this should not be required. fixes #151
The fix to prevent a resource leak in #143 removed the task scheduler running as a daemon thread and so doesn't exit unless the application is explicitly exited (via System.exit) or the thread is explicitly stopped (via bugsnag.close). This fix should be the benefits of both #143 and #121 to gracefully shutdown in both use cases. Updated the Spring Boot app test and example to remove explict System.exit call as this should not be required. fixes #151
This has now been fixed and released in v3.6.2 |
Expected behavior
When all non daemon threads of any app finish, the JVM shuts down normally... After implementing Bugsnag JVM still runs. This behavior is not what I expect, especially for AWT/Swing apps.
Steps to reproduce
`public class Test {
}`
JVM will never shut down...
Version
3.6.1
Additional information
If this cannot be fixed, please update your implementation guide to call System.exit(0) or bugsnag.close() somewhere in the code. Calling System.exit(0) is not common in AWT/Swing apps as user closes window and UI thread finishes normally.
This issue made our app update mechanism broken as JVM was running and old jar couldn't be overwritten with new one. Also it made our app unusable after broken update as we use FileLock to enable single instance of app and and lock was never released as JVM kept running. This has broken around 100 installations of our app before we realized what has happened and stopped update. Unfortunately we didn’t discover this bug during our testing, only after it was released to production.
The text was updated successfully, but these errors were encountered: