Browser tab times out for simple, limited query that works fine in cypher-shell


(Tony Panza) #1

I am having a weird and frustrating problem. Fairly simple queries that (should) return subsets of my most numerous node label cause the browser to "timeout" and just show a completely blank white page.

Configuration:

  • Neo4j Server version: 3.4.5 (community), on RHEL 7.3 remote machine
  • Neo4j Browser version: 3.2.5
  • Web browser Firefox 60.1.0esr (32-bit), on Windows 10 local machine

The Firefox browser is running on my local machine running Windows 10. The Neo4j server is running on a remote server elsewhere on LAN. From my local machine, I am using Firefox to connect to the remote server via http. (http://remote-machine:7474)

I have three node labels in my graph and a total of 2411039 nodes. All the labels are mutually exclusive. I'll call them Label1, Label2, and Label3. Label1 contains 2366 nodes. Label2 contains 364235 nodes. Label3, the apparent problem child, contains 2044438 nodes (by far the most numerous). There is a relationship type between Label3 nodes and other Label3 nodes. There is another relationship type between Label3 nodes and Label2 nodes. The third and final relationship is between Label2 nodes and Label1 nodes.

If I run the sample queries in the "Database Information" section to just return 25 example nodes for each label, Label3 has problems. MATCH (n:Label3) RETURN n LIMIT 25 this causes the browser to hang for a few seconds, then eventually the entire tab just becomes a blank white page.

If I refresh the browser tab, I get back to what looks like a "fresh" new session with just the :play start content showing. The browser is now working again (for queries not involving Label3). If I hit the up arrow key in the query bar, my last query that caused the browser to seemingly time out shows back up.

If if try PROFILE MATCH (n:Label3) RETURN n LIMIT 25 from the browser, this also fails but with slightly different symptoms. It causes all of the "result boxes" from previous queries to go away. The content in the left frame is still visible but unresponsive if I click the icons. The query bar is still visible with a flashing cursor, but also unresponsive if I try typing in it. The tab has to be refreshed to get back to a working session.

If I run the same exact query but from the cypher-shell on my remote server's command line, instead of within browser on my local machine, the query runs fine and very fast.

So it doesn't look like the query itself is the problem, but rather something about the browser environment.

Slightly more complex queries involving Label3 also fail/timeout in the browser but run fine from the cypher-shell. Example: MATCH (n:Label3)-[r]->(m:Label2) RETURN n, r, m LIMIT 60

There is no problem if I run, from the browser, the "sample 25" queries for the other nodes. Label2 and Label1 work fine when running the MATCH (n:Labelx) RETURN n LIMIT 25 queries from the browser.

I'm not sure if Label3 being the most numerous node is part of what is causing this problem or just a coincidence, but that is my only working hypothesis.

I realize that neither my neo4j server nor the neo4j browser are the latest, greatest versions. I looked through the changelog for both neo4j and neo4j-browser to see if there is anything in the newer versions that might address this, but didn't see anything obvious.

Any ideas as to what is going on? What else can I try or check to help characterize this problem?


(Benoit Simard) #2

Can you try to use an other browser (for example chromium) ?
Do you have the same behaviour ?

Does your :Label3 nodes are really heavy (ie. have a lot of properties, or one big property) ?
Can you try to not return the entire node but just its id, to see if it works : MATCH (n:Label3) RETURN id(n) LIMIT 25


(Tony Panza) #3

Returning the id worked fine from the browser. MATCH (n:Label3) RETURN id(n) LIMIT 25 completed in 1 ms.

I don't think the :Label3 nodes are all that "heavy". They have 6 float properties and 3 string properties. The first string property has an average length of about 4.03 chars. The second string property has an average length of about 1.72 characters. The third string property, which is a uniqueness constraint, has an average length of 15 characters.

Unfortunately I don't really have another option for browser to try. The only possibility for an alternate is IE 11, but I still can't resolve the "security error 18" issue.


(Tony Panza) #4

This simple query also causes the browser tab to timeout and become completely blank: MATCH (n) RETURN n LIMIT 25


(Benoit Simard) #5

Can you run this query and give me the result : MATCH (n) RETURN id(n), size((n)--()) LIMIT 25

I think that you have an hypernode somewhere, and it freezes during its renderer.


(Tony Panza) #6
╒═══════╤═══════════════╕
│"id(n)"│"size((n)--())"│
╞═══════╪═══════════════╡
│0      │2              │
├───────┼───────────────┤
│1      │2              │
├───────┼───────────────┤
│2      │2              │
├───────┼───────────────┤
│3      │2              │
├───────┼───────────────┤
│4      │7              │
├───────┼───────────────┤
│5      │2              │
├───────┼───────────────┤
│6      │2              │
├───────┼───────────────┤
│7      │2              │
├───────┼───────────────┤
│8      │2              │
├───────┼───────────────┤
│9      │2              │
├───────┼───────────────┤
│10     │22             │
├───────┼───────────────┤
│11     │2              │
├───────┼───────────────┤
│12     │2              │
├───────┼───────────────┤
│13     │2              │
├───────┼───────────────┤
│14     │2              │
├───────┼───────────────┤
│15     │2              │
├───────┼───────────────┤
│16     │2              │
├───────┼───────────────┤
│17     │2              │
├───────┼───────────────┤
│18     │2              │
├───────┼───────────────┤
│19     │2              │
├───────┼───────────────┤
│20     │2              │
├───────┼───────────────┤
│21     │2              │
├───────┼───────────────┤
│22     │2              │
├───────┼───────────────┤
│23     │2              │
├───────┼───────────────┤
│24     │3              │
└───────┴───────────────┘

(Tony Panza) #7

The node with ID of 10, whose size((n)--()) is 22, is causing problems:

This also causes a browser timeout: MATCH (n) WHERE id(n)=10 RETURN n

This query works fine from the browser: MATCH (n) WHERE id(n)=9 RETURN n


(Benoit Simard) #8

There is nothing wrong and the browser can normally handle that for the graph renderer ...

Last chance do you have some errors in the console ? Can you display SVG files in your browser ?


(Tony Panza) #9

Yes, my browser can display SVG files. If I run a cypher query that does not crash the browser, I can save the graph results as graph.svg and download it. Then I can open that downloaded graph.svg in Firefox.

Yes, I am seeing some errors in the Firefox console when I run MATCH (n) WHERE id(n)=10 RETURN n:

Invariant Violation: Minified React error #185; visit https://reactjs.org/docs/error-decoder.html?invariant=185 for the full message or use the non-minified dev environment for full errors and additional helpful warnings. 
Stack trace:
r@http://remote-machine.mycompany.com:7474/browser/vendor-8e76f7dbd0cd6ce654d5.js:1:1420121
l@http://remote-machine.mycompany.com:7474/browser/app-8e76f7dbd0cd6ce654d5.js:1:249494
$n@http://remote-machine.mycompany.com:7474/browser/app-8e76f7dbd0cd6ce654d5.js:1:305665
enqueueSetState@http://remote-machine.mycompany.com:7474/browser/app-8e76f7dbd0cd6ce654d5.js:1:338164
../../node_modules/react/cjs/react.production.min.js/o.prototype.setState@http://remote-machine.mycompany.com:7474/browser/vendor-8e76f7dbd0cd6ce654d5.js:1:2754697
../../node_modules/styled-components/dist/styled-components.browser.es.js/</ne</o</e.prototype.componentWillReceiveProps@http://remote-machine.mycompany.com:7474/browser/vendor-8e76f7dbd0cd6ce654d5.js:1:3118310
pn@http://remote-machine.mycompany.com:7474/browser/app-8e76f7dbd0cd6ce654d5.js:1:282027
In@http://remote-machine.mycompany.com:7474/browser/app-8e76f7dbd0cd6ce654d5.js:1:294061
Kn@http://remote-machine.mycompany.com:7474/browser/app-8e76f7dbd0cd6ce654d5.js:1:303894
Yn@http://remote-machine.mycompany.com:7474/browser/app-8e76f7dbd0cd6ce654d5.js:1:304202
dl@http://remote-machine.mycompany.com:7474/browser/app-8e76f7dbd0cd6ce654d5.js:1:307584
il@http://remote-machine.mycompany.com:7474/browser/app-8e76f7dbd0cd6ce654d5.js:1:307093
ul@http://remote-machine.mycompany.com:7474/browser/app-8e76f7dbd0cd6ce654d5.js:1:306919
rl@http://remote-machine.mycompany.com:7474/browser/app-8e76f7dbd0cd6ce654d5.js:1:306291
$n@http://remote-machine.mycompany.com:7474/browser/app-8e76f7dbd0cd6ce654d5.js:1:305650
enqueueSetState@http://remote-machine.mycompany.com:7474/browser/app-8e76f7dbd0cd6ce654d5.js:1:338164
../../node_modules/react/cjs/react.production.min.js/o.prototype.setState@http://remote-machine.mycompany.com:7474/browser/vendor-8e76f7dbd0cd6ce654d5.js:1:2754697
a/</c</c.prototype.onStateChange@http://remote-machine.mycompany.com:7474/browser/vendor-8e76f7dbd0cd6ce654d5.js:1:2739009
c@http://remote-machine.mycompany.com:7474/browser/vendor-8e76f7dbd0cd6ce654d5.js:1:2792448
s/</</<@http://remote-machine.mycompany.com:7474/browser/app-8e76f7dbd0cd6ce654d5.js:1:1827194
f/</<@http://remote-machine.mycompany.com:7474/browser/vendor-8e76f7dbd0cd6ce654d5.js:1:2787116
../../node_modules/suber/lib/bus.js/e.createReduxMiddleware/</</<@http://remote-machine.mycompany.com:7474/browser/vendor-8e76f7dbd0cd6ce654d5.js:1:3134418
dispatch@http://remote-machine.mycompany.com:7474/browser/vendor-8e76f7dbd0cd6ce654d5.js:1:2788660
exec/<@http://remote-machine.mycompany.com:7474/browser/app-8e76f7dbd0cd6ce654d5.js:1:1813951
N/</<@http://remote-machine.mycompany.com:7474/browser/vendor-8e76f7dbd0cd6ce654d5.js:1:679180
N/<@http://remote-machine.mycompany.com:7474/browser/vendor-8e76f7dbd0cd6ce654d5.js:1:679048
a@http://remote-machine.mycompany.com:7474/browser/vendor-8e76f7dbd0cd6ce654d5.js:1:614643

(Tony Panza) #10

New theory on what might be causing this React error and failure to render in the browser. It is not the number of connections to a particular node (as mentioned above, 22 relationships is normally handled quite easily by the renderer), nor does it have anything to do with how numerous a particular node label is.

But rather it is due to NaN being in some of the property values. How did NaNs get in there? They got there via the BOLT protocol when I created the graph via Python from a large Pandas dataframe. In that dataframe, the 6 columns containing float datatypes have missing values, which are encoded as NaN by Pandas. So those NaN values are getting passed into the graph as is, since this is using BOLT. If using JavaScript or browser interface, these NaNs would have been converted to null as part of JSON-ifying the data. But I populated my graph's data using py2neo and BOLT connector.

Here is output from the cypher-shell for the problematic node ID of 10 that causing the React error:

neo4j> MATCH (n) WHERE id(n)=10 RETURN n;
+----------------------------------------------------------------------------------------------------------------------------+
| n                                                                                                                          |
+----------------------------------------------------------------------------------------------------------------------------+
| (:Label3 {item_id: "000000012345678", usage_type: "thing", z1: NaN, z2: NaN, y1: NaN, y2: NaN, x1: NaN, x2: NaN})          |
+----------------------------------------------------------------------------------------------------------------------------+

1 row available after 7 ms, consumed after another 0 ms

Thoughts? I'll see if I can use algo.isInfinite() from the graph algorithms plugin to clean the NaNs out of the graph.

What's odd is that, according to the screenshot posted here, at least at one point, the Neo4J browser was able to render nodes with NaN property values. Perhaps something changed with either the React library or the neo4j browser code..??


(Tony Panza) #11

Confirmed that after running this query to remove NaNs:

MATCH (n:Label3)
WHERE algo.isInfinite(n.x1)
REMOVE n.x1, n.x2, n.y1, n.y2, n.z1, n.z2

Now queries such as MATCH (n:Label3) RETURN n LIMIT 25 and MATCH (n) WHERE id(n)=10 RETURN n do work in the browser!

Is this worthy of a bug report against neo4j-browser???


(Tony Panza) #12

Filed issue against neo4j-browser: https://github.com/neo4j/neo4j-browser/issues/826