Skip to content
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

[query] avoid hanging the JVM in Dataproc #13916

Merged
merged 5 commits into from
Oct 26, 2023
Merged

Conversation

danking
Copy link
Contributor

@danking danking commented Oct 26, 2023

Non-daemon threads keep a JVM alive:

When a Java Virtual Machine starts up, there is usually a single non-daemon thread (which typically calls the method named main of some designated class). The Java Virtual Machine continues to execute threads until either of the following occurs:

The exit method of class Runtime has been called and the security manager has permitted the exit operation to take place.

All threads that are not daemon threads have died, either by returning from the call to the run method or by throwing an exception that propagates beyond the run method.

Spark appears to wait for the JVM to terminate before it considers a job complete.

Non-daemon threads [keep a JVM
alive](https://docs.oracle.com/javase/8/docs/api/java/lang/Thread.html):

> When a Java Virtual Machine starts up, there is usually a single non-daemon thread (which
> typically calls the method named main of some designated class). The Java Virtual Machine
> continues to execute threads until either of the following occurs:
>
> The exit method of class Runtime has been called and the security manager has permitted the exit
> operation to take place.
>
> All threads that are not daemon threads have died, either by returning from the call to the run
> method or by throwing an exception that propagates beyond the run method.

Spark appears to wait for the JVM to terminate before it considers a job complete.
@danking danking added WIP and removed prio:high labels Oct 26, 2023
@danking
Copy link
Contributor Author

danking commented Oct 26, 2023

WIP until #13919 merges.

Dan King added 3 commits October 26, 2023 12:46
`aiohttp.ClientOSError` inherits from `OSError`, so we can just use `errno` or `strerror` directly.

We should not directly use the `args` because one of the subclasses of `ClientOSError` sets them
to *its* arguments after initializing its super classes with the expected arguments:

```python3
class ClientConnectorError(ClientOSError):
    """Client connector error.

    Raised in :class:`aiohttp.connector.TCPConnector` if
        a connection can not be established.
    """

    def __init__(self, connection_key: ConnectionKey, os_error: OSError) -> None:
        self._conn_key = connection_key
        self._os_error = os_error
        super().__init__(os_error.errno, os_error.strerror)
        self.args = (connection_key, os_error)
```

I also tried to remove `e.args` from the `ClientPayloadError` case (the one right above this, and
the only one still using `e.args`), but neither that class nor any super class sets a field with
the error message (in fact, no fields are ever set so we can only use `e.args`).
@danking danking dismissed daniel-goldstein’s stale review October 26, 2023 17:37

@daniel-goldstein, for expediency's sake, I merged #13921 into here; can you re-approve consider that new code?

@danking danking added prio:high and removed WIP labels Oct 26, 2023
@danking danking merged commit 87a6057 into hail-is:main Oct 26, 2023
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants