You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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);
}
The text was updated successfully, but these errors were encountered:
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:The text was updated successfully, but these errors were encountered: