I realized this could be due to an inability by the JVM to create
additional native threads
You may need to increase the nproc limit on your systems.
-Eric
On Wed, Oct 1, 2014 at 11:12 AM, Geoffry Roberts threadedb...@gmail.com
wrote:
Thanks for the response.
The only reason I was
Or nofile (too). ulimit is your friend :)
Eric Newton wrote:
I realized this could be due to an inability by the JVM to create
additional native threads
You may need to increase the nproc limit on your systems.
-Eric
On Wed, Oct 1, 2014 at 11:12 AM, Geoffry Roberts
Apparently, my JDBC driver, no matter what settings one sets, always tries
to load the entire table into memory. I tried using Groovy's page facility
thinking it would fetch rows in an increment of say, 10k. It creates the
impression that it's doing this, but behind the scenes, it still tries to
You shouldn't have to create a new BatchWriter -- have you tried
reducing the amount of memory the BatchWriter will use? It keeps a cache
internally to try to do an amortization of Mutations to send to a given
tabletserver.
To limit this memory, use the BatchWriterConfig#setMaxMemory(long)