Known Issues

The following key issues have been registered as bugs in the SnappyData bug tracking system:

BUG ID Title Description Workaround
SNAP-1375 JVM crash reported This was reported on:
- RHEL kernel version: 3.10.0-327.13.1.el7.x86_64
- Java version: 1.8.0_121
To resolve this, use:
- RHEL kernel version: 3.10.0-693.2.2.el7.x86_64
- Java version: 1.8.0_144
SNAP-1422 Catalog in smart connector inconsistent with servers Catalog in smart connector inconsistent with servers|When a table is queried from spark-shell (or from an application that uses smart connector mode) the table metadata is cached on the smart connector side.
If this table is dropped from SnappyData embedded cluster (by using snappy-shell, or JDBC application, or a Snappy job), the metadata on the smart connector side stays cached even though catalog has changed (table is dropped).
In such cases, the user may see unexpected errors like "org.apache.spark.sql.AnalysisException: Table `SNAPPYTABLE` already exists" in the smart connector app side for example for `DataFrameWriter.saveAsTable()` API if the same table name that was dropped is used in `saveAsTable()`
1. User may either create a new SnappySession in such scenarios
OR
2. Invalidate the cache on the Smart Connector mode, for example by calling
`snappy.sessionCatalog.invalidateAll()`
SNAP-1634 Creating a temporary table with the same name as an existing table in any schema should not be allowed When creating a temporary table, the SnappyData catalog is not referred, which means, a temporary table with the same name as that of an existing SnappyData table can be created. Two tables with the same name lead to ambiguity during query execution and can either cause the query to fail or return wrong results.
Ensure that you create temporary tables with a unique name.
SNAP-1753 TPCH Q19 execution performance degraded in 0.9 A disjunctive query (that is, query with two or more predicates joined by an OR clause) with common filter predicates may report performance issues. To resolve this, the query should be rewritten in the following manner to achieve better performance:
  
select
        sum(l_extendedprice) 
    from
        LINEITEM,
        PART
    where
        (
       p_partkey = l_partkey
       and p_size between 1 and 5
 and l_shipinstruct = 'DELIVER IN PERSON'
        )
        or
        (
       p_partkey = l_partkey
       and p_brand = 'Brand#?'
       and l_shipinstruct = 'DELIVER IN PERSON'
        )

select
        sum(l_extendedprice)
    from
        LINEITEM,
        PART
    where
        ( p_partkey = l_partkey and l_shipinstruct = 'DELIVER IN PERSON') and 
        ( p_size between 1 and 5 or  p_brand = 'Brand#3')
SNAP-1911 JVM crash reported This was reported on:
- RHEL kernel version: 3.10.0-327.13.1.el7.x86_64
- Java version: 1.8.0_131
To resolve this, use:
- RHEL kernel version: 3.10.0-693.2.2.el7.x86_64
- Java version: 1.8.0_144
SNAP-1999 JVM crash reported This was reported on:
- RHEL kernel version: 3.10.0-327.13.1.el7.x86_64
- Java version: 1.8.0_131
To resolve this, use:
- RHEL kernel version: 3.10.0-693.2.2.el7.x86_64
- Java version: 1.8.0_144
SNAP-2017 JVM crash reported This was reported on:
- RHEL kernel version: 3.10.0-514.10.2.el7.x86_64
- Java version: 1.8.0_144
To resolve this, use:
- RHEL kernel version: 3.10.0-693.2.2.el7.x86_64
- Java version: 1.8.0_144
SNAP-2436 Data mismatch in queries running on servers coming up after a failure Data mismatch is observed in queries which are running when some servers are coming up after a failure. Also, the tables on which the queries are running must have set their redundancy to one or more for the issue to be observed. This issue happens due to Spark retry mechanism with SnappyData tables. To avoid this issue, you can stop all the queries when one or more servers are coming up. If that is not feasible, you should configure the lead node with `spark.task.maxFailures = 0`;
SNAP-2381 Data inconsistency due to concurrent putInto/update operations Concurrent putInto/update operations and inserts in column tables with overlapping keys may cause data inconsistency. This problem is not seen when all the concurrent operations deal with different sets of rows. You can either ensure serialized mutable operations on column tables or these should be working on a distinct set of key columns.
SNAP-2457 Inconsistent results during further transformation when using snappySession.sql() from jobs, Zeppelin etc. When using snappySession.sql() from jobs, Zeppelin etc, if a further transformation is applied on the DataFrame, it may give incorrect results due to plan caching. If you are using SnappyJobs and using snappySession.sql("sql string") you must ensure that further transformation is not done. For example:
  
val df1 = snappySession.sql("sql string")
val df2 = df1.repartition(12) // modifying df1
df2.collect()
The above operation will give inconsistent results, if you are using df2 further in your code. To avoid this problem, you can use snappySession.sqlUncached("sql string"). For example:
 
val df1 = snappySession.sqlUncached("sql string")
val df2 = df1.repartition(12) // modifying df1
df2.collect()