Bug Type (问题类型)
logic (逻辑设计问题): missing configuration validation
Before submit
Environment (环境信息)
master 83ef9f3f, PD + 3 Stores + Server; also reproduced on a single-node PD + Store + Server deployment. Graph config file with backend=hstore, store, pd.peers and no serializer line.
Expected & Actual behavior (期望与实际表现)
Expected: a graph on HStore either refuses to open with a serializer it cannot read, or picks the only one it supports.
Actual: CoreOptions.SERIALIZER defaults to text. The shipped hugegraph.properties sets serializer=binary explicitly; a hand-written graph file usually does not. With text the write path serialises rows through TextSerializer and HStore stores them, but HstoreTable.newEntryIterator always parses returned keys as binary (new BinaryBackendEntry(type, col.name)): a text key such as marko starts with 0x6d, so readId() takes the number branch and readNumber() runs off the end of the buffer.
POST /graph/vertices {"label":"person","id":"marko",...} -> 201, the vertex is echoed back
GET /graph/vertices/"marko" -> 404 Vertex 'marko' does not exist
GET /graph/vertices?limit=10 -> 500 java.nio.BufferUnderflowException
g.V().count() -> 3 (rows are counted, not parsed)
g.V().limit(3).valueMap(true) -> BufferUnderflowException
server log: Failed to parse entry: 0x533e6578706972: [S>expired_time=0]
Stack (identical on both deployments): BytesBuffer.readShort:327 ← readUInt16:457 ← readNumber:983 ← readId:761 ← parseId:855 ← BinaryBackendEntry.<init>:44 ← HstoreTable.lambda$newEntryIterator$1:121 ← BinaryEntryIterator.fetch:86 ← … ← VertexAPI.list.
Why it costs people time
The failure is far from the cause: writes succeed, the schema API works, the error is a low-level buffer exception in the read path, and nothing in the log mentions the serializer. On the second deployment this was chased through jar checksums, Java versions and data wipes for an hour before the config line was found. The HStore backend has exactly one serializer it can read, so the option is not a choice there.
Proposal (small, I can send the PR)
HstoreProvider (or the store open path) checks the graph's serializer and fails fast with a clear message when it is not binary: HStore backend requires serializer=binary, but got 'text' (graph 'smoketext'). The same guard makes sense for any backend whose tables are binary-only.
- Alternatively, default the option per backend:
hstore and rocksdb imply binary when the line is absent, with an INFO line saying so.
- A note in the graph-config documentation:
serializer is not optional for hstore.
Related: #3090 (property codec between server and store) is a different topic; this one is purely a missing configuration guard.
Bug Type (问题类型)
logic (逻辑设计问题): missing configuration validation
Before submit
Environment (环境信息)
master
83ef9f3f, PD + 3 Stores + Server; also reproduced on a single-node PD + Store + Server deployment. Graph config file withbackend=hstore,store,pd.peersand noserializerline.Expected & Actual behavior (期望与实际表现)
Expected: a graph on HStore either refuses to open with a serializer it cannot read, or picks the only one it supports.
Actual:
CoreOptions.SERIALIZERdefaults totext. The shippedhugegraph.propertiessetsserializer=binaryexplicitly; a hand-written graph file usually does not. Withtextthe write path serialises rows throughTextSerializerand HStore stores them, butHstoreTable.newEntryIteratoralways parses returned keys as binary (new BinaryBackendEntry(type, col.name)): a text key such asmarkostarts with0x6d, soreadId()takes the number branch andreadNumber()runs off the end of the buffer.Stack (identical on both deployments):
BytesBuffer.readShort:327 ← readUInt16:457 ← readNumber:983 ← readId:761 ← parseId:855 ← BinaryBackendEntry.<init>:44 ← HstoreTable.lambda$newEntryIterator$1:121 ← BinaryEntryIterator.fetch:86 ← … ← VertexAPI.list.Why it costs people time
The failure is far from the cause: writes succeed, the schema API works, the error is a low-level buffer exception in the read path, and nothing in the log mentions the serializer. On the second deployment this was chased through jar checksums, Java versions and data wipes for an hour before the config line was found. The HStore backend has exactly one serializer it can read, so the option is not a choice there.
Proposal (small, I can send the PR)
HstoreProvider(or the store open path) checks the graph'sserializerand fails fast with a clear message when it is notbinary:HStore backend requires serializer=binary, but got 'text' (graph 'smoketext'). The same guard makes sense for any backend whose tables are binary-only.hstoreandrocksdbimplybinarywhen the line is absent, with an INFO line saying so.serializeris not optional for hstore.Related: #3090 (property codec between server and store) is a different topic; this one is purely a missing configuration guard.