obrienlabs
commented
7 years ago Anne's/J.F.'s workaround using 2 neo4j servers is good - I verified it on my setup - I get the same NPE as well.
Use the browser from a standalone to run queries against the embedded servers's bolt 7688 address without having to shutdown either graph.db
1) graph1.db managed by embedded neo4j (nsp live db) 2) graph2.db managed by standalone neo4j (app db - stub in the context of nsp) 3) launch embedded neo4j on bolt 7688 dbms.connector.bolt.address=127.0.0.1:7688 4) launch standalone neo4j on bolt 7687 (default) 5) in http://localhost:7474 point the bolt address to 7688 (didn't realize we could edit this greyed box) 6) now queries from 7474 will run against the embedded graph1.db instead of the standalone graph2.db Going forward: Currently a pure embedded server cannot instantiate an http port (the code in in NeoServer) - we would need to revert back to the Wrapping class removed in 3.x No effect
{noformat}
<entry key="dbms.connector.http.enabled" value="true" />
<entry key="dbms.connector.http.type" value="HTTP" />{noformat}
Ideally a procedure to wrap the embedded server' graphDatabaseFacade so that 7474 can be exposed via NeoServer code would be good in the future
The jmx exception does not block querying the db but should be looked at
{noformat}
match(n) return(n);
{noformat}
{noformat}
2016-12-19 16:46:27.595+0000 ERROR [o.n.b.v.r.ErrorReporter] Client triggered an unexpected error [UnknownError]: Exception invoking method writeBufSize. See debug.log for more details, reference dcc80076-665c-4cde-be3b-041c9253647c.
2016-12-19 16:46:27.596+0000 ERROR [o.n.b.v.r.ErrorReporter] Client triggered an unexpected error [UnknownError]: Exception invoking method writeBufSize, reference dcc80076-665c-4cde-be3b-041c9253647c. Exception invoking method writeBufSize
javax.management.RuntimeOperationsException: Exception invoking method writeBufSize
at org.apache.tomcat.util.modeler.BaseModelMBean.getAttribute(BaseModelMBean.java:196)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:647)
at com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:678)
at org.neo4j.kernel.builtinprocs.JmxQueryProcedure.toNeo4jValue(JmxQueryProcedure.java:131)
at org.neo4j.kernel.builtinprocs.JmxQueryProcedure.toNeo4jValue(JmxQueryProcedure.java:119)
{noformat}
obriensystems
oskarhane
archenroot
jiaenqiu
Having issues bridging bolt and http to enable the browser to come up under 7474 like it did for 2.3
See other tracking issue
https://github.com/neo4j/neo4j/issues/7608 2.14 of http://neo4j.com/docs/java-reference/current/#tutorials-java-embedded https://neo4j.com/developer/kb/how-do-i-enable-remote-https-access-with-neo4j-30x/
We are running Neo4j 3.1.0 as an embedded graph.db and also would like to enable the 7474 neo4j HTTP browser as we did in 2.3.7. Conf parameters are setting 7474 to HTTP from BOLT in 3.1.0, in 3.0.7 the port behaves like a bolt websocket port
Bottom line is:
3.0.7 brings up 7474 as a bolt port 3.1.0 does not bring up 7474 at all
In 3.1 the gui is different for the 3.0 procedure where a standalone browser is used to adjust the embedded graph.db - the bolt-http connector is still not up though.
Can you advise if the bolt+routing protocol workaround for 3.1 is valid - when it was put in to 3.1 the issue states "when in a causal cluster"
cl: Add support for the bolt+routing protocol when in a Causal Cluster https://github.com/neo4j/neo4j-browser/pull/322
To check - I switched back to 3.0.7 (deleted graph.db) - get different behaviour I get the same malformed websocket message I see in 7474 that I get if I access bolt 7687 directly in 3.1.0
likely because 7474 ends up configured with BOLT instead of HTTP
This is with or without the bolt settings applied on the factory and running only with
running
"not a WebSocket handshake request: missing upgrade"
A 400 this time Request URL:http://localhost:7474/ Request Method:GET Status Code:400 Bad Request Remote Address:127.0.0.1:7474
//I'll try 3.2.0-alpha02 when it comes up on maven central as well.
The KernelExtensionFactory impls contain only one Bolt subclass that could setup the 7687 and 7474 connectors. If I force the http connector as type BOLT - I register both of them (7474 is then a websocket port) - but this is not a solution.
It looks like we need to be running the connector setup that occurs in NeoServer and its subclasses down to EnterpriseNeoServer where we setup the following - however this code only runs for non-embedded servers
I did run into an issue with SSL creation during OPTIONAL (the default) only when a certain logging parameter was set to DEBUG - I'll raise a separate issue on this. The fix was to set tls_level on the indexed 0 bolt property not directly on bolt.tls_level
Just to verify our custom 4 level constructor override of GraphDatabaseService to load our custom HA listener is causing us connector deviation I ran a very basic embedded setup - same issue
graphDb GraphDatabaseFacade (id=198)
community single [/ec2-user/graph2.db]
TODO: I still have a couple experiments and debugging I can do to try to force 7474 port creation on the embedded instance. Sad because 7474 works so well on a standalone server via the sh command
Attaching small maven war eclipse project used to test biometric.nbi.web-0.0.11-SNAPSHOT_eclipse_maven_src.zip