Force immediate shutdown

[mlnrDev]

General Troubleshooting

• I have checked for similar issues.
• I have updated to the latest JDA version.
• I have checked the branches or the maintainers' PRs for upcoming features.

Feature Request

So, i asked about this "feature" (more like an addition or fix if you wish) in the JDA guild already and i was advised to rather create an issue instead of creating a PR, so here it is. I saw many people having "issue" with JDA not shutting down immediately even when using shutdownNow() method. This could be fixed by using two methods provided in the http client.

Example Use-Case

These are the methods that could result in an immediate shutdown.

httpClient.connectionPool().evictAll();
httpClient.dispatcher().executorService().shutdown(); //assuming httpClient is really an http client variable, of course

Those methods could be implemented in 2 ways.

1. Implement them into the shutdownNow() method
2. Create a separate method for it, for example shutdownForcely(), which would call shutdownNow() and those 2 methods

Example

1. shutdownNow()

    @Override
    public synchronized void shutdownNow()
    {
        shutdown();
        threadConfig.shutdownNow();
        this.getHttpClient().connectionPool().evictAll();
        this.getHttpClient().dispatcher().executorService().shutdown();
    }

2. shutdownForcely() (?)

    @Override
    public synchronized void shutdownForcely()
    {
        shutdownNow();
        this.getHttpClient().connectionPool().evictAll();
        this.getHttpClient().dispatcher().executorService().shutdown();
    }

Calling such methods would make JDA completely unusable for further use, obviously.

[kantenkugel]

A few things to consider here:

• We have to be careful to not close clients that JDA didn't create, but were passed into the JDABuilder
• Being double-careful that those connection pools are per-client and not global OkHttp pools, in which case they would also violate first point
• can really only be applied to the shutdownNow or a new one like suggested above, since this will abort any ongoing or queued RestActions
• IMO this is a bug of OkHttp and not sure if adding (possibly temporary) workarounds into JDA is the right call
• disabling HTTP2 in Okhttp might be the better option, if possible

[mlnrDev]

* can really only be applied to the shutdown**Now** or a new one like suggested above, since this will abort any ongoing or queued RestActions

Well, it's obvious that an immediate shutdown is really immediate, so queued RestActions won't get executed and people have to count on it.

* IMO this is a bug of OkHttp and not sure if adding (possibly temporary) workarounds into JDA is the right call

If this is a bug, then it's a really old one, as there were few releases which didn't fix it (yet?). But i agree with other points.

[MinnDevelopment]

as there were few releases which didn't fix it (yet?).

The same applies to JDA. I have known about this behavior for months if not years and decided not to change our handling. I intentionally did not add any special shutdown behavior for this and I don't intend to do.

[mlnrDev]

 * and decided not to change our handling. I intentionally did not add any special shutdown behavior for this and I don't intend to do.

May i please know why?

[MinnDevelopment]

I consider this bad behavior and a bug in okhttp that we should not need to workaround. I try not to implement workarounds if possible. And in this case its definitely not needed as the thread times out either way.

[robinfriedli]

Just throwing in my two cents but I would like a blocking shutdown method that only returns once pending RestActions have completed, after that I don't really care about the okhtttp connection pool and could just exit manually. Even with http 1.1 the okhttp still seems to take 1 minute to shut down (considerably better than 5 minutes with http 2 but still).

[mlnrDev]

I consider this bad behavior and a bug in okhttp that we should not need to workaround. I try not to implement workarounds if possible.

I mean, the method as shutdownForcely() for example could be useful for people that really want to shut JDA down immediately after calling the method. They might/might not have enough experience to find the solution out by themself.

[gpluscb]

I think adding a section in the troubleshooting page of the wiki where the issue and workarounds are explained and a corresponding tag for the Discord servers Spectra bot would be a good option to consider in the case that no changes to JDAs code are made.

[MinnDevelopment]

I mean, the method as shutdownForcely() for example could be useful for people that really want to shut JDA down immediately after calling the method. They might/might not have enough experience to find the solution out by themself.

From my experience, most people figure out how to use System.exit(0); on their own. I don't really see this as a good argument and adding a bunch of shutdown methods is not useful. Again this would be trying to work around an issue with okhttp which I don't want to do.

adding a section in the troubleshooting page of the wiki where the issue and workarounds are explained

I think that is reasonable.

[MinnDevelopment]

I have added an entry for this in the troubleshooting guide: Shutdown but the process doesn't exit

[mlnrDev]

I have added an entry for this in the troubleshooting guide: Shutdown but the process doesn't exit-Troubleshooting#shutdown-but-the-process-doesnt-exit)

I consider this as a reason to close this issue. Thanks for your time.