Hello Sulabh,
We're going to need a little more information before we can help.
Can you tell us how it fails? Are you trying to run a batch inserter on
different databases on each of your parallel jobs?
Jim
___
Neo4j mailing list
Also,
what technology are you writing those map-reduce jobs with ? (framework,
runtime-env, etc).
Some code samples would be great as well.
Cheers
Michael
Am 17.06.2011 um 22:24 schrieb Jim Webber:
Hello Sulabh,
We're going to need a little more information before we can help.
Can
Well as I mentioned the code does not fail anywhere, it runs it full course
and just skips the writing to the graph part.
I have just one graph and I pass just 1 instance of the batchInserter to
the map function.
My code is in Scala, sample code attached below
class ExportReducer extends
Hi Sulabh,
what do you mean by 'local' mode?
The batch inserter can only be used in a single threaded environment. You
shouldn't use it in a concurrent env as it will fail unpredictably.
Please use the EmbeddedGraphDatabase instead.
Michael
Am 17.06.2011 um 23:20 schrieb sulabh choudhury:
Are you referring that in a M/R environment each Map (or Reduce) process
will try to have its own instance of batchInserter and hence it would fail ?
WHen I say local I mean that the code works fine when I just use the M/R
api but fails when I try to run in distributed mode.
On Fri, Jun 17, 2011
No that would even be worse.
A single BatchInserter and every graphdb-store that is currently written to by
a batch inserter MUST be accessed from only a single single threaded
environment.
Please use the normal EmbeddedGraphDbService for your multi-threaded MR jobs.
Cheers
Michael
Am
Alright thank you all
On Fri, Jun 17, 2011 at 2:46 PM, Michael Hunger
michael.hun...@neotechnology.com wrote:
No that would even be worse.
A single BatchInserter and every graphdb-store that is currently written
to by a batch inserter MUST be accessed from only a single single threaded
7 matches
Mail list logo
