AnsweredAssumed Answered

getTable threads blocked on Inode.closeAll in MapR

Question asked by itrs.eng on Jul 17, 2018

We are experiencing an issue that first appeared to be a deadlock in MapR but seems to be more of a live lock scenario. We have several threads attempting to get a table. 


Each thread has this stack trace: 


"" #22 prio=5 os_prio=0 tid=0x00007f62f6fd70d0 nid=0x7e38 waiting for monitor entry [0x00007f62ac94e000] java.lang.Thread.State: BLOCKED (on object monitor) at com.mapr.fs.MapRFileSystem.initConfig( - waiting to lock <0x000000008026f610> (a java.lang.Integer) at com.mapr.fs.MapRFileSystem.initialize( at com.mapr.fs.MapRFileSystem.initialize( at com.mapr.fs.MapRHTable.init( - locked <0x0000000080acb6e8> (a com.mapr.fs.MapRHTable) at com.mapr.fs.hbase.HTableImpl.( at com.mapr.fs.hbase.HTableImpl11.( at sun.reflect.GeneratedConstructorAccessor14.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance( at java.lang.reflect.Constructor.newInstance( at org.apache.hadoop.hbase.client.mapr.GenericHFactory.getImplementorInstance( at org.apache.hadoop.hbase.client.HTable.createMapRTable( at org.apache.hadoop.hbase.client.HTable$ at org.apache.hadoop.hbase.client.HTable$ at Method) at at at org.apache.hadoop.hbase.client.HTable.initIfMapRTableImpl( at org.apache.hadoop.hbase.client.HTable.initIfMapRTable( at org.apache.hadoop.hbase.client.HTable.( at com.mapr.fs.hbase.MapRClusterConnectionImpl.getTable( at com.mapr.fs.hbase.MapRClusterConnectionImpl.getTable(


The thread that has the lock on this Integer has the following stack:


"" #23 prio=5 os_prio=0 tid=0x00007f62f6feee30 nid=0x7e39 runnable [0x00007f62ac84e000]
java.lang.Thread.State: RUNNABLE
at com.mapr.fs.Inode.closeAll(
at com.mapr.fs.BackgroundWork.close(
at com.mapr.fs.MapRFileSystem.close(
- locked <0x000000008026f610> (a java.lang.Integer)


All table access to getTable is via a "using" style construct so we know we're closing tables.   The  blocking file system call is as follows:


def withFileSystem[T](conf: Configuration = EmptyConfiguration)(thunk: FileSystem => T): T = {
  using(FileSystem.get(conf)) { fileSystem =>

So we are closing the fs. ( ie using closes the fileSystem object) 


Quickly checking the MapR code in the IDE ( which just decomps it crudely)  the lock appears to be on numInstances inside of MapRFileSystem.


synchronized(numInstances) {
Integer var2 = numInstances;
numInstances = numInstances - 1;
if (numInstances == 0) {


BackgroundWork.close() calls Inode.closeAll().  


Now.. we have observed in the past that Inode.closeAll() can appear to hang but in those cases it seemed to be more related to code version mismatch ( we specifically saw this in 6.0.1).   From what i can see we have no such version mismatch this time around ( although the line numbers in the stack don't match the decompiled code line numbers). 


The code inside Inode.CloseAll is suspicious.   That is, it appears that Inode.List.first may not be threadsafe or may be racey, as the only way for Inode.CloseAll to never complete would be that Inode.List.first always returns a non null item.   All the while, it holds the lock on numInstances in a kind of busy spin of the infinite variety.   We end up with a CPU going at 100% and the only way to stop this is to restart the application. 


More info:

- ulimit -n  is 64000

- MapRBuildVersion is 

- If we do numerous hits to getTable around the same time ( multiple threads) we can get this to happen. if only a couple of threads are running it does not occur.

- Feels somewhat related to MapR-DB Java API Thread Issue // Hang?  


I think this needs to be resolved as it is causing us all kinds of problems.  So my questions are: 


- Is this a MapR code problem?  ( i think any potential for an infinite lock hold is pretty bad)

- Is the MapRFileSystem class threadsafe?  We think it should be as implementations of FileSystem are supposed to be threadsafe. 

- Is Inode.List and Inode itself threadsafe?  It really seems like it has a potential there for an infinite loop.

- Could there be some underlying contention between getFileSystem and getTable ?

- Is there anything else that you can observed that might help us resolve without a code patch 


Thanks for your assistance,