Hi Group,
glad to announce a new SNAPSHOT version of Structr, and it comes with
the long-awaited integrated Neo4j server!
You just have to add 'Neo4jService' to the list of configured services,
set host and port in the structr.conf and start as usual. Then you can
access the Neo4j browser
Hi Axel,
This sounds like fun. Surely will try to run our Prologram viz thingy
against this server!
You state that it bypasses security. Does it also bypass any data-integrity
rules like cardinality and other stuff we created through the Structr
schema?
Best,
Tom
On Monday, 10 November
This sounds like fun. Surely will try to run our Prologram viz thingy
against this server!
Great! Any feedback welcome!
You state that it bypasses security. Does it also bypass any
data-integrity rules like cardinality and other stuff we created
through the Structr schema?
Yes, it does.
(I'm posting this question here since it seems a bit too non-specific for
Stack Overflow).
I've been working on a Neo4j system that needs to ingest a lot of data.
We've been testing the data-load with many writing threads. Generally this
works fine. For example, writing with 5 threads
batch insertion is a very special and specific case which generally is done
once when you initially populate your graph with data taken elsewhere
whether Neo4j on *your* particular hardware with *your* particular JVM
settings in *your* particular cluster configuration with *your* particular
What's the state of the system if you take a thread dump when it's in
unresponsive mood?
On 10 November 2014 05:13, Ryan Sattler xgravi...@gmail.com wrote:
(I'm posting this question here since it seems a bit too non-specific for
Stack Overflow).
I've been working on a Neo4j system that
Thanks. I had already create indexes on Pool. I have resolved the
specific performance issue by doing a traversal rather than the cypher
query. This confirms my suspicion that it was because of cycling.
I'm still not sure why queries in general seem to be that slow, but I have
solved my
If you're in the UK (London) you might want to drop by at graphday this
week or come to one of our meetups for some advice.
Otherwise feel free to share your detailed model, example database and
queries here or on stackoverflow to get some help.
Cheers, Michael
On Mon, Nov 10, 2014 at 6:59 PM,
Hi guys,
searched for this but cant really make anything out of it.
I was happy to leave my desk yesterday with a working POC and after a
reboot today my DB managed to get corrupted.
From the other posts on the error i can see that you havent been able to
get any data from the issuers but
Wow Axel, Christian, and the Structr Team...
This is a SUPER move. With Structr maturing and Neo4j going 2.2, things
will be getting more and more interesting.
I have been quiet lately so as to not divert your attention from all the
amazing work your team is doing. But things are DEFINITELY
I will try that next time that happens, but one time when I was able to
cancel it normally (running as ./neo4j console), it took a while to stop
and then had the following errors:
16:36:01.151 [Thread-192] WARN o.e.j.util.thread.QueuedThreadPool -
qtp1198728399{STOPPING,8=62=80,i=0,q=0}
I would have betted GC, but perhaps it was locking. So threads waiting for
each other to either finish writing the commit logs (which is synchronized)
or waiting for other threads to release locks on nodes that are updated
concurrently. Is there any means for you to group nodes that are updated
Thanks a lot Per,
was there anything noticeable on your system? Disk full? Power outage?
So your Neo4j server was running and you rebooted while it was running?
On Mon, Nov 10, 2014 at 7:28 PM, Per Svensson per.svensson...@gmail.com
wrote:
Hi guys,
searched for this but cant really make
Here is the thread dump for a situation where isolated delete queries have
started timing out: http://pastebin.com/u3Ecsp8i
We do share some nodes quite heavily (ie they'll be involved in many
transactions), so it could be a locking issue. I don't think we can really
do all those in 1
Hi Ryan,
so are you deleting the whole db?
Wouldn't it be faster to shutdown the server clean out the graph.db
directory and restart?
Also the id's of the deleted elements are not reused until the next restart.
Something I could imagine would help for your delete operation is to
separate
I think the queries timing out are just an indication of all processing
threads blocked on locks, and then adding delete queries on top of that
doesn't make it better.
But if you delete the data anyway the indexes will be emptied as well?
Addressing the root cause of not getting locks, is the
16 matches
Mail list logo
