Neo4j 和 Gephi Graph Streaming 插件:连接被拒绝
Neo4j and Gephi Graph Streaming plugin: Connection refused
我正在尝试连接Gephi(https://gephi.org/) and Neo4j (via docker) using Gephi's graph Streaming plugin and Neo4j's apoc procedures, as explained here: https://tbgraph.wordpress.com/2017/04/01/neo4j-to-gephi/。我已经在Gephi中安装了所需的插件,并在neo4j中安装了apoc程序,并添加了所需的安全配置以使apoc程序能够工作。因此, neo4j.conf
包括这一行 dbms.security.procedures.unrestricted=apoc.\*
.
但是,当我在控制台中输入以下查询时:
MATCH path = (:Person)-[:KNOWS]->(:Person)
CALL apoc.gephi.add(null,'workspace1',path,'weight') yield nodes
return *
我明白了
Neo.ClientError.Procedure.ProcedureCallFailed: Failed to invoke procedure `apoc.gephi.add`: Caused by: java.net.ConnectException: Connection refused (Connection refused)
我也尝试用 https://localhost:8443
和 http://localhost:8080
替换第一个空值(即服务器 url),但我得到了同样的异常。 Gephi Graph Streaming 插件服务器正在监听 8080 和 8443。
不知道如何进一步排查问题。
编辑:
关于 docker,我正在使用自定义图像并将 apoc 添加到基础 neo4j 图像:
# Adding APOC
FROM neo4j:3.3
ENV APOC_URI https://github.com/neo4j-contrib/neo4j-apoc-procedures/releases/download/3.3.0.1/apoc-3.3.0.1-all.jar
RUN apk add --no-cache --quiet curl
RUN mv plugins /plugins \
&& ln -s plugins /plugins
RUN curl --fail --silent --show-error --location --output apoc-3.3.0.1-all.jar $APOC_URI \
&& mv apoc-3.3.0.1-all.jar /plugins
RUN apk del curl
EXPOSE 7474 7473 7687
CMD ["neo4j"]
我运行容器为:
docker run \
--publish=7474:7474 --publish=7687:7687 \
--volume=$HOME/neo4j/data:/data \
-e NEO4J_dbms_security_procedures_unrestricted=apoc.\\* \
neo4j_apoc:3.3
将--net="host"添加到Docker命令;在默认配置中,容器的 "localhost" 不指向实际的 docker 主机。
您正在尝试连接到本地主机,但是由于默认 Docker 网络(bridge
网络)的工作方式,127.0.0.1 和本地主机实际上都没有指向 Docker 主机,而是指向容器本身。
仍然可以访问 Docker 主机,但是由于 Docker 网络是动态的(不能保证容器启动之间的 IP 相同),因此需要检查默认网关在哪里,这将是主机的地址。
一个更简单的解决方法是通过将 --net="host"
传递给 Docker 的调用来切换网络模式:
docker run \
--publish=7474:7474 --publish=7687:7687 \
--net="host" \
--volume=$HOME/neo4j/data:/data \
-e NEO4J_dbms_security_procedures_unrestricted=apoc.\\* \
neo4j_apoc:3.3
这将从bridge
模式切换到host
模式,其中容器直接使用主机的网络堆栈。那时,localhost 和 127.0.0.1 都将指向 Docker 主机(以及容器本身)。
注意这个模式有破坏网络'containerization'的效果;在容器中打开的任何端口也将在 Docker 主机上打开 。
我正在尝试连接Gephi(https://gephi.org/) and Neo4j (via docker) using Gephi's graph Streaming plugin and Neo4j's apoc procedures, as explained here: https://tbgraph.wordpress.com/2017/04/01/neo4j-to-gephi/。我已经在Gephi中安装了所需的插件,并在neo4j中安装了apoc程序,并添加了所需的安全配置以使apoc程序能够工作。因此, neo4j.conf
包括这一行 dbms.security.procedures.unrestricted=apoc.\*
.
但是,当我在控制台中输入以下查询时:
MATCH path = (:Person)-[:KNOWS]->(:Person)
CALL apoc.gephi.add(null,'workspace1',path,'weight') yield nodes
return *
我明白了
Neo.ClientError.Procedure.ProcedureCallFailed: Failed to invoke procedure `apoc.gephi.add`: Caused by: java.net.ConnectException: Connection refused (Connection refused)
我也尝试用 https://localhost:8443
和 http://localhost:8080
替换第一个空值(即服务器 url),但我得到了同样的异常。 Gephi Graph Streaming 插件服务器正在监听 8080 和 8443。
不知道如何进一步排查问题。
编辑:
关于 docker,我正在使用自定义图像并将 apoc 添加到基础 neo4j 图像:
# Adding APOC
FROM neo4j:3.3
ENV APOC_URI https://github.com/neo4j-contrib/neo4j-apoc-procedures/releases/download/3.3.0.1/apoc-3.3.0.1-all.jar
RUN apk add --no-cache --quiet curl
RUN mv plugins /plugins \
&& ln -s plugins /plugins
RUN curl --fail --silent --show-error --location --output apoc-3.3.0.1-all.jar $APOC_URI \
&& mv apoc-3.3.0.1-all.jar /plugins
RUN apk del curl
EXPOSE 7474 7473 7687
CMD ["neo4j"]
我运行容器为:
docker run \
--publish=7474:7474 --publish=7687:7687 \
--volume=$HOME/neo4j/data:/data \
-e NEO4J_dbms_security_procedures_unrestricted=apoc.\\* \
neo4j_apoc:3.3
将--net="host"添加到Docker命令;在默认配置中,容器的 "localhost" 不指向实际的 docker 主机。
您正在尝试连接到本地主机,但是由于默认 Docker 网络(bridge
网络)的工作方式,127.0.0.1 和本地主机实际上都没有指向 Docker 主机,而是指向容器本身。
仍然可以访问 Docker 主机,但是由于 Docker 网络是动态的(不能保证容器启动之间的 IP 相同),因此需要检查默认网关在哪里,这将是主机的地址。
一个更简单的解决方法是通过将 --net="host"
传递给 Docker 的调用来切换网络模式:
docker run \
--publish=7474:7474 --publish=7687:7687 \
--net="host" \
--volume=$HOME/neo4j/data:/data \
-e NEO4J_dbms_security_procedures_unrestricted=apoc.\\* \
neo4j_apoc:3.3
这将从bridge
模式切换到host
模式,其中容器直接使用主机的网络堆栈。那时,localhost 和 127.0.0.1 都将指向 Docker 主机(以及容器本身)。
注意这个模式有破坏网络'containerization'的效果;在容器中打开的任何端口也将在 Docker 主机上打开 。