Cole-Greer commented on code in PR #3703:
URL: https://github.com/apache/tinkerpop/pull/3703#discussion_r4275910095
##########
gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/io/binary/types/SimpleTypeSerializer.java:
##########
@@ -35,6 +35,23 @@
public abstract class SimpleTypeSerializer<T> implements TypeSerializer<T> {
private final DataType dataType;
+ /**
+ * Upper bound, in bytes, on a length prefix sizing a fixed byte
allocation ({@code byte[]}, {@code ByteBuffer}),
+ * enforced even when {@link Buffer#hasKnownRemainingLength()} is {@code
false}.
+ */
+ private static final int MAX_BYTE_LENGTH = 64 * 1024 * 1024;
Review Comment:
If I understand this correctly, this imposes a hard cap of the size of
single object being deserialized. Attempts to deserialize a single String in
excess of 64MB would result in a SerializationException. Is this correct?
If so, I think we need to make these limits configurable in both the server
and the driver. 64MB seems like a completely reasonable limit, and I would
argue it's bad practice to store something that large as a property of
something, but I'm sure there's someone storing a novel as a vertex property
who will need a workaround for this.
The same applies for the following caps as well. We need to ensure a viable
success path for users with excessively large data.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
