test 10

[bitflicker64]

Bug Type (问题类型)

None

Before submit

• 我已经确认现有的 Issues 与 FAQ 中没有相同 / 重复问题 (I have confirmed and searched that there are no similar problems in the historical issue and documents)

Environment (环境信息)

• Server Version: 1.0.0 (Apache Release Version)
• Backend: RocksDB x nodes, HDD or SSD
• OS: xx CPUs, xx G RAM, Ubuntu 2x.x / CentOS 7.x
• Data Size: xx vertices, xx edges

Expected & Actual behavior (期望与实际表现)

Bug Type
server status (startup / runtime exception)

Before submit

I have confirmed and searched that there are no similar problems in the historical issues and documents
Environment
Server Version: 1.7.0 (latest master)
Backend: RocksDB (standalone, default)
OS: macOS / Linux (Docker)
Image: hugegraph/hugegraph:latest built from hugegraph-server/Dockerfile
Expected & Actual behavior
Expected: The standalone image built from hugegraph-server/Dockerfile should start successfully and be ready to use immediately after docker run.

Actual: The server starts up (HTTP listener bound to 8080), but then keeps printing Waiting for partition assignment... for ~120 seconds before timing out:

INFO: Started listener bound to [0.0.0.0:8080]
INFO: [HttpServer] Started.
Started [pid 1017]
Waiting for partition assignment...
Waiting for partition assignment...
Waiting for partition assignment...
Waiting for partition assignment...
Waiting for partition assignment...
Root Cause:

PR apache#2952 (0154c06) refactored docker-compose and added an unconditional call to wait-partition.sh in docker-entrypoint.sh:

Line 84-90 in docker-entrypoint.sh

STORE_REST="${STORE_REST:-store:8520}"
export STORE_REST
./bin/start-hugegraph.sh -j "${JAVA_OPTS:-}" -t 120
./bin/wait-partition.sh || log "WARN: partitions not assigned yet"
wait-partition.sh polls http://store:8520 looking for "partitionCount":[1-9] — this is only meaningful in distributed hstore mode. In standalone rocksdb mode, there is no Store service, so it loops for 120 seconds before timing out.

In contrast, wait-storage.sh correctly guards against this: it skips the PD wait entirely when no hstore-related environment variables are set.

Vertex/Edge example
N/A — this is a Docker startup issue, not a data issue.

Schema [VertexLabel, EdgeLabel, IndexLabel]
N/A

Vertex/Edge example (问题点 / 边数据举例)

Schema [VertexLabel, EdgeLabel, IndexLabel] (元数据结构)

[github-actions]

问题分析与解决方案

你报告的问题是关于 Docker 启动时由于无条件调用 wait-partition.sh 脚本导致的超时问题。这个脚本在独立 RocksDB 模式下会尝试轮询 http://store:8520 以寻找分区信息，但是由于独立模式下没有 Store 服务，这导致脚本循环 120 秒后超时。

根本原因

问题的根源在于 docker-entrypoint.sh 中无条件地调用 wait-partition.sh。与 wait-storage.sh 的正确做法相比，后者会检查环境变量以确定是否需要执行 PD 等待逻辑。

解决建议

为了解决这个问题，建议修改 docker-entrypoint.sh 以仅在分布式 hstore 模式下调用 wait-partition.sh。这可以通过检查与 hstore 相关的环境变量（如 HG_SERVER_BACKEND 或 HG_SERVER_PD_PEERS）是否设置来实现。只有当这些变量设置时，才应该执行分区等待的逻辑。

附加信息

• 问题发生在版本 1.7.0（latest master）中。
• 问题仅影响使用 hugegraph-server/Dockerfile 构建的独立镜像。
• 分布式部署不受影响，因为它们设置了必要的环境变量。
• wait-partition.sh 脚本本身没有问题，问题出在其被无条件调用的方式上。

我希望这能够帮助你解决问题。如果需要进一步的帮助或有任何其他问题，请不要犹豫ingly提出。

我是 AI bot，powered by DeepWiki + Groq。如果您需要进一步的帮助或有任何其他问题，请随时提出。您可以查看相关的 Wiki 页面，如 Glossary (apache/incubator-hugegraph) 或 Example Programs (apache/incubator-hugegraph)，以获取更多信息。同时，也可以在 DeepWiki 中进行搜索以找到更多相关内容。