Description
The REPL becomes unresponsive (indefinitely) when result of a computation is something whose "message" is a huge string.
May be simulated by reading lines of a large file in a manner similar to this:
java> java.util.List<String> listOfPrintables = java.nio.file.Files.lines(java.nio.file.Paths.get(NAME_OF_SOME_LARGE_FILE)).collect(java.util.stream.Collectors.toList())
The size (heap memory-footprint of result) itself is not the problem - large enough "-Xmx" was used.
Further confirmed that if, instead of gathering into a List reference, we simply determine the size of the list and save into an "int" variable, the equivalent command terminates within a few seconds and the result (length of List) is printed and control returns to console (remains responsive).
That is, the following works in contrast to above, even though the same amount of data is being read:
.....collect(java.util.stream.Collectors.toList()).size()
Finally, as an experiment and debugging client and server (jdb
),
I could work around the problem by making such a change in 'java-repl' source on the server (Repl
) side:
2017-06-13/java-repl-master/src/javarepl/console/ConsoleLog.java
public static ConsoleLog consoleLog(ConsoleLog.Type type, String message) {
final int MAX_LEN = 512; // let us trim long messages within the server
int len = message.length();
if (len > MAX_LEN) {
message = message.substring(0, MAX_LEN);
}
return new ConsoleLog(type, message);
}