text:
[SUPPORT] hudi-0.15.0 spark sql query mro's ro table error: Caused by: java.io.FileNotFoundException: File does not exist: hdfs://hadoop/apps/hive/warehouse/hudi.db/hudi_qwe_cdc/partition_001/00000096-b062-4667-9c66-37fb8e3f26ef_1-8-2_20240802095544277.parquet

Tips before filing an issue

Have you gone through our FAQs? yes

Join the mailing list to engage in conversations and get faster support at dev-subscribe@hudi.apache.org.

If you have triaged this as a bug, then file an issue directly.

Describe the problem you faced
hudi-0.15.0 spark sql query mro's ro table error: Caused by: java.io.FileNotFoundException: File does not exist: hdfs://hadoop/apps/hive/warehouse/hudi.db/hudi_qwe_cdc/partition_001/00000096-b062-4667-9c66-37fb8e3f26ef_1-8-2_20240802095544277.parquet
Error when executing SQL using Spark SQL client:
spark-sql> INSERT OVERWRITE TABLE doris_dws.doris_aaaa_upd select source_document_id, max(gl_date) gl_date FROM  ods_rbs.ods_rbs_qwe_cdc_ro cfad where cfad._flink_cdc_op != 'd' group by source_document_id;
org.apache.spark.SparkException: Job aborted due to stage failure: Task 709 in stage 19.0 failed 4 times, most recent failure: Lost task 709.3 in stage 19.0 (TID 4209) (crpprd6hd02 executor 29): java.io.FileNotFoundException:
File does not exist: hdfs://cmccprdhadoop/apps/hive/warehouse/hudi.db/hudi_rbs_qwe_cdc/arch_acct_distributions/00000376-7e58-4ee3-b251-5e2958ab37f8_0-8-2_20240801162146243.parquet
It is possible the underlying files have been updated. You can explicitly invalidate
the cache in Spark by running 'REFRESH TABLE tableName' command in SQL or by
recreating the Dataset/DataFrame involved.
    at org.apache.spark.sql.errors.QueryExecutionErrors$.readCurrentFileNotFoundError(QueryExecutionErrors.scala:661)
    at org.apache.spark.sql.execution.datasources.FileScanRDD$$anon$1.org$apache$spark$sql$execution$datasources$FileScanRDD$$anon$$readCurrentFile(FileScanRDD.scala:212)
    at org.apache.spark.sql.execution.datasources.FileScanRDD$$anon$1.nextIterator(FileScanRDD.scala:270)
    at org.apache.spark.sql.execution.datasources.FileScanRDD$$anon$1.hasNext(FileScanRDD.scala:116)
    at org.apache.spark.sql.execution.FileSourceScanExec$$anon$1.hasNext(DataSourceScanExec.scala:561)
    at org.apache.spark.sql.catalyst.expressions.GeneratedClass$GeneratedIteratorForCodegenStage2.columnartorow_nextBatch_0$(Unknown Source)
    at org.apache.spark.sql.catalyst.expressions.GeneratedClass$GeneratedIteratorForCodegenStage2.processNext(Unknown Source)
    at org.apache.spark.sql.execution.BufferedRowIterator.hasNext(BufferedRowIterator.java:43)
    at org.apache.spark.sql.execution.WholeStageCodegenExec$$anon$1.hasNext(WholeStageCodegenExec.scala:760)
    at scala.collection.Iterator$$anon$10.hasNext(Iterator.scala:460)
    at org.apache.spark.shuffle.sort.BypassMergeSortShuffleWriter.write(BypassMergeSortShuffleWriter.java:140)
    at org.apache.spark.shuffle.ShuffleWriteProcessor.write(ShuffleWriteProcessor.scala:59)
    at org.apache.spark.scheduler.ShuffleMapTask.runTask(ShuffleMapTask.scala:99)
    at org.apache.spark.scheduler.ShuffleMapTask.runTask(ShuffleMapTask.scala:52)
    at org.apache.spark.scheduler.Task.run(Task.scala:136)
    at org.apache.spark.executor.Executor$TaskRunner.$anonfun$run$3(Executor.scala:548)
    at org.apache.spark.util.Utils$.tryWithSafeFinally(Utils.scala:1504)
    at org.apache.spark.executor.Executor$TaskRunner.run(Executor.scala:551)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
    at java.lang.Thread.run(Thread.java:748)

Driver stacktrace:
at org.apache.spark.scheduler.DAGScheduler.failJobAndIndependentStages(DAGScheduler.scala:2672)
at org.apache.spark.scheduler.DAGScheduler.$anonfun$abortStage$2(DAGScheduler.scala:2608)
at org.apache.spark.scheduler.DAGScheduler.$anonfun$abortStage$2$adapted(DAGScheduler.scala:2607)
at scala.collection.mutable.ResizableArray.foreach(ResizableArray.scala:62)
at scala.collection.mutable.ResizableArray.foreach$(ResizableArray.scala:55)
at scala.collection.mutable.ArrayBuffer.foreach(ArrayBuffer.scala:49)
at org.apache.spark.scheduler.DAGScheduler.abortStage(DAGScheduler.scala:2607)
at org.apache.spark.scheduler.DAGScheduler.$anonfun$handleTaskSetFailed$1(DAGScheduler.scala:1182)
at org.apache.spark.scheduler.DAGScheduler.$anonfun$handleTaskSetFailed$1$adapted(DAGScheduler.scala:1182)
at scala.Option.foreach(Option.scala:407)
at org.apache.spark.scheduler.DAGScheduler.handleTaskSetFailed(DAGScheduler.scala:1182)
at org.apache.spark.scheduler.DAGSchedulerEventProcessLoop.doOnReceive(DAGScheduler.scala:2860)
at org.apache.spark.scheduler.DAGSchedulerEventProcessLoop.onReceive(DAGScheduler.scala:2802)
at org.apache.spark.scheduler.DAGSchedulerEventProcessLoop.onReceive(DAGScheduler.scala:2791)
at org.apache.spark.util.EventLoop$$anon$1.run(EventLoop.scala:49)
Caused by: java.io.FileNotFoundException:
File does not exist: hdfs://cmccprdhadoop/apps/hive/warehouse/hudi.db/hudi_rbs_qwe_cdc/arch_acct_distributions/00000376-7e58-4ee3-b251-5e2958ab37f8_0-8-2_20240801162146243.parquet
It is possible the underlying files have been updated. You can explicitly invalidate
the cache in Spark by running 'REFRESH TABLE tableName' command in SQL or by
recreating the Dataset/DataFrame involved.
    at org.apache.spark.sql.errors.QueryExecutionErrors$.readCurrentFileNotFoundError(QueryExecutionErrors.scala:661)
    at org.apache.spark.sql.execution.datasources.FileScanRDD$$anon$1.org$apache$spark$sql$execution$datasources$FileScanRDD$$anon$$readCurrentFile(FileScanRDD.scala:212)
    at org.apache.spark.sql.execution.datasources.FileScanRDD$$anon$1.nextIterator(FileScanRDD.scala:270)
    at org.apache.spark.sql.execution.datasources.FileScanRDD$$anon$1.hasNext(FileScanRDD.scala:116)
    at org.apache.spark.sql.execution.FileSourceScanExec$$anon$1.hasNext(DataSourceScanExec.scala:561)
    at org.apache.spark.sql.catalyst.expressions.GeneratedClass$GeneratedIteratorForCodegenStage2.columnartorow_nextBatch_0$(Unknown Source)
    at org.apache.spark.sql.catalyst.expressions.GeneratedClass$GeneratedIteratorForCodegenStage2.processNext(Unknown Source)
    at org.apache.spark.sql.execution.BufferedRowIterator.hasNext(BufferedRowIterator.java:43)
    at org.apache.spark.sql.execution.WholeStageCodegenExec$$anon$1.hasNext(WholeStageCodegenExec.scala:760)
    at scala.collection.Iterator$$anon$10.hasNext(Iterator.scala:460)
    at org.apache.spark.shuffle.sort.BypassMergeSortShuffleWriter.write(BypassMergeSortShuffleWriter.java:140)
    at org.apache.spark.shuffle.ShuffleWriteProcessor.write(ShuffleWriteProcessor.scala:59)
    at org.apache.spark.scheduler.ShuffleMapTask.runTask(ShuffleMapTask.scala:99)
    at org.apache.spark.scheduler.ShuffleMapTask.runTask(ShuffleMapTask.scala:52)
    at org.apache.spark.scheduler.Task.run(Task.scala:136)
    at org.apache.spark.executor.Executor$TaskRunner.$anonfun$run$3(Executor.scala:548)
    at org.apache.spark.util.Utils$.tryWithSafeFinally(Utils.scala:1504)
    at org.apache.spark.executor.Executor$TaskRunner.run(Executor.scala:551)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
    at java.lang.Thread.run(Thread.java:748)

According to the prompt, first execute: "REFRESH TABLE ods_rbs.ods_rbs_qwe_cdc_ro" then execute the SQL: "INSERT OVERWRITE TABLE doris_dws.doris_aaaa_upd select source_document_id, max(gl_date) gl_date FROM ods_rbs.ods_rbs_qwe_cdc_ro cfad where cfad._flink_cdc_op != 'd' group by source_document_id;" still getting an error:
spark-sql>
> REFRESH TABLE ods_rbs.ods_rbs_qwe_cdc_ro;
Time taken: 0.176 seconds
spark-sql> INSERT OVERWRITE TABLE doris_dws.doris_aaaa_upd select source_document_id, max(gl_date) gl_date FROM  ods_rbs.ods_rbs_qwe_cdc_ro cfad where cfad._flink_cdc_op != 'd' group by source_document_id;
24/08/02 16:40:26 WARN TaskSetManager: Lost task 695.0 in stage 64.0 (TID 12954) (crpprd13hd04 executor 36): java.io.FileNotFoundException: File does not exist: hdfs://cmccprdhadoop/apps/hive/warehouse/hudi.db/hudi_qwe_cdc/partition_001/00000186-a762-4e67-823c-00cde3350e13_2-8-2_20240801181045754.parquet
at org.apache.hadoop.hdfs.DistributedFileSystem$29.doCall(DistributedFileSystem.java:1757)
at org.apache.hadoop.hdfs.DistributedFileSystem$29.doCall(DistributedFileSystem.java:1750)
at org.apache.hadoop.fs.FileSystemLinkResolver.resolve(FileSystemLinkResolver.java:81)
at org.apache.hadoop.hdfs.DistributedFileSystem.getFileStatus(DistributedFileSystem.java:1765)
at org.apache.parquet.hadoop.util.HadoopInputFile.fromPath(HadoopInputFile.java:39)
at org.apache.spark.sql.execution.datasources.parquet.ParquetFooterReader.readFooter(ParquetFooterReader.java:39)
at org.apache.spark.sql.execution.datasources.parquet.Spark33LegacyHoodieParquetFileFormat.footerFileMetaData$lzycompute$1(Spark33LegacyHoodieParquetFileFormat.scala:172)
at org.apache.spark.sql.execution.datasources.parquet.Spark33LegacyHoodieParquetFileFormat.footerFileMetaData$1(Spark33LegacyHoodieParquetFileFormat.scala:171)
at org.apache.spark.sql.execution.datasources.parquet.Spark33LegacyHoodieParquetFileFormat.$anonfun$buildReaderWithPartitionValues$1(Spark33LegacyHoodieParquetFileFormat.scala:175)
at org.apache.hudi.HoodieDataSourceHelper$.$anonfun$buildHoodieParquetReader$1(HoodieDataSourceHelper.scala:68)
at org.apache.hudi.HoodieBaseRelation.$anonfun$createBaseFileReader$2(HoodieBaseRelation.scala:586)
at org.apache.hudi.HoodieBaseRelation$BaseFileReader.apply(HoodieBaseRelation.scala:677)
at org.apache.hudi.RecordMergingFileIterator.(Iterators.scala:250)
at org.apache.hudi.HoodieMergeOnReadRDD.compute(HoodieMergeOnReadRDD.scala:109)
at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:365)
at org.apache.spark.rdd.RDD.iterator(RDD.scala:329)
at org.apache.spark.rdd.MapPartitionsRDD.compute(MapPartitionsRDD.scala:52)
at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:365)
at org.apache.spark.rdd.RDD.iterator(RDD.scala:329)
at org.apache.spark.rdd.MapPartitionsRDD.compute(MapPartitionsRDD.scala:52)
at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:365)
at org.apache.spark.rdd.RDD.iterator(RDD.scala:329)
at org.apache.spark.shuffle.ShuffleWriteProcessor.write(ShuffleWriteProcessor.scala:59)
at org.apache.spark.scheduler.ShuffleMapTask.runTask(ShuffleMapTask.scala:99)
at org.apache.spark.scheduler.ShuffleMapTask.runTask(ShuffleMapTask.scala:52)
at org.apache.spark.scheduler.Task.run(Task.scala:136)
at org.apache.spark.executor.Executor$TaskRunner.$anonfun$run$3(Executor.scala:548)
at org.apache.spark.util.Utils$.tryWithSafeFinally(Utils.scala:1504)
at org.apache.spark.executor.Executor$TaskRunner.run(Executor.scala:551)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
24/08/02 16:40:26 WARN TaskSetManager: Lost task 701.0 in stage 64.0 (TID 12962) (crpprd6hd25 executor 39): java.io.FileNotFoundException: File does not exist: hdfs://cmccprdhadoop/apps/hive/warehouse/hudi.db/hudi_qwe_cdc/partition_001/00000609-2108-40f4-b999-faebd67f0706_1-8-2_20240801113831765.parquet
at org.apache.hadoop.hdfs.DistributedFileSystem$29.doCall(DistributedFileSystem.java:1757)
at org.apache.hadoop.hdfs.DistributedFileSystem$29.doCall(DistributedFileSystem.java:1750)
at org.apache.hadoop.fs.FileSystemLinkResolver.resolve(FileSystemLinkResolver.java:81)
at org.apache.hadoop.hdfs.DistributedFileSystem.getFileStatus(DistributedFileSystem.java:1765)
at org.apache.parquet.hadoop.util.HadoopInputFile.fromPath(HadoopInputFile.java:39)
at org.apache.spark.sql.execution.datasources.parquet.ParquetFooterReader.readFooter(ParquetFooterReader.java:39)
at org.apache.spark.sql.execution.datasources.parquet.Spark33LegacyHoodieParquetFileFormat.footerFileMetaData$lzycompute$1(Spark33LegacyHoodieParquetFileFormat.scala:172)
at org.apache.spark.sql.execution.datasources.parquet.Spark33LegacyHoodieParquetFileFormat.footerFileMetaData$1(Spark33LegacyHoodieParquetFileFormat.scala:171)
at org.apache.spark.sql.execution.datasources.parquet.Spark33LegacyHoodieParquetFileFormat.$anonfun$buildReaderWithPartitionValues$1(Spark33LegacyHoodieParquetFileFormat.scala:175)
at org.apache.hudi.HoodieDataSourceHelper$.$anonfun$buildHoodieParquetReader$1(HoodieDataSourceHelper.scala:68)
at org.apache.hudi.HoodieBaseRelation.$anonfun$createBaseFileReader$2(HoodieBaseRelation.scala:586)
at org.apache.hudi.HoodieBaseRelation$BaseFileReader.apply(HoodieBaseRelation.scala:677)
at org.apache.hudi.RecordMergingFileIterator.(Iterators.scala:250)
at org.apache.hudi.HoodieMergeOnReadRDD.compute(HoodieMergeOnReadRDD.scala:109)
at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:365)
at org.apache.spark.rdd.RDD.iterator(RDD.scala:329)
at org.apache.spark.rdd.MapPartitionsRDD.compute(MapPartitionsRDD.scala:52)
at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:365)
at org.apache.spark.rdd.RDD.iterator(RDD.scala:329)
at org.apache.spark.rdd.MapPartitionsRDD.compute(MapPartitionsRDD.scala:52)
at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:365)
at org.apache.spark.rdd.RDD.iterator(RDD.scala:329)
at org.apache.spark.shuffle.ShuffleWriteProcessor.write(ShuffleWriteProcessor.scala:59)
at org.apache.spark.scheduler.ShuffleMapTask.runTask(ShuffleMapTask.scala:99)
at org.apache.spark.scheduler.ShuffleMapTask.runTask(ShuffleMapTask.scala:52)
at org.apache.spark.scheduler.Task.run(Task.scala:136)
at org.apache.spark.executor.Executor$TaskRunner.$anonfun$run$3(Executor.scala:548)
at org.apache.spark.util.Utils$.tryWithSafeFinally(Utils.scala:1504)
at org.apache.spark.executor.Executor$TaskRunner.run(Executor.scala:551)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
24/08/02 16:40:26 ERROR TaskSetManager: Task 695 in stage 64.0 failed 4 times; aborting job
org.apache.spark.SparkException: Job aborted due to stage failure: Task 695 in stage 64.0 failed 4 times, most recent failure: Lost task 695.3 in stage 64.0 (TID 12963) (crpprd6hd25 executor 39): java.io.FileNotFoundException: File does not exist: hdfs://cmccprdhadoop/apps/hive/warehouse/hudi.db/hudi_qwe_cdc/partition_001/00000186-a762-4e67-823c-00cde3350e13_2-8-2_20240801181045754.parquet
at org.apache.hadoop.hdfs.DistributedFileSystem$29.doCall(DistributedFileSystem.java:1757)
at org.apache.hadoop.hdfs.DistributedFileSystem$29.doCall(DistributedFileSystem.java:1750)
at org.apache.hadoop.fs.FileSystemLinkResolver.resolve(FileSystemLinkResolver.java:81)
at org.apache.hadoop.hdfs.DistributedFileSystem.getFileStatus(DistributedFileSystem.java:1765)
at org.apache.parquet.hadoop.util.HadoopInputFile.fromPath(HadoopInputFile.java:39)
at org.apache.spark.sql.execution.datasources.parquet.ParquetFooterReader.readFooter(ParquetFooterReader.java:39)
at org.apache.spark.sql.execution.datasources.parquet.Spark33LegacyHoodieParquetFileFormat.footerFileMetaData$lzycompute$1(Spark33LegacyHoodieParquetFileFormat.scala:172)
at org.apache.spark.sql.execution.datasources.parquet.Spark33LegacyHoodieParquetFileFormat.footerFileMetaData$1(Spark33LegacyHoodieParquetFileFormat.scala:171)
at org.apache.spark.sql.execution.datasources.parquet.Spark33LegacyHoodieParquetFileFormat.$anonfun$buildReaderWithPartitionValues$1(Spark33LegacyHoodieParquetFileFormat.scala:175)
at org.apache.hudi.HoodieDataSourceHelper$.$anonfun$buildHoodieParquetReader$1(HoodieDataSourceHelper.scala:68)
at org.apache.hudi.HoodieBaseRelation.$anonfun$createBaseFileReader$2(HoodieBaseRelation.scala:586)
at org.apache.hudi.HoodieBaseRelation$BaseFileReader.apply(HoodieBaseRelation.scala:677)
at org.apache.hudi.RecordMergingFileIterator.(Iterators.scala:250)
at org.apache.hudi.HoodieMergeOnReadRDD.compute(HoodieMergeOnReadRDD.scala:109)
at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:365)
at org.apache.spark.rdd.RDD.iterator(RDD.scala:329)
at org.apache.spark.rdd.MapPartitionsRDD.compute(MapPartitionsRDD.scala:52)
at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:365)
at org.apache.spark.rdd.RDD.iterator(RDD.scala:329)
at org.apache.spark.rdd.MapPartitionsRDD.compute(MapPartitionsRDD.scala:52)
at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:365)
at org.apache.spark.rdd.RDD.iterator(RDD.scala:329)
at org.apache.spark.shuffle.ShuffleWriteProcessor.write(ShuffleWriteProcessor.scala:59)
at org.apache.spark.scheduler.ShuffleMapTask.runTask(ShuffleMapTask.scala:99)
at org.apache.spark.scheduler.ShuffleMapTask.runTask(ShuffleMapTask.scala:52)
at org.apache.spark.scheduler.Task.run(Task.scala:136)
at org.apache.spark.executor.Executor$TaskRunner.$anonfun$run$3(Executor.scala:548)
at org.apache.spark.util.Utils$.tryWithSafeFinally(Utils.scala:1504)
at org.apache.spark.executor.Executor$TaskRunner.run(Executor.scala:551)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Driver stacktrace:
at org.apache.spark.scheduler.DAGScheduler.failJobAndIndependentStages(DAGScheduler.scala:2672)
at org.apache.spark.scheduler.DAGScheduler.$anonfun$abortStage$2(DAGScheduler.scala:2608)
at org.apache.spark.scheduler.DAGScheduler.$anonfun$abortStage$2$adapted(DAGScheduler.scala:2607)
at scala.collection.mutable.ResizableArray.foreach(ResizableArray.scala:62)
at scala.collection.mutable.ResizableArray.foreach$(ResizableArray.scala:55)
at scala.collection.mutable.ArrayBuffer.foreach(ArrayBuffer.scala:49)
at org.apache.spark.scheduler.DAGScheduler.abortStage(DAGScheduler.scala:2607)
at org.apache.spark.scheduler.DAGScheduler.$anonfun$handleTaskSetFailed$1(DAGScheduler.scala:1182)
at org.apache.spark.scheduler.DAGScheduler.$anonfun$handleTaskSetFailed$1$adapted(DAGScheduler.scala:1182)
at scala.Option.foreach(Option.scala:407)
at org.apache.spark.scheduler.DAGScheduler.handleTaskSetFailed(DAGScheduler.scala:1182)
at org.apache.spark.scheduler.DAGSchedulerEventProcessLoop.doOnReceive(DAGScheduler.scala:2860)
at org.apache.spark.scheduler.DAGSchedulerEventProcessLoop.onReceive(DAGScheduler.scala:2802)
at org.apache.spark.scheduler.DAGSchedulerEventProcessLoop.onReceive(DAGScheduler.scala:2791)
at org.apache.spark.util.EventLoop$$anon$1.run(EventLoop.scala:49)
Caused by: java.io.FileNotFoundException: File does not exist: hdfs://cmccprdhadoop/apps/hive/warehouse/hudi.db/hudi_qwe_cdc/partition_001/00000186-a762-4e67-823c-00cde3350e13_2-8-2_20240801181045754.parquet
at org.apache.hadoop.hdfs.DistributedFileSystem$29.doCall(DistributedFileSystem.java:1757)
at org.apache.hadoop.hdfs.DistributedFileSystem$29.doCall(DistributedFileSystem.java:1750)
at org.apache.hadoop.fs.FileSystemLinkResolver.resolve(FileSystemLinkResolver.java:81)
at org.apache.hadoop.hdfs.DistributedFileSystem.getFileStatus(DistributedFileSystem.java:1765)
at org.apache.parquet.hadoop.util.HadoopInputFile.fromPath(HadoopInputFile.java:39)
at org.apache.spark.sql.execution.datasources.parquet.ParquetFooterReader.readFooter(ParquetFooterReader.java:39)
at org.apache.spark.sql.execution.datasources.parquet.Spark33LegacyHoodieParquetFileFormat.footerFileMetaData$lzycompute$1(Spark33LegacyHoodieParquetFileFormat.scala:172)
at org.apache.spark.sql.execution.datasources.parquet.Spark33LegacyHoodieParquetFileFormat.footerFileMetaData$1(Spark33LegacyHoodieParquetFileFormat.scala:171)
at org.apache.spark.sql.execution.datasources.parquet.Spark33LegacyHoodieParquetFileFormat.$anonfun$buildReaderWithPartitionValues$1(Spark33LegacyHoodieParquetFileFormat.scala:175)
at org.apache.hudi.HoodieDataSourceHelper$.$anonfun$buildHoodieParquetReader$1(HoodieDataSourceHelper.scala:68)
at org.apache.hudi.HoodieBaseRelation.$anonfun$createBaseFileReader$2(HoodieBaseRelation.scala:586)
at org.apache.hudi.HoodieBaseRelation$BaseFileReader.apply(HoodieBaseRelation.scala:677)
at org.apache.hudi.RecordMergingFileIterator.(Iterators.scala:250)
at org.apache.hudi.HoodieMergeOnReadRDD.compute(HoodieMergeOnReadRDD.scala:109)
at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:365)
at org.apache.spark.rdd.RDD.iterator(RDD.scala:329)
at org.apache.spark.rdd.MapPartitionsRDD.compute(MapPartitionsRDD.scala:52)
at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:365)
at org.apache.spark.rdd.RDD.iterator(RDD.scala:329)
at org.apache.spark.rdd.MapPartitionsRDD.compute(MapPartitionsRDD.scala:52)
at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:365)
at org.apache.spark.rdd.RDD.iterator(RDD.scala:329)
at org.apache.spark.shuffle.ShuffleWriteProcessor.write(ShuffleWriteProcessor.scala:59)
at org.apache.spark.scheduler.ShuffleMapTask.runTask(ShuffleMapTask.scala:99)
at org.apache.spark.scheduler.ShuffleMapTask.runTask(ShuffleMapTask.scala:52)
at org.apache.spark.scheduler.Task.run(Task.scala:136)
at org.apache.spark.executor.Executor$TaskRunner.$anonfun$run$3(Executor.scala:548)
at org.apache.spark.util.Utils$.tryWithSafeFinally(Utils.scala:1504)
at org.apache.spark.executor.Executor$TaskRunner.run(Executor.scala:551)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
To Reproduce
Steps to reproduce the behavior:

Expected behavior
A clear and concise description of what you expected to happen.
Environment Description

Hudi version : 0.15.0

Spark version : 3.3.2

Hive version : 3.1.3

Hadoop version :

Storage (HDFS/S3/GCS..) :

Running on Docker? (yes/no) :

Additional context
Add any other context about the problem here.
Stacktrace
Add the stacktrace of the error.

@Toroidals How are you ingesting your data the first time and how are you syncing the table to metastore?

I'm also was able to reproduce the issue

source: gharchive/issue

authors: Toroidals ad1happy2go dderjugin

repo: apache/hudi


text:
Failed to read schema while doing delete_partition operation

Describe the problem you faced
When I do a delete_partition operation, during the sync-hive phase, this Exception will be thrown:
And only happens when the files to be deleted are the last committed data files.
User class threw exception: org.apache.hudi.exception.HoodieException: Got runtime exception when hive syncing test_delete_partition_1
at org.apache.hudi.hive.HiveSyncTool.syncHoodieTable(HiveSyncTool.java:118)
at org.apache.hudi.HoodieSparkSqlWriter$.syncHive(HoodieSparkSqlWriter.scala:539)
at org.apache.hudi.HoodieSparkSqlWriter$.$anonfun$metaSync$2(HoodieSparkSqlWriter.scala:595)
at org.apache.hudi.HoodieSparkSqlWriter$.$anonfun$metaSync$2$adapted(HoodieSparkSqlWriter.scala:591)
at scala.collection.mutable.HashSet.foreach(HashSet.scala:79)
at org.apache.hudi.HoodieSparkSqlWriter$.metaSync(HoodieSparkSqlWriter.scala:591)
at org.apache.hudi.HoodieSparkSqlWriter$.commitAndPerformPostOperations(HoodieSparkSqlWriter.scala:665)
at org.apache.hudi.HoodieSparkSqlWriter$.write(HoodieSparkSqlWriter.scala:286)
at org.apache.hudi.DefaultSource.createRelation(DefaultSource.scala:164)
at org.apache.spark.sql.execution.datasources.SaveIntoDataSourceCommand.run(SaveIntoDataSourceCommand.scala:46)
at org.apache.spark.sql.execution.command.ExecutedCommandExec.sideEffectResult$lzycompute(commands.scala:70)
at org.apache.spark.sql.execution.command.ExecutedCommandExec.sideEffectResult(commands.scala:68)
at org.apache.spark.sql.execution.command.ExecutedCommandExec.doExecute(commands.scala:90)
at org.apache.spark.sql.execution.SparkPlan.$anonfun$execute$1(SparkPlan.scala:180)
at org.apache.spark.sql.execution.SparkPlan.$anonfun$executeQuery$1(SparkPlan.scala:218)
at org.apache.spark.rdd.RDDOperationScope$.withScope(RDDOperationScope.scala:151)
at org.apache.spark.sql.execution.SparkPlan.executeQuery(SparkPlan.scala:215)
at org.apache.spark.sql.execution.SparkPlan.execute(SparkPlan.scala:176)
at org.apache.spark.sql.execution.QueryExecution.toRdd$lzycompute(QueryExecution.scala:127)
at org.apache.spark.sql.execution.QueryExecution.toRdd(QueryExecution.scala:126)
at org.apache.spark.sql.DataFrameWriter.$anonfun$runCommand$1(DataFrameWriter.scala:962)
at org.apache.spark.sql.execution.SQLExecution$.$anonfun$withNewExecutionId$5(SQLExecution.scala:100)
at org.apache.spark.sql.execution.SQLExecution$.withSQLConfPropagated(SQLExecution.scala:160)
at org.apache.spark.sql.execution.SQLExecution$.$anonfun$withNewExecutionId$1(SQLExecution.scala:87)
at org.apache.spark.sql.SparkSession.withActive(SparkSession.scala:767)
at org.apache.spark.sql.execution.SQLExecution$.withNewExecutionId(SQLExecution.scala:64)
at org.apache.spark.sql.DataFrameWriter.runCommand(DataFrameWriter.scala:962)
at org.apache.spark.sql.DataFrameWriter.saveToV1Source(DataFrameWriter.scala:414)
at org.apache.spark.sql.DataFrameWriter.save(DataFrameWriter.scala:398)
at org.apache.spark.sql.DataFrameWriter.save(DataFrameWriter.scala:287)
at tv.freewheel.reporting.river.spark.engine.RiverSparkBatchEngineContext.standardSinkingToHudi(RiverSparkBatchEngineContext.java:188)
at tv.freewheel.reporting.river.common.engine.RiverEngineContext.sinkToHudi(RiverEngineContext.java:131)
at tv.freewheel.reporting.river.core.RiverMain.main(RiverMain.java:42)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.apache.spark.deploy.yarn.ApplicationMaster$$anon$2.run(ApplicationMaster.scala:728)
Caused by: org.apache.hudi.sync.common.HoodieSyncException: Failed to read data schema
at org.apache.hudi.sync.common.AbstractSyncHoodieClient.getDataSchema(AbstractSyncHoodieClient.java:158)
at org.apache.hudi.hive.HiveSyncTool.syncHoodieTable(HiveSyncTool.java:171)
at org.apache.hudi.hive.HiveSyncTool.doSync(HiveSyncTool.java:129)
at org.apache.hudi.hive.HiveSyncTool.syncHoodieTable(HiveSyncTool.java:115)
... 37 more
Caused by: java.lang.IllegalArgumentException: Failed to read schema from data file s3a://hudi/test_delete_partition_1/1849/xxxx/xxxx/xxxx/e4043ee1-c8b8-4e5c-8788-b86d35d437d0-0_13-25-11859_20221206065637234.parquet. File does not exist.
at org.apache.hudi.common.table.TableSchemaResolver.readSchemaFromBaseFile(TableSchemaResolver.java:451)
at org.apache.hudi.common.table.TableSchemaResolver.getTableParquetSchemaFromDataFile(TableSchemaResolver.java:95)
at org.apache.hudi.common.table.TableSchemaResolver.getTableParquetSchema(TableSchemaResolver.java:209)
at org.apache.hudi.sync.common.AbstractSyncHoodieClient.getDataSchema(AbstractSyncHoodieClient.java:155)
... 40 more

To Reproduce
Steps to reproduce the behavior:
1.Upsert a dataframe into Hudi
2.Do delete_partition on this same dataframe
Environment Description

Hudi version : 0.10.1

Spark version : 3.0.3

Hive version : 2.3.7

Hadoop version : 3.3.0

Storage (HDFS/S3/GCS..) : S3

Running on Docker? (yes/no) : no

Additional context
Add any other context about the problem here.
Stacktrace
Add the stacktrace of the error.

@gaoshihang I was not able to reproduce this error , tried multiple scenarios with both Hudi version 0.13.0 and 0.10.1.
Are you still facing this issue, Can you try reproducing with mock up data and share us.
Code I used for reference. Please let me know in case of any issues.
    "hoodie.datasource.write.table.type": "COPY_ON_WRITE",
    "hoodie.datasource.write.recordkey.field": "id",
    "hoodie.datasource.write.precombine.field": "timestamp",
    "hoodie.datasource.write.partitionpath.field": "timestamp__date_",
    'hoodie.table.name': table_name,
    "hoodie.payload.ordering.field": "timestamp",
    'hoodie.datasource.hive_sync.mode': 'hms',
    'hoodie.datasource.hive_sync.use_jdbc': 'false',
}

schema = StructType([
    StructField("id", IntegerType(), True),
    StructField("b", IntegerType(), True),
    StructField("c", StringType(), True),
    StructField("d", StringType(), True),
    StructField("timestamp", StringType(), True),
    StructField("f", StringType(), True)
])

#df = spark.createDataFrame([
#    Row(id=3, b=2, c='string1', d="2000-01-01", timestamp="2000-01-01 12:00:00", f = "2000-01-01 12:00:00"),
#    Row(id=5, b=3, c='string2', d="2000-02-01", timestamp="2000-01-01 12:00:00", f = "2000-01-01 12:21:20"),
#    Row(id=6, b=5, c='string3', d="2000-03-01", timestamp="2000-01-01 12:00:00", f = "2000-01-03 12:00:00")
#], schema)

df = spark.createDataFrame([
    Row(id=5, b=3, c='string2', d="2000-02-01", timestamp="2000-01-01 12:00:00", f = "2000-01-01 12:21:20")
], schema)

df = df.withColumn("timestamp__date_", to_date(df["timestamp"]))
df.write.format("org.apache.hudi") \
    .options(**common_config) \
    .option("hoodie.datasource.hive_sync.database",db_name) \
    .option("hoodie.datasource.hive_sync.table",table_name) \
    .option("hoodie.datasource.hive_sync.partition_fields","timestamp__date_") \
    .option("hoodie.datasource.write.operation","upsert") \
    .mode("append") \
    .save(path)

df.write.format("org.apache.hudi") \
    .options(**common_config) \
    .option("hoodie.datasource.hive_sync.database",db_name) \
    .option("hoodie.datasource.hive_sync.table",table_name) \
    .option("hoodie.datasource.hive_sync.partition_fields","timestamp__date_") \
    .option("hoodie.datasource.write.operation","delete_partition") \
   .mode("append") \
    .save(path)

license_type: permissive

license_source: github-api


text:
Implement ManifestEvaluator to prune mainfest files.

See python implementation

I suppose this issue has been taken according to https://github.com/apache/iceberg-rust/pull/241#issuecomment-1987506207?

I suppose this issue has been taken according to #241 (comment)?

Not yet, there are some dependencies not implemented yet, I'll open issues and clarify their dependencies.

@liurenjie1024
Is it correct that we need to implement the ProjectionEvaluator beforehand in order to provide the partition_filters
and extend TableScan with row_filter: Predicate?
https://github.com/apache/iceberg-python/blob/4ed5a144ecad69878cf47292557b17df31ffe5a8/pyiceberg/table/__init__.py#L753-L763

@liurenjie1024 Is it correct that we need to implement the ProjectionEvaluator beforehand in order to provide the partition_filters and extend TableScan with row_filter: Predicate?
https://github.com/apache/iceberg-python/blob/4ed5a144ecad69878cf47292557b17df31ffe5a8/pyiceberg/table/__init__.py#L753-L763

Yes, and before that we need to implement project for transform.

I just browsed the issues, you've already listed the dependencies here:
linking this for ref:
https://github.com/apache/iceberg-rust/issues/153

Close by #322

authors: liurenjie1024 marvinlanhenke waynexia

repo: apache/iceberg-rust


text:
fix: equality delete writer field id project

I find that the definition of primitive type is different between arrow and iceberg, which cause the condition in equality delete writer to be wrong. This PR fixes it and add test.
Also find that the decimal of parquet statistic has different representation for different precision, this case not covert in original test and has something wrong in parse phase. Thi PR also fixed it and add test.

cc @liurenjie1024

source: gharchive/pull-request


text:
IGNITE-3678: Test for partition distribution

This submission includes a test that will assert the even and safe distribution of partitions when server nodes are forcibly killed.
Additionally, the following are included:
(1) A new Assertion interface. This looks similar on the surface to IgnitePredicate - however there are two subtle differences:

it returns void, not boolean
it throws AssertionError
Since this does not return boolean, the caller does not have to check for the result of the assertion; if the assertion fails an exception is thrown which contains the details of the failed assertion.

(2) GridRollingRestartAbstractTest: a new abstract test class that is extended for tests that require:

multiple JVMs
the first JVM to be a client (i.e. not own any partitions)
the server JVMs to be killed forcibly (not gracefully) while the test executes

Merged as 632ff9c0098e1d62c106cc6a2c3b3c49ab1005d7

repo: apache/ignite


text:
Stream load error

Http return fail log when using stream load.
Pls help to check this.
Thx
2021-02-01 14:14:01,673 ERROR com.xxx   http://xxx/api/XXX/_stream_load<<<   {
    "TxnId": 8934328,
    "Label": "b41ad882-abc2-4cee-957e-ab75c4b3d696",
    "Status": "Fail",
    "Message": "already stopped, skip waiting for close. cancelled/!eos: : 1/0",
    "NumberTotalRows": 0,
    "NumberLoadedRows": 0,
    "NumberFilteredRows": 0,
    "NumberUnselectedRows": 0,
    "LoadBytes": 905053,
    "LoadTimeMs": 1350,
    "BeginTxnTimeMs": 0,
    "StreamLoadPutTimeMs": 1,
    "ReadDataTimeMs": 0,
    "WriteDataTimeMs": 1344,
    "CommitAndPublishTimeMs": 0
}

2021-01-29 13:50:34,318 ERROR com.xxx [] - >>>   http://xxx/api/XXX/_stream_load<<<   {
    "TxnId": 7792672,
    "Label": "2697ab3d-dcd3-419a-9f8a-d75f34d12821",
    "Status": "Fail",
    "Message": "failed to call frontend service",
    "NumberTotalRows": 36127,
    "NumberLoadedRows": 36127,
    "NumberFilteredRows": 0,
    "NumberUnselectedRows": 0,
    "LoadBytes": 45654428,
    "LoadTimeMs": 27277,
    "BeginTxnTimeMs": 0,
    "StreamLoadPutTimeMs": 2,
    "ReadDataTimeMs": 88,
    "WriteDataTimeMs": 4250,
    "CommitAndPublishTimeMs": 0
}

It means that the stream load being cancelled for some reason.
you have to check be.INFO for more information.
Maybe you can just retry to see if it still happen.

I also encountered this problem, json data format
W0201 16:20:45.516393 164407 thrift_rpc_helper.cpp:84] call frontend service failed, address=TNetworkAddress(hostname=172.22.197.240, port=9020), reason=THRIFT_EAGAIN (timed out)
W0201 16:20:47.517021 164407 stream_load.cpp:113] handle streaming load failed, id=bc4ca94a908d84f9-7d483648c5534dba, errmsg=failed to call frontend service

repo: apache/incubator-doris


text:
spelling mistake:   "proejct" to "project"

What is the purpose of the change
spelling mistake:   "proejct" to "project"
Brief changelog
spelling mistake:   "proejct" to "project"
Follow this checklist to help us incorporate your contribution quickly and easily:

[x] Make sure there is a GITHUB_issue filed for the change (usually before you start working on it). Trivial changes like typos do not require a GITHUB issue. Your pull request should address just this issue, without pulling in other changes - one PR resolves one issue.
[ ] Format the pull request title like Fix UnknownException when host config not exist #XXX. Each commit in the pull request should have a meaningful subject line and body.
[ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
[ ] Test your code locally by running docsite start, and make sure it works as expected.
[ ] Make sure no files under build directory is added.
[ ] If this contribution is large, please follow the Software Donation Guide.

Thanks for the pull request, LGTM!

repo: apache/incubator-dubbo-website


text:
warn Unsupported category providers,configurators,routers

[ ] I have searched the issues of this repository and believe that this is not a duplicate.
[ ] I have checked the FAQ of this repository and believe that this is not a duplicate.

Environment

Dubbo version: 2.6.2
Operating System version: CentOS x64
Java version: 1.8

Steps to reproduce this issue

使用dubbo 2.6.2，搭建dubbo服务（技术栈：dubbo，spring boot 2.0.4.RELEASE，zookeeper）
暴露dubbo任意dubbo服务，此服务的逻辑中调用别的服务
运行一段时间后，发现控制台界面出现以下警告：
WARN  com.alibaba.dubbo.registry.integration.RegistryDirectory:200 notify [DUBBO] Unsupported category providers,configurators,routers in notified url: empty://。。。

从日志中查看到，警告为RegistryDirectory类第 200行打印出的警告，如下图：

通过断点，进一步追综代码运行堆栈，发现，问题可能在于  CuratorWatcherImpl （CuratorZookeeperClient类的一个内部类），process方法中，path为null引起，如下图：

因为当以上170行代码的 path为null 的时候，会被赋予一个空字符串""，这导致 171行代码调用childChanged时，传了空串参数进去。（请注意上图中第172处的  // if path is null, curator using watcher will throw NullPointerException. 之类的注释，可能有助于解决这个问题）
因为为path赋值了空串参数，导致 ZookeeperRegistry类中的 179行代码进调用 notify 的时候，传了空字符串参数进去，如下图：

（说明：以上代码块为 ZookeeperRegistry 中的 doSubscribe 方法，用于消费者订阅 ，该方法内部开启了一个监听节点变化的 listener），因为进传递进来的 parentPath 参数为空串，导致 179行代码在调用 toUrlsWithEmpty 方法的时候，得到的 url 中的 category 的值依旧为providers,configurators,routers ，重而导致上诉警告。

通过以上分析，问题原因，很可能就是 RegistryDirectory类第 170行处path为null引起，通过那段代码块的注释，我猜测，可能 是为了解决 空指针异常而产生的新的警告，相关issue如下：
https://github.com/apache/incubator-dubbo/issues/870
https://github.com/apache/incubator-dubbo/pull/928

if ptah is null. maybe the connect or disconnect event,  I think it can be ignore and  childListener.childChanged method should not be called

repo: apache/incubator-dubbo


text:
Add CI Integration

As far as I can tell, there is no CI integration with this project. May I suggest we add a CI Integration? We could use CircleCI or GitLab CI (https://docs.gitlab.com/ee/ci/ci_cd_for_external_repos/github_integration.html)

@ClemMakesApps Hi Clement. We are considering adding CI support, probably Travis.
The ECharts project depends on ZRender project. When developing locally, we use a soft link in echarts/node_modules to the local zrender project.
**When using CI, how should we specify using the latest ZRender commit (rather than ZRender npm release) when building ECharts project? **
For example, there may be a new function in the latest ZRender commit, and a new ECharts commit calls this new function. Since the function is not included in the latest ZRender release on npm, npm i zrender will not help.
npm supports something like npm install --save "git://github.com/username/package.git#commit", although I'm not sure this is helpful.
Could you please give some idea about this?

I think you can use 'npm link' to use any local non project.

Instead of
"dependencies": {
  "zrender": "4.0.6"
},

in master,
if you could do
"dependencies": {
  "zrender": "git://github.com/ecomfe/zrender.git"
},

that should pull the latest master commit for zrender. According to https://docs.npmjs.com/files/package.json#git-urls-as-dependencies

It is possible to pull in the latest ZRender master commit but there is a risk in doing so.
If we are pulling in the latest zrender at all times, your upstream dependency could break your CI builds in this project at any moment. This could make the CI pipeline unreliable for this project

Agree. With each ci test, a determined version is useful when test failure emerges.

@ClemMakesApps Is it possible to use "zrender": "git://github.com/ecomfe/zrender.git" for master CI, while keeping "zrender": "4.0.6" for release branch and hopefully for the default package.json of ECharts project?

I understand using a specific version in CI is out of the consideration of reliability. But in our situation, upstream is fully under our control and ZRender should be updated before ECharts. So depending on the latest commit should have no problem.

Even though ZRender is currently under the control of ECharts core team, I still don't think it's the most optimal approach for this project. The core team for both projects could change over time, especially since one project is still under Baidu's organization while this is going through the Apache incubation process. This also makes it more difficult for contributors to contribute to ECharts because their builds may fail in the event ZRender has a breaking commit/change. In addition, this in my opinion complicates the release process (for both projects) more than it needs to be.
If we really need to add ZRender master branch as a dependency, I would recommend adding a CI job on ZRender to check for breaking changes on ECharts on each commit. In the very least, that will ensure that each commit on ZRender doesn't indirectly break ECharts.

@ClemMakesApps Thanks Clement for the details!
We also have an internal discussion. And the conclusion is, we are going to use the npm release version on zrender in echarts project, for both master and release branch. And if there's a breaking change in zrender that echarts relies on, we will publish a non-latest version of zrender first, and then merge the related logic of echarts from a feature branch into master or release branch.
Besides, I'm working on a full doc for developing workflow so that people from the community can understand how to help.

authors: ClemMakesApps Ovilia chfw

repo: apache/incubator-echarts

license_source: bigquery


text:
[Enhancement] Method handle(HttpExchange) manually handles closing an auto-closeable resource [SSLContextFactory]

Search before asking

[X] I had searched in the issues and found no similar issues.

Enhancement Request

located at:
eventmesh-runtime/src/main/java/org/apache/eventmesh/runtime/boot/SSLContextFactory.java
analysis and explanation:
This method allocates and uses an auto closeable resource. However, it manually closes the resource in a finally block. While this is correct management, it doesn't rely on the idiomatic way available to JDK 7 and above, allows for possible subtle problems, and complicates the reading of code by developers expecting the use of try-with-resources.
Describe the solution you'd like
Change to use try-with-resources to manage resources.
Are you willing to submit PR?

[x] Yes I am willing to submit a PR!

I want to fix it.

authors: Alonexc jonyangx

repo: apache/incubator-eventmesh


text:
[HUDI-454] Redo hudi-cli log statements using SLF4J

What is the purpose of the pull request
Redo hudi-cli log statements using SLF4J.
Brief change log
Modify AnnotationLocation checkstyle rule in checkstyle.xml
Verify this pull request
Use existing tests to verify the original module.
Committer checklist

[ ] Has a corresponding JIRA in PR title & commit

[ ] Commit message is descriptive of the change

[ ] CI is green

[ ] Necessary doc changes done or have another open PR

[ ] For large changes, please consider breaking it into sub-tasks under an umbrella JIRA.

Hi @XuQianJin-Stars Found check style errors, the detailed log file is here: https://api.travis-ci.org/v3/job/630558609/log.txt

I found that
ERROR StatusLogger No log4j2 configuration file found. Using default configuration: logging only errors to the console.

If there is only one single project changing log4j to slf4j, is there a problem of log class conflict?

I found that in https://api.travis-ci.org/v3/job/630558609/log.txt
ERROR StatusLogger No log4j2 configuration file found. Using default configuration: logging only errors to the console.

If there is only one single project changing log4j to slf4j, is there a problem of log class conflict?

Maybe they are irrelevant? I fond another green PR which also contains this message in its log file.

@yanghua It may be log4j2 depend error, and it's not caused by this change. Please ignore this :)

@XuQianJin-Stars Thanks for opening this PR, Could you please reopen and merge this PR to redo-log branch? more context can be found https://lists.apache.org/thread.html/9dc1f3a590413a5224a1a5ad835353e11b2b754e1ec7ad1ca0a55053%40<dev.hudi.apache.org>, Thanks.

authors: XuQianJin-Stars cdmikechen leesf yanghua

repo: apache/incubator-hudi


text:
[Question] graphs/hugegraph/graph/vertices API 报 NotFoundException

Bug Type (问题类型)
server status (启动/运行异常)
Before submit

[X] 我已经确认现有的 Issues 与 FAQ 中没有相同 / 重复问题 (I have confirmed and searched that there are no similar problems in the historical issue and documents)

Environment (环境信息)

Server Version: 1.0.0 (Apache Release Version)
Backend: MySQL 8.0.32
OS: CentOS 7.x

Expected & Actual behavior (期望与实际表现)
Actual behavior

Vertex/Edge example (问题点 / 边数据举例)
No response
Schema [VertexLabel, EdgeLabel, IndexLabel] (元数据结构)
No response

Thanks for the report, we need more context to ensure the problem

ensure the hugegraph exist (try visit localhost:8080/graphs to see the result)
ensure we use the correct HTTP Method with vertex API

Thanks for the report, we need more context to ensure the problem

ensure the hugegraph exist (try visit localhost:8080/graphs to see the result)
ensure we use the correct HTTP Method with vertex API

1、访问 localhost:8080/graphs 没有出现问题：

2、目前还在搭建hugegraph的环境，并没有导入任何图数据，所以访问vertex应该是空的，一切步骤都是按照官方的文档进行操作，初始化数据库，和开启server是正常的：

我在进行init操作时，出现的日志是这样的：
[root@DESKTOP-UABNU86 bin]# ./init-store.sh
Initializing HugeGraph Store...
2023-04-12 13:48:45 [main] [INFO] o.a.h.u.ConfigUtil - Scanning option 'graphs' directory './conf/graphs'
2023-04-12 13:48:45 [main] [INFO] o.a.h.c.InitStore - Init graph with config file: ./conf/graphs/hugegraph.properties
2023-04-12 13:48:45 [main] [WARN] o.a.h.c.HugeConfig - The config option 'jdbc.sslmode' is redundant, please ensure it has been registered
2023-04-12 13:48:45 [main] [INFO] o.a.h.b.s.m.MysqlSessions - Connect to the jdbc url: 'jdbc:mysql://127.0.0.1:3306/?socketTimeout=0&useSSL=false'
Loading class com.mysql.jdbc.Driver'. This is deprecated. The new driver class is com.mysql.cj.jdbc.Driver'. The driver is automatically registered via the SPI and manual loading of the driver class is generally unnecessary.
2023-04-12 13:48:45 [main] [INFO] o.a.h.b.s.m.MysqlSessions - Connect to the jdbc url: 'jdbc:mysql://127.0.0.1:3306/hugegraph?characterEncoding=utf-8&rewriteBatchedStatements=true&useServerPrepStmts=false&autoReconnect=false&maxReconnects=3&initialTimeout=3&useSSL=false'
2023-04-12 13:48:45 [main] [INFO] o.a.h.b.s.m.MysqlSessions - Connect to the jdbc url: 'jdbc:mysql://127.0.0.1:3306/hugegraph?characterEncoding=utf-8&rewriteBatchedStatements=true&useServerPrepStmts=false&autoReconnect=true&maxReconnects=3&initialTimeout=3&useSSL=false'
2023-04-12 13:48:45 [main] [INFO] o.a.h.b.c.CacheManager - Init RamCache for 'schema-id-hugegraph' with capacity 10000
2023-04-12 13:48:45 [main] [INFO] o.a.h.b.c.CacheManager - Init RamCache for 'schema-name-hugegraph' with capacity 100002023-04-12 13:48:45 [main] [INFO] o.a.h.b.s.m.MysqlSessions - Connect to the jdbc url: 'jdbc:mysql://127.0.0.1:3306/?socketTimeout=0&useSSL=false'
2023-04-12 13:48:45 [main] [INFO] o.a.h.b.s.m.MysqlSessions - Connect to the jdbc url: 'jdbc:mysql://127.0.0.1:3306/hugegraph?characterEncoding=utf-8&rewriteBatchedStatements=true&useServerPrepStmts=false&autoReconnect=false&maxReconnects=3&initialTimeout=3&useSSL=false'
2023-04-12 13:48:45 [main] [INFO] o.a.h.b.s.m.MysqlSessions - Connect to the jdbc url: 'jdbc:mysql://127.0.0.1:3306/hugegraph?characterEncoding=utf-8&rewriteBatchedStatements=true&useServerPrepStmts=false&autoReconnect=true&maxReconnects=3&initialTimeout=3&useSSL=false'
main dict load finished, time elapsed 585 ms
model load finished, time elapsed 39 ms.
2023-04-12 13:48:46 [main] [INFO] o.a.h.b.s.m.MysqlSessions - Connect to the jdbc url: 'jdbc:mysql://127.0.0.1:3306/?socketTimeout=0&useSSL=false'
2023-04-12 13:48:46 [main] [INFO] o.a.h.b.s.m.MysqlSessions - Connect to the jdbc url: 'jdbc:mysql://127.0.0.1:3306/hugegraph?characterEncoding=utf-8&rewriteBatchedStatements=true&useServerPrepStmts=false&autoReconnect=false&maxReconnects=3&initialTimeout=3&useSSL=false'
2023-04-12 13:48:46 [main] [INFO] o.a.h.b.s.m.MysqlSessions - Connect to the jdbc url: 'jdbc:mysql://127.0.0.1:3306/hugegraph?characterEncoding=utf-8&rewriteBatchedStatements=true&useServerPrepStmts=false&autoReconnect=true&maxReconnects=3&initialTimeout=3&useSSL=false'
2023-04-12 13:48:46 [main] [INFO] o.c.o.l.Uns - OHC using JNA OS native malloc/free
2023-04-12 13:48:46 [main] [INFO] o.a.h.b.c.CacheManager - Init LevelCache for 'vertex-hugegraph' with capacity 10000:10000000
2023-04-12 13:48:46 [main] [INFO] o.a.h.b.c.CacheManager - Init LevelCache for 'edge-hugegraph' with capacity 1000:1000000
2023-04-12 13:48:46 [main] [INFO] o.a.h.b.c.CacheManager - Init RamCache for 'users-hugegraph' with capacity 10240
2023-04-12 13:48:46 [main] [INFO] o.a.h.b.c.CacheManager - Init RamCache for 'users_pwd-hugegraph' with capacity 10240
2023-04-12 13:48:46 [main] [INFO] o.a.h.b.c.CacheManager - Init RamCache for 'token-hugegraph' with capacity 10240
2023-04-12 13:48:46 [main] [INFO] o.a.h.b.s.m.MysqlSessions - Connect to the jdbc url: 'jdbc:mysql://127.0.0.1:3306/?socketTimeout=0&useSSL=false'
2023-04-12 13:48:46 [main] [INFO] o.a.h.b.s.m.MysqlSessions - Connect to the jdbc url: 'jdbc:mysql://127.0.0.1:3306/hugegraph?socketTimeout=0&useSSL=false'
2023-04-12 13:48:46 [main] [INFO] o.a.h.b.s.m.MysqlSessions - Connect to the jdbc url: 'jdbc:mysql://127.0.0.1:3306/hugegraph?socketTimeout=0&useSSL=false'
2023-04-12 13:48:46 [main] [INFO] o.a.h.b.s.m.MysqlSessions - Connect to the jdbc url: 'jdbc:mysql://127.0.0.1:3306/hugegraph?socketTimeout=0&useSSL=false'
2023-04-12 13:48:46 [main] [INFO] o.a.h.b.s.m.MysqlSessions - Connect to the jdbc url: 'jdbc:mysql://127.0.0.1:3306/hugegraph?socketTimeout=0&useSSL=false'
2023-04-12 13:48:46 [main] [INFO] o.a.h.b.s.m.MysqlSessions - Connect to the jdbc url: 'jdbc:mysql://127.0.0.1:3306/hugegraph?socketTimeout=0&useSSL=false'
2023-04-12 13:48:46 [main] [INFO] o.a.h.b.s.m.MysqlSessions - Connect to the jdbc url: 'jdbc:mysql://127.0.0.1:3306/hugegraph?socketTimeout=0&useSSL=false'
2023-04-12 13:48:46 [main] [INFO] o.a.h.b.s.m.MysqlSessions - Connect to the jdbc url: 'jdbc:mysql://127.0.0.1:3306/hugegraph?socketTimeout=0&useSSL=false'
2023-04-12 13:48:46 [main] [INFO] o.a.h.b.s.m.MysqlSessions - Connect to the jdbc url: 'jdbc:mysql://127.0.0.1:3306/hugegraph?socketTimeout=0&useSSL=false'
2023-04-12 13:48:46 [main] [INFO] o.a.h.b.s.m.MysqlSessions - Connect to the jdbc url: 'jdbc:mysql://127.0.0.1:3306/hugegraph?socketTimeout=0&useSSL=false'
2023-04-12 13:48:46 [main] [INFO] o.a.h.b.s.m.MysqlSessions - Connect to the jdbc url: 'jdbc:mysql://127.0.0.1:3306/hugegraph?socketTimeout=0&useSSL=false'
2023-04-12 13:48:46 [main] [INFO] o.a.h.b.s.m.MysqlSessions - Connect to the jdbc url: 'jdbc:mysql://127.0.0.1:3306/hugegraph?socketTimeout=0&useSSL=false'
2023-04-12 13:48:46 [main] [INFO] o.a.h.b.s.m.MysqlSessions - Connect to the jdbc url: 'jdbc:mysql://127.0.0.1:3306/hugegraph?socketTimeout=0&useSSL=false'
2023-04-12 13:48:46 [main] [INFO] o.a.h.b.s.m.MysqlSessions - Connect to the jdbc url: 'jdbc:mysql://127.0.0.1:3306/?socketTimeout=0&useSSL=false'
2023-04-12 13:48:46 [main] [INFO] o.a.h.b.s.m.MysqlSessions - Connect to the jdbc url: 'jdbc:mysql://127.0.0.1:3306/hugegraph?socketTimeout=0&useSSL=false'
2023-04-12 13:48:46 [main] [INFO] o.a.h.b.s.m.MysqlSessions - Connect to the jdbc url: 'jdbc:mysql://127.0.0.1:3306/hugegraph?socketTimeout=0&useSSL=false'
2023-04-12 13:48:46 [main] [INFO] o.a.h.b.s.m.MysqlSessions - Connect to the jdbc url: 'jdbc:mysql://127.0.0.1:3306/hugegraph?socketTimeout=0&useSSL=false'
2023-04-12 13:48:46 [main] [INFO] o.a.h.b.s.m.MysqlSessions - Connect to the jdbc url: 'jdbc:mysql://127.0.0.1:3306/hugegraph?socketTimeout=0&useSSL=false'
2023-04-12 13:48:46 [main] [INFO] o.a.h.b.s.m.MysqlSessions - Connect to the jdbc url: 'jdbc:mysql://127.0.0.1:3306/hugegraph?socketTimeout=0&useSSL=false'
2023-04-12 13:48:46 [main] [INFO] o.a.h.b.s.m.MysqlSessions - Connect to the jdbc url: 'jdbc:mysql://127.0.0.1:3306/hugegraph?socketTimeout=0&useSSL=false'
2023-04-12 13:48:46 [main] [INFO] o.a.h.b.s.m.MysqlSessions - Connect to the jdbc url: 'jdbc:mysql://127.0.0.1:3306/hugegraph?socketTimeout=0&useSSL=false'
2023-04-12 13:48:46 [main] [INFO] o.a.h.b.s.m.MysqlSessions - Connect to the jdbc url: 'jdbc:mysql://127.0.0.1:3306/hugegraph?socketTimeout=0&useSSL=false'
2023-04-12 13:48:46 [main] [INFO] o.a.h.b.s.m.MysqlSessions - Connect to the jdbc url: 'jdbc:mysql://127.0.0.1:3306/hugegraph?socketTimeout=0&useSSL=false'
2023-04-12 13:48:46 [main] [INFO] o.a.h.b.s.m.MysqlSessions - Connect to the jdbc url: 'jdbc:mysql://127.0.0.1:3306/hugegraph?socketTimeout=0&useSSL=false'
2023-04-12 13:48:46 [main] [INFO] o.a.h.b.s.m.MysqlSessions - Connect to the jdbc url: 'jdbc:mysql://127.0.0.1:3306/hugegraph?socketTimeout=0&useSSL=false'
2023-04-12 13:48:46 [main] [INFO] o.a.h.b.s.m.MysqlSessions - Connect to the jdbc url: 'jdbc:mysql://127.0.0.1:3306/?socketTimeout=0&useSSL=false'
2023-04-12 13:48:46 [main] [INFO] o.a.h.b.s.m.MysqlSessions - Connect to the jdbc url: 'jdbc:mysql://127.0.0.1:3306/hugegraph?socketTimeout=0&useSSL=false'
2023-04-12 13:48:46 [main] [INFO] o.a.h.b.s.m.MysqlSessions - Connect to the jdbc url: 'jdbc:mysql://127.0.0.1:3306/hugegraph?socketTimeout=0&useSSL=false'
2023-04-12 13:48:46 [main] [INFO] o.a.h.b.s.m.MysqlSessions - Connect to the jdbc url: 'jdbc:mysql://127.0.0.1:3306/hugegraph?socketTimeout=0&useSSL=false'
2023-04-12 13:48:46 [main] [INFO] o.a.h.b.s.m.MysqlSessions - Connect to the jdbc url: 'jdbc:mysql://127.0.0.1:3306/hugegraph?socketTimeout=0&useSSL=false'
2023-04-12 13:48:47 [main] [INFO] o.a.h.b.s.m.MysqlSessions - Connect to the jdbc url: 'jdbc:mysql://127.0.0.1:3306/hugegraph?socketTimeout=0&useSSL=false'
2023-04-12 13:48:47 [main] [INFO] o.a.h.c.InitStore - Skip init-store due to the backend store of 'hugegraph' had been initialized
2023-04-12 13:48:47 [main] [INFO] o.a.h.b.s.m.MysqlSessions - Connect to the jdbc url: 'jdbc:mysql://127.0.0.1:3306/?socketTimeout=0&useSSL=false'
2023-04-12 13:48:47 [main] [INFO] o.a.h.StandardHugeGraph - Close graph standardhugegraph[hugegraph]
2023-04-12 13:48:47 [main] [INFO] o.a.h.HugeFactory - HugeFactory shutdown
2023-04-12 13:48:47 [hugegraph-shutdown] [INFO] o.a.h.HugeFactory - HugeGraph is shutting down
Initialization finished.
在init操作之前，我在lib中，引用了“mysql-connector-java-8.0.30.jar”这个包

2023-04-12 13:48:47 [main] [INFO] o.a.h.c.InitStore - Skip init-store due to the backend store of 'hugegraph' had been initialized

不好意思之前编辑了你的 comment, 本来是回复一下.. 从这里看它跳过了 hugegraph 的初始化, 那你需要看看是否启动 start-server 的时候日志里报错信息, 以及是否初始化完整了 (如果不确定是否完整, 又是空的 db, 可以在 mysql 里删掉之前的 hugegraph 然后重新初始化一次看看)

1、访问 localhost:8080/graphs 没有出现问题：
![image](https://user-images.githubusercontent.com/18582787/231384940-c71d06e8-5dbd-455e-9b75-> 4feaf5a2a5ca.png)

显然这是没有任何图初始化的输出呢, 是不符合预期的, 你需要 init-store 确认成功, 文档应该有这个步骤
返回应该是 {"graphs":["hugegraph"]}才对

已经解决问题了，原因是hugegraph.properties中mysql的配置少写了一个：jdbc.connect_database=hugegraph，
目前修改之后的配置是这样的：

2023-04-12 13:48:47 [main] [INFO] o.a.h.c.InitStore - Skip init-store due to the backend store of 'hugegraph' had been initialized

不好意思之前编辑了你的 comment, 本来是回复一下.. 从这里看它跳过了 hugegraph 的初始化:

那你需要看看是否启动 start-server 的时候日志里报错信息, 以及是否初始化完整了
如果不确定是否完整, 又是空的 db, 可以在 mysql 里删掉之前的 hugegraph 然后重新初始化一次看看

谢谢你，确实是因为数据库没有配置好导致的问题，现在get vertex已经没有问题了：

好的

好的

不知道有空在 server & doc 仓库提交两个小 PR 么? 可以帮助下其它 MySQL 用户

好的

不知道有空在 server & doc 仓库提交两个小 PR 么? 可以帮助下其它 MySQL 用户

您好，我刚刚提交了一个doc更改：新增MySQL做后端数据库的配置，不知道这样提交对不对

您好，我刚刚提交了一个 doc 更改：新增 MySQL 做后端数据库的配置，不知道这样提交对不对

可以的, 您可以直接在 doc 仓库那边提交 PR, 提交后我们可以直接 review / 修改更新的, 这样更直观准确一些 (好像现在还没提交 PR). 如果是不熟悉 PR 过程可以参考这里,  使用 Github 客户端会大幅简化流程

authors: imbajin lanerbean

repo: apache/incubator-hugegraph


text:
Issue-596: Holistic review of non-quarkus cloud chapter

Closes/Fixes/Resolves #596

Description:
Improvement to cloud sections

Please make sure that your PR meets the following requirements:

[ ] You have read the contributions doc
[ ] Pull Request title is properly formatted: Issue-XYZ Subject
[ ] Pull Request title contains the target branch if not targeting main: [0.9.x] Issue-XYZ Subject
[ ] The nav.adoc file has a link to this guide in the proper category
[ ] The index.adoc file has a card to this guide in the proper category, with a meaningful description

How to backport a pull request to a different branch?

In order to automatically create a backporting pull request please add one or more labels having the following format backport-<branch-name>, where <branch-name> is the name of the branch where the pull request must be backported to (e.g., backport-7.67.x to backport the original PR to the 7.67.x branch).

NOTE: backporting is an action aiming to move a change (usually a commit) from a branch (usually the main one) to another one, which is generally referring to a still maintained release branch. Keeping it simple: it is about to move a specific change or a set of them from one branch to another.

Once the original pull request is successfully merged, the automated action will create one backporting pull request per each label (with the previous format) that has been added.
If something goes wrong, the author will be notified and at this point a manual backporting is needed.

NOTE: this automated backporting is triggered whenever a pull request on main branch is labeled or closed, but both conditions must be satisfied to get the new PR created.

Found some extra flaws, apologies. :eyes: suggestions

repo: apache/incubator-kie-kogito-docs


text:
[KOGITO-9816] Adding ProcessDefinitionRegistration to springboot

Many thanks for submitting your Pull Request :heart:!
Please make sure that your PR meets the following requirements:

[ ] You have read the contributors guide
[ ] Your code is properly formatted according to this configuration
[ ] Pull Request title is properly formatted: KOGITO-XYZ Subject
[ ] Pull Request title contains the target branch if not targeting main: [0.9.x] KOGITO-XYZ Subject
[ ] Pull Request contains link to the JIRA issue
[ ] Pull Request contains link to any dependent or related Pull Request
[ ] Pull Request contains description of the issue
[ ] Pull Request does not include fixes for issues other than the main ticket

How to replicate CI configuration locally?

Build Chain tool does "simple" maven build(s), the builds are just Maven commands, but because the repositories relates and depends on each other and any change in API or class method could affect several of those repositories there is a need to use build-chain tool to handle cross repository builds and be sure that we always use latest version of the code for each repository.
build-chain tool is a build tool which can be used on command line locally or in Github Actions workflow(s), in case you need to change multiple repositories and send multiple dependent pull requests related with a change you can easily reproduce the same build by executing it on Github hosted environment or locally in your development environment. See local execution details to get more information about it.

How to retest this PR or trigger a specific build:

for pull request checks
Please add comment: Jenkins retest this

for a specific pull request check
Please add comment: Jenkins (re)run [kogito-runtimes|kogito-apps|kogito-examples] tests

for quarkus branch checks
Run checks against Quarkus current used branch
Please add comment: Jenkins run quarkus-branch

for a quarkus branch specific check
Run checks against Quarkus current used branch
Please add comment: Jenkins (re)run [kogito-runtimes|kogito-apps|kogito-examples] quarkus-branch

for quarkus main checks
Run checks against Quarkus main branch
Please add comment: Jenkins run quarkus-main

for a specific quarkus main check
Run checks against Quarkus main branch
Please add comment: Jenkins (re)run [kogito-runtimes|kogito-apps|kogito-examples] quarkus-main

for quarkus lts checks
Run checks against Quarkus lts branch
Please add comment: Jenkins run quarkus-lts

for a specific quarkus lts check
Run checks against Quarkus lts branch
Please add comment: Jenkins (re)run [kogito-runtimes|kogito-apps|kogito-examples] quarkus-lts

for native checks
Run native checks
Please add comment: Jenkins run native

for a specific native check
Run native checks
Please add comment: Jenkins (re)run [kogito-runtimes|kogito-apps|kogito-examples] native

for native lts checks
Run native checks against quarkus lts branch
Please add comment: Jenkins run native-lts

for a specific native lts check
Run native checks against quarkus lts branch
Please add comment: Jenkins (re)run [kogito-runtimes|kogito-apps|kogito-examples] native-lts

How to backport a pull request to a different branch?

In order to automatically create a backporting pull request please add one or more labels having the following format backport-<branch-name>, where <branch-name> is the name of the branch where the pull request must be backported to (e.g., backport-7.67.x to backport the original PR to the 7.67.x branch).

NOTE: backporting is an action aiming to move a change (usually a commit) from a branch (usually the main one) to another one, which is generally referring to a still maintained release branch. Keeping it simple: it is about to move a specific change or a set of them from one branch to another.

Once the original pull request is successfully merged, the automated action will create one backporting pull request per each label (with the previous format) that has been added.
If something goes wrong, the author will be notified and at this point a manual backporting is needed.

NOTE: this automated backporting is triggered whenever a pull request on main branch is labeled or closed, but both conditions must be satisfied to get the new PR created.

Quarkus-3 PR check is failing ... what to do ?

The Quarkus 3 check is applying patches from the `.ci/environments/quarkus-3/patches`.
The first patch, called 0001_before_sh.patch, is generated from Openrewrite .ci/environments/quarkus-3/quarkus3.yml recipe. The patch is created to speed up the check. But it may be that some changes in the PR broke this patch.
No panic, there is an easy way to regenerate it. You just need to comment on the PR:
jenkins rewrite quarkus-3

and it should, after some minutes (~20/30min) apply a commit on the PR with the patch regenerated.
Other patches were generated manually. If any of it fails, you will need to manually update it... and push your changes.

PR job #5 was: UNSTABLE
Possible explanation: This should be test failures

Reproducer
build-chain build full_downstream  -f 'https://raw.githubusercontent.com/${AUTHOR:apache}/incubator-kie-kogito-pipelines/${BRANCH:main}/.ci/buildchain-config-pr-cdb.yaml' -o 'bc' -p apache/incubator-kie-kogito-runtimes -u https://github.com/apache/incubator-kie-kogito-runtimes/pull/3310 --skipParallelCheckout
NOTE: To install the build-chain tool, please refer to https://github.com/kiegroup/github-action-build-chain#local-execution

Please look here: https://ci-builds.apache.org/job/KIE/job/kogito/job/main/job/pullrequest_jobs/job/kogito-runtimes-pr/job/PR-3310/5/display/redirect
Test results:

PASSED: 3256
FAILED: 1

Those are the test failures:

org.jbpm.bpmn2.ProcessFactoryTest.testActionNodeIsDroolsAction
testActionNodeIsDroolsAction() timed out after 10 seconds

repo: apache/incubator-kie-kogito-runtimes


text:
NO-ISSUE: Unable to copy and paste nodes in the new DMN Editor

Attempting to copy and paste a node in the editor resulted in a node being added to the DRG nodes menu, but not to the editor. The problem was that a new ID was never being generated.
This fix resolves that by using the randomize function similarly to how we use it in the BEE.
And ensures that the pasted nodes have a new ID and that the copied nodes retain their original IDs.
https://github.com/apache/incubator-kie-tools/assets/92726146/6893eae9-3cdc-42a5-a581-cae0ff884fe4

Hi Jozef, I had the same thought! :D I was still able to replicate the issue even when on Tiago's branch containing the fix, so this PR is needed 👍

repo: apache/incubator-kie-tools


text:
refactor: refact some code and clear some Scala code format alarm

What is the purpose of the change
refact some code and clear some Scala code format alarm
Related issues/PRs
Related issues: #2703
Checklist

[x] I have read the Contributing Guidelines on pull requests.
[x] I have explained the need for this PR and the problem it solves
[ ] I have explained the changes or the new features added to this PR
[ ] I have added tests corresponding to this change
[ ] I have updated the documentation to reflect this change
[ ] I have verified that this change is backward compatible (If not, please discuss on the Linkis mailing list first)
[ ] If this is a code change: I have written unit tests to fully verify the new behavior.

It's recommended that this PR only do this:[refact some code and clear some Scala code format alarm]

It's recommended that this PR only do this:[refact some code and clear some Scala code format alarm]

ok

repo: apache/incubator-linkis


text:
[MXNET-892] ONNX export/import: DepthToSpace, SpaceToDepth operators

Description
Adding DepthToSpace, SpaceToDepth operators to ONNX import/export
v2: Added tests for SpaceToDepth.
Checklist
Essentials
Please feel free to remove inapplicable items for your PR.

[x] The PR title starts with [MXNET-$JIRA_ID], where $JIRA_ID refers to the relevant JIRA issue created (except PRs with tiny changes)
[x] Changes are complete (i.e. I finished coding on this PR)
[x] All changes have test coverage:
Unit tests are added for small changes to verify correctness (e.g. adding a new operator)
Nightly tests are added for complicated/long-running ones (e.g. changing distributed kvstore)
Build tests will be added for build configuration changes (e.g. adding a new build option with NCCL)
[x] Code is well-documented:
For user-facing API changes, API doc string has been updated.
For new C++ functions in header files, their functionalities and arguments are documented.
For new examples, README.md is added to explain the what the example does, the source of the dataset, expected performance on test set and reference to the original paper if applicable
Check the API doc at http://mxnet-ci-doc.s3-accelerate.dualstack.amazonaws.com/PR-$PR_ID/$BUILD_ID/index.html
[x] To the my best knowledge, examples are either not affected by this change, or have been fixed to be compatible with this change

Changes

Added DepthToSpace, SpaceToDepth operator import/export
Added tests for DepthToSpace

Comments
Temporarily adding tests for SpaceToDepth in mxnet_export_test.py and onnx_import_test.py.

@mxnet-label-bot [pr-awaiting-review]

@anirudhacharya @zhreshold @Roshrini for review

@Roshrini @anirudhacharya - Can you please take a look at this PR?

Thanks for adding test Vandana. Lgtm

Updated the test for SpaceToDepth - removed hard coded input/output. Since ONNX export test executed import, export, import, maintaining the custom test only in mxnet_export_test.py.

Addressed all the review comments so far. Please have a look @zhreshold @anirudhacharya @Roshrini

@zhreshold Can you take a look and merge if it looks good?

@vandanavk See comment, if you find it's more convenient to implement that later in a separate PR, I can merge this one now.

authors: Roshrini sandeep-krishnamurthy vandanavk vrakesh zhreshold

repo: apache/incubator-mxnet


text:
armv7-a/r: modify regs index to improve exception performance

Summary
Modify arm regs index to improve exception handler performance.
Impact
Code Size:
Before:
  text	   data	    bss	    dec	    hex	filename
 110164	    224	  24940	 135328	  210a0	nuttx

After:
  text	   data	    bss	    dec	    hex	filename
 110084	    224	  24940	 135248	  21050	nuttx

Performance:
sem_post -> sem_wait (cycle count):
before:
358
after:
350
Testing
sabre-6quad:nsh

@masayuki2009 could you review this change?

repo: apache/incubator-nuttx


text:
[Paimon-794][Improvement] Display the specific table name in the error message when the table doesn't support lookup join

fix: #794
module: flink
Purpose
Show more detailed msg which include the table name when the table doesn't support the lookup join ability.
Tests
(List UT and IT cases to verify this change) no
API and Format
(Does this change affect API or storage format) no
Documentation
(Does this change introduce a new feature) no

+1 merged

repo: apache/incubator-paimon


text:
Support Supervision.restart for SubFlow's

Provide support for restarting subflow.

@He-Pin @jxnu-liguobin @Roiocam @raboof
So I just noticed that for SubFlow's in general the supervision strategy doesn't properly propagate (see comment at https://github.com/apache/incubator-pekko/blob/c44c0b7cbdab11d85176cfe062288fdcba16c56a/stream-tests/src/test/scala/org/apache/pekko/stream/scaladsl/FlowSplitAfterSpec.scala#L213) which mean that this PR isn't going to work until we solve the fundamental underlying issue.
Due to this I will set the PR to blocked and make another issue on this point

I'm planning to cut an RC for 1.1.0-M1. This will likely not be in it - but can be included in 1.1.0-M2.

I'm planning to cut an RC for 1.1.0-M1. This will likely not be in it - but can be included in 1.1.0-M2.

There is an actual bug with the functionality introduced in https://github.com/apache/incubator-pekko/pull/252, i.e. Supervision.resumeStrategy doesn't actually resume when an exception is thrown.
This needs to be solved for 1.1.0, ideally in -M1 but I don't know when you wanted to make the actual release (I guess after incubation is fully passed?)

Bug made at https://github.com/apache/incubator-pekko/issues/1205

is there a chance that we could revert #252 and try a full change for 1.1.0-M2?

is there a chance that we could revert #252 and try a full change for 1.1.0-M2?

We are actually using this feature in production so I would try and avoid that. If fixing the bug ends up taking too long I would propose we fix it in 1.1.0-M2 since no one right now is actually relying on Supervision.resumeStrategy catching and resuming exceptions

I'm only to delaying the 1.1.0-M1-RC1 until next week if this a reasonable chance that this can be addressed soon.

Agreed

So I had a look at this after it was unblocked and it does seem to be harder than normal, this is because a new SubstreamHandler is created from the original input port which makes things complicated if we have already handed over to the new SubStreamHandler because we have crossed the boundary of the split decision. I think to solve this properly we need to persist already retrieved elements.
Furthermore its not just Split we have to support but also Group (the other operator that creates SubFlow). For this reason and in the interest of also reducing the number of milestones ill drop this unless I happen to be missing something.
@pjfanning @He-Pin @Roiocam wdyt?

Is this related to #1205 ?

No this is something else, its a new feature change

authors: mdedetrich pjfanning

repo: apache/incubator-pekko


text:
RYA-358 Added checkstyle policy to build and fixed problems.

Disabled snapshot repos since there are no snapshot dependencies.

Description
A number of classes use incorrect imports.

Added a checkstyle policy that fails the build if incorrect import statements are used
Fixed existing checkstyle violations.
Disabled third party snapshot repositories since this project has no third party snapshot dependencies.  This will reduce the number of unnecessary http requests a build will require in some scenarios.

Tests
N/A
Links
Jira RYA-358
Checklist

[ ] Code Review
[X] Squash Commits

People To Reivew
@meiercaleb
@amihalik

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/incubator-rya-master-with-optionals-pull-requests/529/

authors: asfgit jdasch

repo: apache/incubator-rya


text:
[Bug] java.lang.NoClassDefFoundError: org/apache/flink/table/api/bridge/java/StreamTableEnvironment

Search before asking

[X] I had searched in the issues and found no similar issues.

What happened
when run the example as docker flink
got the exception
java.lang.NoClassDefFoundError: org/apache/flink/table/api/bridge/java/StreamTableEnvironment
SeaTunnel Version
2.1.3
SeaTunnel Config
same as example in deploy/docker/flink/config/

Running Command
docker run -it --rm   -v $(pwd)/config:/seatunnel/config    -v $(pwd)/config/flink-conf.yaml:/flink/conf/flink-conf.yaml   --network flink_local   -e FLINK_PROPERTIES="jobmanager.rpc.address: jobmanager"   yihui8776/seatunnel-flink:v1 /seatunnel/bin/start-seatunnel-flink.sh --config /seatunnel/config/application.conf
Export JVM_ARGS: -Dexecution.parallelism=1

Error Exception
Export JVM_ARGS: -Dexecution.parallelism=1
Execute SeaTunnel Flink Job: ${FLINK_HOME}/bin/flink run -c org.apache.seatunnel.core.flink.SeatunnelFlink /seatunnel/lib/seatunnel-core-flink.jar --config /seatunnel/config/application.conf
Starting execution of program
java.lang.NoClassDefFoundError: org/apache/flink/table/api/bridge/java/StreamTableEnvironment
        at org.apache.seatunnel.flink.FlinkEnvironment.createStreamTableEnvironment(FlinkEnvironment.java:173)
        at org.apache.seatunnel.flink.FlinkEnvironment.prepare(FlinkEnvironment.java:93)
        at org.apache.seatunnel.flink.FlinkEnvironment.prepare(FlinkEnvironment.java:55)
        at org.apache.seatunnel.core.base.config.EnvironmentFactory.getEnvironment(EnvironmentFactory.java:63)
        at org.apache.seatunnel.core.base.config.AbstractExecutionContext.<init>(AbstractExecutionContext.java:53)
        at org.apache.seatunnel.core.flink.config.FlinkExecutionContext.<init>(FlinkExecutionContext.java:48)
        at org.apache.seatunnel.core.flink.command.FlinkApiTaskExecuteCommand.execute(FlinkApiTaskExecuteCommand.java:68)
        at org.apache.seatunnel.core.base.Seatunnel.run(Seatunnel.java:40)
        at org.apache.seatunnel.core.flink.SeatunnelFlink.main(SeatunnelFlink.java:34)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at org.apache.flink.client.program.PackagedProgram.callMainMethod(PackagedProgram.java:576)
        at org.apache.flink.client.program.PackagedProgram.invokeInteractiveModeForExecution(PackagedProgram.java:438)
        at org.apache.flink.client.program.ClusterClient.run(ClusterClient.java:274)
        at org.apache.flink.client.cli.CliFrontend.executeProgram(CliFrontend.java:746)
        at org.apache.flink.client.cli.CliFrontend.runProgram(CliFrontend.java:273)
        at org.apache.flink.client.cli.CliFrontend.run(CliFrontend.java:205)
        at org.apache.flink.client.cli.CliFrontend.parseParameters(CliFrontend.java:1010)
        at org.apache.flink.client.cli.CliFrontend.lambda$main$10(CliFrontend.java:1083)
        at org.apache.flink.runtime.security.NoOpSecurityContext.runSecured(NoOpSecurityContext.java:30)
        at org.apache.flink.client.cli.CliFrontend.main(CliFrontend.java:1083)
Caused by: java.lang.ClassNotFoundException: org.apache.flink.table.api.bridge.java.StreamTableEnvironment
        at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
        ... 23 more
(base) root@k8s-master1:/media/nizhengqi/7a646073-10bf-41e4-9

Flink or Spark Version
flnik 1.9
Java or Scala Version
java 8
Screenshots
Export JVM_ARGS: -Dexecution.parallelism=1
Execute SeaTunnel Flink Job: ${FLINK_HOME}/bin/flink run -c org.apache.seatunnel.core.flink.SeatunnelFlink /seatunnel/lib/seatunnel-core-flink.jar --config /seatunnel/config/application.conf
Starting execution of program
java.lang.NoClassDefFoundError: org/apache/flink/table/api/bridge/java/StreamTableEnvironment
at org.apache.seatunnel.flink.FlinkEnvironment.createStreamTableEnvironment(FlinkEnvironment.java:173)
at org.apache.seatunnel.flink.FlinkEnvironment.prepare(FlinkEnvironment.java:93)
at org.apache.seatunnel.flink.FlinkEnvironment.prepare(FlinkEnvironment.java:55)
at org.apache.seatunnel.core.base.config.EnvironmentFactory.getEnvironment(EnvironmentFactory.java:63)
at org.apache.seatunnel.core.base.config.AbstractExecutionContext.(AbstractExecutionContext.java:53)
at org.apache.seatunnel.core.flink.config.FlinkExecutionContext.(FlinkExecutionContext.java:48)
at org.apache.seatunnel.core.flink.command.FlinkApiTaskExecuteCommand.execute(FlinkApiTaskExecuteCommand.java:68)
at org.apache.seatunnel.core.base.Seatunnel.run(Seatunnel.java:40)
at org.apache.seatunnel.core.flink.SeatunnelFlink.main(SeatunnelFlink.java:34)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.apache.flink.client.program.PackagedProgram.callMainMethod(PackagedProgram.java:576)
at org.apache.flink.client.program.PackagedProgram.invokeInteractiveModeForExecution(PackagedProgram.java:438)
at org.apache.flink.client.program.ClusterClient.run(ClusterClient.java:274)
at org.apache.flink.client.cli.CliFrontend.executeProgram(CliFrontend.java:746)
at org.apache.flink.client.cli.CliFrontend.runProgram(CliFrontend.java:273)
at org.apache.flink.client.cli.CliFrontend.run(CliFrontend.java:205)
at org.apache.flink.client.cli.CliFrontend.parseParameters(CliFrontend.java:1010)
at org.apache.flink.client.cli.CliFrontend.lambda$main$10(CliFrontend.java:1083)
at org.apache.flink.runtime.security.NoOpSecurityContext.runSecured(NoOpSecurityContext.java:30)
at org.apache.flink.client.cli.CliFrontend.main(CliFrontend.java:1083)
Caused by: java.lang.ClassNotFoundException: org.apache.flink.table.api.bridge.java.StreamTableEnvironment
at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
... 23 more
(base) root@k8s-master1:/media/nizhengqi/7a646073-10bf-41e4-9
Are you willing to submit PR?

[X] Yes I am willing to submit a PR!

Code of Conduct

[X] I agree to follow this project's Code of Conduct

What is the version of Flink?

What is the version of Flink?

1.9

For V1 connectors, Flink 1.13+ is supported For V2 connectors, Flink 1.12+ is supported

repo: apache/incubator-seatunnel


text:
when using binding-table,error occurred

My application.properties is :
spring.shardingsphere.sharding.binding-tables=t_order,t_order_item
It's error :
Caused by: java.lang.NullPointerException
	at org.apache.shardingsphere.core.rule.ShardingRule.isBroadcastTable(ShardingRule.java:292)
	at org.apache.shardingsphere.core.rule.ShardingRule.getTableRule(ShardingRule.java:186)
	at org.apache.shardingsphere.core.rule.ShardingRule.createBindingTableRule(ShardingRule.java:114)
	at org.apache.shardingsphere.core.rule.ShardingRule.createBindingTableRules(ShardingRule.java:106)
	at org.apache.shardingsphere.core.rule.ShardingRule.<init>(ShardingRule.java:81)
	at org.apache.shardingsphere.shardingjdbc.api.ShardingDataSourceFactory.createDataSource(ShardingDataSourceFactory.java:50)
	at org.apache.shardingsphere.shardingjdbc.spring.boot.SpringBootConfiguration.shardingDataSource(SpringBootConfiguration.java:96)
	at org.apache.shardingsphere.shardingjdbc.spring.boot.SpringBootConfiguration$$EnhancerBySpringCGLIB$$eb1f0297.CGLIB$shardingDataSource$1(<generated>)
	at org.apache.shardingsphere.shardingjdbc.spring.boot.SpringBootConfiguration$$EnhancerBySpringCGLIB$$eb1f0297$$FastClassBySpringCGLIB$$348b8c97.invoke(<generated>)
	at org.springframework.cglib.proxy.MethodProxy.invokeSuper(MethodProxy.java:244)

In method isBroadcastTable, broadcastTables is null. Please use Assert.notNull().
Additional,change position of bindingTableRules and broadcastTables  In ShardingRule construct method.
public ShardingRule(final ShardingRuleConfiguration shardingRuleConfig, final Collection<String> dataSourceNames) {
        Preconditions.checkArgument(null != shardingRuleConfig, "ShardingRuleConfig cannot be null.");
        Preconditions.checkArgument(null != dataSourceNames && !dataSourceNames.isEmpty(), "Data sources cannot be empty.");
        this.ruleConfiguration = shardingRuleConfig;
        shardingDataSourceNames = new ShardingDataSourceNames(shardingRuleConfig, dataSourceNames);
        tableRules = createTableRules(shardingRuleConfig);
        **bindingTableRules** = createBindingTableRules(shardingRuleConfig.getBindingTableGroups());
        **broadcastTables** = shardingRuleConfig.getBroadcastTables();
        defaultDatabaseShardingStrategy = createDefaultShardingStrategy(shardingRuleConfig.getDefaultDatabaseShardingStrategyConfig());
        defaultTableShardingStrategy = createDefaultShardingStrategy(shardingRuleConfig.getDefaultTableShardingStrategyConfig());
        defaultShardingKeyGenerator = createDefaultKeyGenerator(shardingRuleConfig.getDefaultKeyGeneratorConfig());
        masterSlaveRules = createMasterSlaveRules(shardingRuleConfig.getMasterSlaveRuleConfigs());
        encryptRule = createEncryptRule(shardingRuleConfig.getEncryptRuleConfig());
    }

What is your version?

What is your version?

org.apache.shardingsphere
sharding-jdbc-spring-boot-starter
4.0.0-RC2

@liubo-tech you can see the same problem in issues#2917
and the bug has been fixed in 4.0.0-RC3-SNAPSHOT
you can also see pr#2918

authors: Pramy liubo-tech terrymanu

repo: apache/incubator-shardingsphere


text:
#2592, sharding-proxing change database error

Fixes #2592.

Pull Request Test Coverage Report for Build 8614

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 61.25%

Totals

Change from base Build 8612:
0.0%

Covered Lines:
8518

Relevant Lines:
13907

💛  - Coveralls


text:
Refactor metadata

Changes proposed in this pull request:

Decouple DatabaseType.getDataSourceMetaData() and customized object.
Reuse DatabaseAccessConfiguration and remove DataSourceInfo.
Make SQLExecuteCallback.CACHED_DATASOURCE_METADATA for thread safe.

/run ci

Pull Request Test Coverage Report for Build 1003

28 of 42 (66.67%)  changed or added relevant lines in 26 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.02%) to 68.932%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

sharding-core/sharding-core-common/src/main/java/org/apache/shardingsphere/core/metadata/datasource/dialect/MariaDBDataSourceMetaData.java
0
1
0.0%

sharding-core/sharding-core-common/src/main/java/org/apache/shardingsphere/spi/database/H2DatabaseType.java
0
1
0.0%

sharding-core/sharding-core-common/src/main/java/org/apache/shardingsphere/spi/database/MariaDBDatabaseType.java
0
1
0.0%

sharding-core/sharding-core-common/src/main/java/org/apache/shardingsphere/spi/database/OracleDatabaseType.java
0
1
0.0%

sharding-core/sharding-core-common/src/main/java/org/apache/shardingsphere/spi/database/PostgreSQLDatabaseType.java
0
1
0.0%

sharding-core/sharding-core-common/src/main/java/org/apache/shardingsphere/spi/database/SQL92DatabaseType.java
0
1
0.0%

sharding-core/sharding-core-common/src/main/java/org/apache/shardingsphere/spi/database/SQLServerDatabaseType.java
0
1
0.0%

sharding-proxy/sharding-proxy-backend/src/main/java/org/apache/shardingsphere/shardingproxy/backend/schema/impl/EncryptSchema.java
0
1
0.0%

sharding-proxy/sharding-proxy-backend/src/main/java/org/apache/shardingsphere/shardingproxy/backend/schema/impl/MasterSlaveSchema.java
0
1
0.0%

sharding-proxy/sharding-proxy-backend/src/main/java/org/apache/shardingsphere/shardingproxy/backend/schema/impl/ShardingSchema.java
0
1
0.0%

Totals

Change from base Build 575:
0.02%

Covered Lines:
11697

Relevant Lines:
16969

💛  - Coveralls

authors: coveralls terrymanu tristaZero


text:
[ISSUE #1700] Add shenyu-src-dist

For #1700

Codecov Report

Merging #1773 (8c86a6c) into master (02ef6a2) will decrease coverage by 0.54%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##             master    #1773      +/-   ##
============================================
- Coverage     62.57%   62.03%   -0.55%
+ Complexity     2392     2378      -14
============================================
  Files           482      482
  Lines         10318    10318
  Branches       1043     1043
============================================
- Hits           6457     6401      -56
- Misses         3347     3403      +56
  Partials        514      514

Impacted Files
Coverage Δ

...enyu/client/tars/TarsServiceBeanPostProcessor.java
25.67% <0.00%> (-33.79%)
:arrow_down:

...ache/shenyu/plugin/grpc/cache/GrpcClientCache.java
66.66% <0.00%> (-27.78%)
:arrow_down:

...henyu/plugin/grpc/resolver/ShenyuNameResolver.java
52.63% <0.00%> (-10.53%)
:arrow_down:

...che/shenyu/sync/data/http/HttpSyncDataService.java
63.10% <0.00%> (-8.74%)
:arrow_down:

...java/org/apache/shenyu/common/utils/UUIDUtils.java
75.00% <0.00%> (-6.25%)
:arrow_down:

...he/shenyu/plugin/grpc/client/ShenyuGrpcClient.java
8.51% <0.00%> (-4.26%)
:arrow_down:

...henyu/plugin/httpclient/NettyHttpClientPlugin.java
57.14% <0.00%> (-2.05%)
:arrow_down:

...t/zookeeper/ZookeeperClientRegisterRepository.java
70.90% <0.00%> (-1.82%)
:arrow_down:

...elimiter/handler/RateLimiterPluginDataHandler.java
69.69% <0.00%> (-1.52%)
:arrow_down:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 02ef6a2...8c86a6c. Read the comment docs.

repo: apache/incubator-shenyu


text:
SINGA-136 Support cuDNN v4

cudnn_convolution.cc: Add cudnn Vesrion Macro
Support cuDNN V4

SINGA-136 Support cuDNN v4

repo: apache/incubator-singa


text:
resolves STREAMS-313 #313

neo4j runtime dependencies are scope:provided and optional
using the existing Http-based writer does not require neo4j libraries
using the Binary writer does, but it's up to the implementing stream to import it

I believe the dependency issue is resolved.
I will lazy consensus merge this in 48 hours.

repo: apache/incubator-streams


text:
[dashboard][Add chart] Chart list is out of order

How to reproduce the bug

Go to a Dashboard
Click on Edit
Open Charts tab
see chart list: charts are not sorted by recent change, it's really hard to find one if you have a lot of charts.

Expected results
chart list should be sorted by most recent change, which is similar to the behavior in the landing page Charts section.
Actual results
hard to tell what is the order
Screenshots

Environment
latest master

superset version: superset version
python version: python --version
node.js version: node -v

Checklist
Make sure to follow these steps before submitting your issue - thank you!

[x] I have checked the superset logs for python stacktraces and included it here as text if there are any.
[x] I have reproduced the issue with at least the latest released version of superset.
[x] I have checked the issue tracker for the same issue and I haven't found one similar.

Additional context
related to #11336 @nytai

Hi @nytai I have to re-open this issue:
the order of charts from API response is correct, but not rendered correctly in the dashboard side-panel:

Note: the Modified time in slice card also disappeared... this explains why order is still broken in the UI.

Hi @nytai this issue is still broken in master branch, it's been 2 weeks. cc @junlincc

repo: apache/incubator-superset


text:
chore: Bump superset-ui deps

SUMMARY
Bump superset-ui deps in order to fix https://github.com/apache/incubator-superset/issues/12266
BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

TEST PLAN

ADDITIONAL INFORMATION

[x] Has associated issue: https://github.com/apache/incubator-superset/issues/12266
[ ] Changes UI
[ ] Requires DB Migration.
[ ] Confirm DB Migration upgrade and downgrade tested.
[ ] Introduces new feature or API
[ ] Removes existing feature or API
CC: @villebro @junlincc

rushing this PR, as it associate with the custom sql filter issue.

rushing this PR, as it associate with the custom sql filter issue.

Codecov Report

Merging #12280 (e49fc57) into master (d4a854e) will decrease coverage by 16.21%.
The diff coverage is n/a.

@@             Coverage Diff             @@
##           master   #12280       +/-   ##
===========================================
- Coverage   67.17%   50.96%   -16.22%
===========================================
  Files        1002      466      -536
  Lines       49231    16757    -32474
  Branches     5000     4301      -699
===========================================
- Hits        33073     8540    -24533
+ Misses      16035     8217     -7818
+ Partials      123        0      -123

Flag
Coverage Δ

cypress
50.96% <ø> (-0.44%)
:arrow_down:

javascript
?

python
?

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

...uperset-frontend/src/dashboard/util/dnd-reorder.js
0.00% <0.00%> (-100.00%)
:arrow_down:

...rset-frontend/src/dashboard/util/getEmptyLayout.js
0.00% <0.00%> (-100.00%)
:arrow_down:

...dashboard/components/resizable/ResizableHandle.jsx
0.00% <0.00%> (-100.00%)
:arrow_down:

.../src/dashboard/util/getFilterScopeFromNodesTree.js
0.00% <0.00%> (-93.48%)
:arrow_down:

...set-frontend/src/views/CRUD/alert/ExecutionLog.tsx
11.76% <0.00%> (-88.24%)
:arrow_down:

...src/dashboard/components/gridComponents/Header.jsx
10.52% <0.00%> (-86.85%)
:arrow_down:

superset-frontend/src/components/IconTooltip.tsx
13.33% <0.00%> (-86.67%)
:arrow_down:

...rc/dashboard/components/gridComponents/Divider.jsx
13.33% <0.00%> (-86.67%)
:arrow_down:

...end/src/SqlLab/components/ExploreResultsButton.jsx
8.00% <0.00%> (-84.00%)
:arrow_down:

...nd/src/views/CRUD/data/query/QueryPreviewModal.tsx
14.70% <0.00%> (-82.97%)
:arrow_down:

... and 857 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 673dea7...e49fc57. Read the comment docs.

Codecov Report

Merging #12280 (e49fc57) into master (d4a854e) will decrease coverage by 16.21%.
The diff coverage is n/a.

@@             Coverage Diff             @@
##           master   #12280       +/-   ##
===========================================
- Coverage   67.17%   50.96%   -16.22%
===========================================
  Files        1002      466      -536
  Lines       49231    16757    -32474
  Branches     5000     4301      -699
===========================================
- Hits        33073     8540    -24533
+ Misses      16035     8217     -7818
+ Partials      123        0      -123

Flag
Coverage Δ

cypress
50.96% <ø> (-0.44%)
:arrow_down:

javascript
?

python
?

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

...uperset-frontend/src/dashboard/util/dnd-reorder.js
0.00% <0.00%> (-100.00%)
:arrow_down:

...rset-frontend/src/dashboard/util/getEmptyLayout.js
0.00% <0.00%> (-100.00%)
:arrow_down:

...dashboard/components/resizable/ResizableHandle.jsx
0.00% <0.00%> (-100.00%)
:arrow_down:

.../src/dashboard/util/getFilterScopeFromNodesTree.js
0.00% <0.00%> (-93.48%)
:arrow_down:

...set-frontend/src/views/CRUD/alert/ExecutionLog.tsx
11.76% <0.00%> (-88.24%)
:arrow_down:

...src/dashboard/components/gridComponents/Header.jsx
10.52% <0.00%> (-86.85%)
:arrow_down:

superset-frontend/src/components/IconTooltip.tsx
13.33% <0.00%> (-86.67%)
:arrow_down:

...rc/dashboard/components/gridComponents/Divider.jsx
13.33% <0.00%> (-86.67%)
:arrow_down:

...end/src/SqlLab/components/ExploreResultsButton.jsx
8.00% <0.00%> (-84.00%)
:arrow_down:

...nd/src/views/CRUD/data/query/QueryPreviewModal.tsx
14.70% <0.00%> (-82.97%)
:arrow_down:

... and 857 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 673dea7...e49fc57. Read the comment docs.

authors: codecov-io junlincc kgabryje


text:
Remove Token and ParseException, refactor to DMLParseException

Deleted Token and ParseException classes. Changed all ParseException references to DMLParseException.
@mboehm7 The only real change in code functionality is in DMLParseException, where newMsg code was replaced my msg code. Please let me know if this looks OK or needs to be changed and if other code updates are needed.
Tests completed successfully here.

Sorry, I found an issue with this. The generated error message isn't properly displayed. I will investigate. Perhaps I should create a test too to test for an expected error message.

OK, problem exists because I folded ParseException and DMLParseException together but "public ParseException(String message)" and "public DMLParseException(String fname)" are not equivalent. Need to think more about this...

Upon further examination, ParseException is used for purposes besides DML parsing (for example, parsing DMLConfig, merging configs, wrapper for FileNotFoundException and IOException, etc). Some of these should not be converted to DMLParseExceptions because they don't have to do with parsing DML. Perhaps I can remove the Token class but not fold ParseException and DMLParseException together.

@deroneriksson I still believe it would be useful to merge these exceptions. The instances of ParseException that are not related to parsing could be replaced with LanguageException.

repo: apache/incubator-systemml


text:
prevents DB update error when using older syncds versions with reval pending…

When updating the status page with use_reval_pending enabled and an older version of ORT, we are attempting to push a null value to the DB.  This fixes that.

is this addressing this error? [2017-05-08 23:31:17,160] [ERROR] DBIx::Class::Storage::DBI::_dbh_execute(): DBI Exception: DBD::Pg::st execute failed: ERROR:  null value in column "reval_pending" violates not-null constraint

Yes.

repo: apache/incubator-trafficcontrol


text:
[Relay][VM][Interpreter] Enable first-class constructors in VM and interpreter via eta expansion

Previously, the VM and interpreter did not support constructors as first-class objects.  For example, the following code snippet would not compile:
def @main[A]() -> (fn(A, List[A]) -> List[A]) {
  Cons
}

.  The eta expansion pass in this PR remedies this problem by wrapping the constructor in a function, like so:
def @main[A]() -> (fn(A, List[A]) -> List[A]) {
  fn (%x: A, %xs: List[A]) -> List[A] {
    Cons(%x, %xs)
  }
}

.  There was an existing eta expansion pass, but it was not recursive and only operated on global variables.  The new pass is configurable, so you can choose to expand constructors, global variables, or both.
Also included are the following minor changes:

Fix LambdaLift pass so it closes over free type variables.
Fix LambdaLift pass so it reuses lifted functions that are alpha equal.
Fix pretty printing of constructors to be context-sensitive (e.g., print Cons(A, List[A]) in a type definition but only print Cons when in an expr).
Rename Module::HasDef to Module::ContainGlobalTypeVar to match the analogous Module::ContainGlobalVar method.
Change prelude definitions to use first-class constructors where applicable.

CC @jroesch @MarisaKirisame @icemelon9

@jroesch @icemelon9 CI is green.  Take a look when you get a chance.

It looks like the tests are timing out.  I think this addition to the interpreter is the cause.  Might need to roll back that change and the change to the prelude, but keep the EtaExpand functionality for the VM.  If we want first-class constructors in the interpreter, we'll need to directly support it there.

nvm. there seem to be CI timeouts repo-wide (https://discuss.tvm.ai/t/remove-unused-function-in-relay-module/4753)

@icemelon9 CI is green again

Thanks @weberlo @MarisaKirisame. This is now merged.

repo: apache/incubator-tvm


text:
插件市场为什么没有了

为什么没有插件市场了 ，打不开了 https://market.weex-project.io/
不维护了吗？
想找插件不知道上哪找去
:joy: :joy: :joy: :joy:

That's just a static page to list what plugins Weex has, and this requirement could be supported by the official website of Weex.
We are working the new website of Weex now, it could be release at early 2019. By that time, community developers are able to share their experence and plugins on it, you can also check what plugin is available.

good ！

This is by far weex's largest plug-in market https://www.jianshu.com/p/1fa669f94f55

repo: apache/incubator-weex


text:
[YUNIKORN-478]Handle app completion at the shim side

Delete pod when receive ReleaseAllocation response, and delete application from context when receive UpdatedApplication response.
Please review @yangwwei
Thanks.

hi @HuangTing-Yao  there is some issue here. First, we need to update go.mod file in order to use the latest binary from scheduler-interface repo, where we get the new UpdateResponse#AllocationRelease. And one more thing I forgot to mention, from the doc:
 // Released allocations, this could be either ack from scheduler when RM asks to terminate some allocations.
  // Or it could be decision made by scheduler (such as preemption or timeout).
  repeated AllocationRelease releasedAllocations = 3;

we need to handle this differently based on the different TERMINATION_TYPE,
 enum TerminationType {
    STOPPED_BY_RM = 0;          // Stopped or killed by ResourceManager (created by RM)
    TIMEOUT = 1;                // Timed out based on the executionTimeoutMilliSeconds (created by core)
    PREEMPTED_BY_SCHEDULER = 2; // Preempted allocation by scheduler (created by core)
    PLACEHOLDER_REPLACED = 3;   // Placeholder allocation replaced by real allocation (created by core)
  }

if STOPPED_BY_RM,  there is no operation needed in the shim side (today's behavior)
if otherwise i.e TIMEOUT, PREEMPTED_BY_SCHEDULER or PLACEHOLDER_REPLACED, we will need to trigger the pod delete.

hi @HuangTing-Yao  any updates? If you have more questions, pls let me know. Thanks

hi @HuangTing-Yao any updates? If you have more questions, pls let me know. Thanks

almost done, I will upload new version today.

authors: HuangTing-Yao yangwwei


text:
We don't need SSL and certificate for videos!

Trying to fix the certificate issue we have with OFBiz demos

This is not going to fly when you leave 'RedirectMatch permanent ^/(.*)$ https://ofbiz-vm2.apache.org/$1' in place.

Right Pierre, it's indeed useless now. I'll fix that!

It was working, right?
So now we don't have a secure path to ofbiz-vm2.apache.org, a letsencrypt config that is not going to be used...

The whole was not working as reported at OFBIZ-9206 and INFRA-11960. So I try to make the setup as simple as possible. For instance we don't need a certificate to shows static files (videos and such). If you have better ideas please share...

It is working. See https://ofbiz-vm2.apache.org/FrameworkIntro/
I wonder why we would go through all this trouble to correct a working setup. I recommend to leave it as is.

The only part that is not working is the backend OFBiz demos (see earlier mentioned JIRA issues), which is due to OFBiz demo specific setups. The letsencrypt and httpd configs work as intended,  see:
https://demo-old.ofbiz.apache.org/catalog/control/main
https://demo-stable.ofbiz.apache.org/catalog/control/main
https://demo-trunk.ofbiz.apache.org/catalog/control/main

Right, I also tried from there https://cwiki.apache.org/confluence/display/OFBIZ/Framework+Introduction+Videos+and+Diagrams. I'll remove my change it's useless.
The pb is indeed that OFBiz is adding the port 8443. I'll check why the demos are doing that.

authors: JacquesLeRoux PierreSmits

repo: apache/infrastructure-puppet