在Snappydata中創建20-30個表后獲取com.gemstone.gemfire.cache.LockTimeoutException

Question

Spark作業從hbase獲取數據，並將數據攝取到snappydata 1.1.0。 與Snappydata 1.1.0打包在一起的Spark作為獨立集群啟動（snappy和spark共享集群），並且作業通過spark restAPI提交給Spark。

Snappydata 1.1.0群集將在一周內保持穩定。 一旦; 柱狀表的數量達到20-30； 提取作業失敗，並出現以下提到的異常。 使用的總資源未達到50％。 在高峰期； 每個表的大小可以為10GB（10億行和25列）。

異常詳細信息：由以下原因引起：java.sql.SQLException：（SQLState = 40XL1嚴重性= 30000）（Server = sw4 / 10.49.2.117 [1527] Thread = ThriftProcessor-57）在io請求的時間內未獲得鎖定。 io.snappydata.thrift.SnappyDataService $ executeUpdate_result $ executeUpdate_resultStandardScheme.read（SnappyDatauteUpdate.Snap_pypypyUpdate_resultStandard_chem_data_io.snappydata.thrift.SnappyDataService $ executeUpdate_result $ executeUpdate_resultStandardScheme.read（SnappyDataService.java:8244）在io.snappydata.thrift處的io.snappydata.thrift.SnappyDataService $ Client.recv_executeUpdate（SnappyDataService.java:285）處的org.apache.thrift.TServiceClient.receiveBase（TServiceClient.java:86）處讀取（SnappyDataService.java:8160） .io.snappydata.thrift.internal.ClientService.executeUpdate（ClientService.java:976）上的.SnappyDataService $ Client.executeUpdate（SnappyDataService.java:269）在io.snappydata.thrift.internal.ClientStatement.executeUpdate（ClientStatement.java:687） ）在io.sna 位於org.apache.spark.sql.sources.JdbcExtendedUtils $ .executeUpdate（jdbcExtensions.scala：84）的ppydata.thrift.internal.ClientStatement.executeUpdate（ClientStatement.java:221）在org.apache.spark.sql.execution.columnar org.apache.spark.sql.sources.NativeTableRowLevelSecurityRelation $ class.createTable（interfaces.scala：444）的.impl.BaseColumnFormatRelation.createActualTables（ColumnFormatRelation.scala：376）位於org.apache.spark.sql.execution.columnar.JDBCAppendableRelation org.apache.spark.sql.execution.columnar.impl.DefaultSource.createRelation（DefaultSource.scala：191）的.createTable（JDBCAppendableRelation.scala：46）在org.apache.spark.sql.execution.columnar.impl.DefaultSource org.apache.spark.sql.execution.columnar.impl.DefaultSource.createRelation（DefaultSource.scala：41）的.createRelation（DefaultSource.scala：71）org.apache.spark.sql.execution.datasources.DataSource.resolveRelation （DataSource.scala：328）在org.apache.spark.sql.execution.command.CreateDataSourceTableCommand.run（createDataSou org.apache.spark.sql.execution.command.ExecutedCommandExec.sideEffectResult $ lzycompute（commands.scala：58）處的rceTables.scala：73），org.apache.spark.sql.execution.command.ExecutedCommandExec.sideEffectResult（commands。 scala：56）位於org.apache.spark.sql.execution.command.ExecutedCommandExec.doExecute（commands.scala：74）位於org.apache.spark.sql.execution.SparkPlan $$ anonfun $ execute $ 1.apply（SparkPlan。 scala：114），位於org.apache.spark.sql.execution.SparkPlan $$ anonfun $ execute $ 1.apply（SparkPlan.scala：114），位於org.apache.spark.sql.execution.SparkPlan $$ anonfun $ executeQuery $ 1。在org.apache.spark.sql.execution.SparkPlan.executeQuery（SparkPlan.scala：132）在org.apache.spark.rdd.RDDOperationScope $ .withScope（RDDOperationScope.scala：151）在org.apache.spark.sql.execution.SparkPlan.executeQuery（SparkPlan.scala：132）處應用（SparkPlan.scala：135） org.org.apache.spark.sql.execution.SparkPlan.execute（SparkPlan.scala：113）在org.apache.spark.sql.execution.CodegenSparkFallback $$ anonfun $ doExecute $ 1.apply（CodegenSparkFallback.scala：175）在org。 apache.spark.sql.execution.CodegenSparkFallback $$ anon 在org.apache.spark.sql.execution.CodegenSparkFallback.executeWithFallback（CodegenSparkFallback.scala：113）處的fun $ doExecute $ 1.apply（CodegenSparkFallback.scala：175）在org.apache.spark.sql.execution.CodegenSparkFallback.doExecute .scala：175），位於org.apache.spark.sql.execution.SparkPlan $$ anonfun $ execute $ 1.apply（SparkPlan.scala：114），位於org.apache.spark.sql.execution.SparkPlan $$ anonfun $ execute $ 1 .apply（SparkPlan.scala：114），位於org.apache.spark.sql.execution.SparkPlan $$ anonfun $ executeQuery $ 1.apply（SparkPlan.scala：135），位於org.apache.spark.rdd.RDDOperationScope $ .withScope（ org.apache.spark.sql.execution.SparkPlan.executeQuery（SparkPlan.scala：132）的RDDOperationScope.scala：151），org的org.apache.spark.sql.execution.SparkPlan.execute（SparkPlan.scala：113）的RDDOperationScope.scala：151） org.apache.spark.sql.execution.QueryExecution.toRdd $ lzycompute（QueryExecution.scala：92）在org.apache.spark.sql.execution.QueryExecution.toRdd（QueryExecution.scala：92）在org.apache.spark.sql .SnappySession.createTableInternal（Snapp com.pw.smp.csa.SuspiciousActivityDetection $ .runjob（SuspiciousActivityDetection.scala：318）的org.apache.spark.sql.SnappySession.createTable（SnappySession.scala：990）的ySession.scala：1259）。位於com.pw.smp.csa.SuspiciousActivityDetection.main（SuspiciousActivityDetection.scala）上的smp.csa.SuspiciousActivityDetection $ .main（SuspiciousActivityDetection.scala：142）... 6更多原因：java.rmi.ServerException：服務器堆棧：java .sql.SQLTransactionRollbackException（40XL1）：在com.pivotal.gemfirexd.internal的com.pivotal.gemfirexd.internal.iapi.error.StandardException.newException（StandardException.java:456）請求的時間內無法獲得鎖定。 com.pivotal.gemfirexd.internal.engine.locks.GfxdDRWLockService.getLockTimeoutException（GfxdDRWLockService.java:727）上的engine.locks.GfxdLocalLockService.getLockTimeoutException（GfxdLocalLockService.java:295）在com.pivotal.gemfirexded.internal com.pivo上的utils.GemFireXDUtils.lockObject（GemFireXDUtils.java:1350） tal.gemfirexd.internal.impl.sql.catalog.GfxdDataDictionary.lockForWriting（GfxdDataDictionary.java:632）位於com.pivotal.gemfirexd.internal.impl.sql.catalog.GfxdDataDictionary.startWriting（GfxdDataDictionary.java）在com.pivotal.gemfirexd.internal.impl.sql.execute.CreateTableConstantAction.executeConstantAction（CreateTableConstantAction.java:297）處的axisal.gemfirexd.internal.impl.sql.catalog.GfxdDataDictionary.startWriting（GfxdDataDictionary.java:507）在com.pivotal的com.pivotal.gemfirexd.internal.impl.sql.GenericPreparedStatement.execute（GenericPreparedStatement.java:593）處的axisal.gemfirexd.internal.impl.sql.execute.MiscResultSet.open（MiscResultSet.java:64）在com.pivotal處。位於com.pivotal.gemfirexdinternal處的gemfirexd.internal.impl.jdbc.EmbedStatement.executeStatement（EmbedStatement.java:2179）位於com.pivotal.gemfirexd.internal.impl.jdbc.EmbedStatement.execute（EmbedStatement.java:1289）位於com.pivotal.gemfirexdinternal在com.pivotal.gemfirexd.internal.impl.jdbc.Em上的impl.jdbc.EmbedStatement.execute（EmbedStatement.java:1006） bedioment.executeUpdate（EmbedStatement.java:503）位於io.snappydata.thrift.server.SnappyDataServiceImpl.executeUpdate（SnappyDataServiceImpl.java:1794）位於io.snappydata.thrift.SnappyDataService $ Processor $ executeUpdate.getResult（SnappyDataService.java:1535）在io.snappydata.thrift.server.SnappyDataServiceImpl $ Processor在org.apache.thrift.ProcessFunction.process（ProcessFunction.java:39）在io.snappydata.thrift.SnappyDataService $ Processor $ executeUpdate.getResult（SnappyDataService.java:1519） io.snappydata.thrift.server.Snap.ThriftServerThreadPool $ WorkerProcess.run（SnappyThriftServerThreadPool.java:270）的java.util.concurrent.ThreadPoolExecutor.runWorker（ThreadPoolExecutor.java:1149）的.process（SnappyDataServiceImpl.java:201）。 io.snappydata.thrift.server.SnappyThriftServer $ 1.lambda $ newThread $ 0（SnappyThriftServer.java:143）上的util.concurrent.ThreadPoolExecutor $ Worker.run（ThreadPoolExecutor.java:624）在java.lang.Thread.run（Thread。 java：748）由：com.gemstone.gemfire.cache.Loc kTimeoutException：對象的鎖定超時：DefaultGfxdLockable @ a534854：GfxdDataDictionary，對於鎖定：GfxdReentrantReadWriteLock @ 77629235，QSync @ 3630b21a [name = GfxdDataDictionary] [readers = 0]，請求所有者：DistributedTXLockOwner（member = 10.49.2.1171（29） ，XID = 2667，ownerThread = Thread [ThriftProcessor-57,5，SnappyThriftServer線程]，vmCreatorThread = Thread [ThriftProcessor-57,5，SnappyThriftServer Thread]）位於com.pivotal.gemfirexd.internal.engine.locks.GfxdLocalLockService.getLockTimeoutRun GfxdLocalLockService.java:290），位於com.pivotal.gemfirexd.internal.engine.locks.GfxdLocalLockService.getLockTimeoutException（GfxdLocalLockService.java:296）... 22更多

at io.snappydata.thrift.common.ThriftExceptionUtil.newSQLException(ThriftExceptionUtil.java:109)
at io.snappydata.thrift.internal.ClientStatement.executeUpdate(ClientStatement.java:696)
... 42 more

Answer 1

數據字典被鎖定時，您的應用似乎正在嘗試創建表。 您的應用同時執行其他工作嗎？