[
https://issues.apache.org/jira/browse/CASSANDRA-15214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17462918#comment-17462918
]
Paulo Motta commented on CASSANDRA-15214:
-----------------------------------------
I noticed that after this patch we produce the synthetic heap OOM even if the
crash/exit on oom flags are not set, which can happen if the user upgrades from
an older version without updating "cassandra-env.sh". This can potentially
leave the JVM in a worse state if we fill the heap and the JVM is not killed.
Do you think it makes sense to only generate the Heap OOM when the crash/exit
on OOM flags are set [~jolynch] [~yifanc] ?
> Internode messaging catches OOMs and does not rethrow
> -----------------------------------------------------
>
> Key: CASSANDRA-15214
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15214
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client, Messaging/Internode
> Reporter: Benedict Elliott Smith
> Assignee: Yifan Cai
> Priority: Normal
> Fix For: 4.0-beta4, 4.0
>
> Attachments: oom-experiments.zip
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> Netty (at least, and perhaps elsewhere in Executors) catches all exceptions,
> so presently there is no way to ensure that an OOM reaches the JVM handler to
> trigger a crash/heapdump.
> It may be that the simplest most consistent way to do this would be to have a
> single thread spawned at startup that waits for any exceptions we must
> propagate to the Runtime.
> We could probably submit a patch upstream to Netty, but for a guaranteed
> future proof approach, it may be worth paying the cost of a single thread.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
