Adding more run-time memory allocations from NAHeap This set of changes moves some of the string vector variables in HBase access operators from standard string template to our NAList and NAString (or HbaseStr for row IDs). In the process, allocationis of the objects will be from our HAHeap instead of the system heap. This would help us tracking memory usage and detecting leaks easier.
In addition, a change in ExHbaseAccessTcb::setupListOfColNames() prevents unnecessary allocations to populate the columns list unless it is empty. The Google profiling tools helped us on identifying this problem.
also, removed ExHbaseAccessDeleteTcb operator which was not used.
Reducing the path length for scan, single row get, batch get operations Earlier, Key-values per row is buffered as a ByteBuffer and shipped to JNI side.There were 2 C->java transitions to get the Hbase row into tuple format. Now, we avoid this copy on the Java side and ship the length and offsets of the Key-Value for all rows in a batch along with reference to the Key-Value buffer. The data is directly moved from Hbase Buffers to row format buffer. There are only 2 C->java transitions per batch of row. This has shown 3-4 times reduction in path length in Trafodion SQL processes while scanning a table with 12 million rows.
Trafodion SQL processes dump core when ex_assert function is called or when it exits with non-zero value. These processes will also dump core when an environment variable ABORT_ON_ERROR is set in release mode.
Fix for seabase/TEST010 failure with the patchSet 1
Rowset Select was dumping core sometimes. A wrong tuple was used to calculate the row length. It caused the proces to dump core sometimes.