text:
Testing Improvements

* Support for running :tests:testSystemBasic as part of `helm test`.

* Enable running tests:testSystemBasic for DockerContainerFactory
  configurations (ping test still fails with KubernetesContainerFactory
  because need to fix upstream to drop CAP_NET_ADMIN on user action pod).

* Change error handling strategy in myTask.sh to being mostly
  explicit to get better control and allow retries of commands
  that might be vulnerable to CouchDB's eventual consistiency.

* Remove obsolete script for starting minikube in TravisCI

* Push openwhisk core git tag forward 2 commits to pick up fix
  for org.apache package rename in tests:testSystemBasic.

* Separate chart deployment and testing into separate scripts
  because we need to use travis_wait when running helm tests,
  but we want to be able to eagerly see the output of the deploy
  step to enable early aborts of the test run when it gets hung.

Fixes #127.

This is finally working reliably.....I've caught my 🐋
Doubles the wall clock time for testing a PR to about 30 minutes, but running the system tests against the kube deploy is worth adding the time.

repo: apache/incubator-openwhisk-deploy-kube


text:
prioritize_critical_css loads css twice

Version: 1.13.35.2-0
Configuration:
pagespeed on;
pagespeed FileCachePath /dev/shm/ngx_pagespeed_cache;
pagespeed Statistics on;
pagespeed StatisticsLogging on;
pagespeed LogDir /var/log/pagespeed;
pagespeed MemcachedServers "127.0.0.1:11211";
pagespeed EnableCachePurge on;
pagespeed PreserveUrlRelativity on;
pagespeed InPlaceResourceOptimization off;
pagespeed InPlaceSMaxAgeSec 604800;
pagespeed ModifyCachingHeaders off;
pagespeed FetchHttps enable;
pagespeed CssInlineMaxBytes 4096;
pagespeed JsInlineMaxBytes 16384;
pagespeed ImageRecompressionQuality 70;
pagespeed WebpRecompressionQuality 70;
pagespeed WebpRecompressionQualityForSmallScreens 60;
pagespeed RewriteLevel CoreFilters;
pagespeed EnableFilters prioritize_critical_css,inline_javascript,resize_images,resize_mobile_images,remove_comments,collapse_whitespace,insert_dns_prefetch,hint_preload_subresources,recompress_images;

I noticed the CSS files were loaded twice, which means the prioritize_critical_css did not remove the original  tags.

but the 2 times css files are loaded are rewrited by pagespeed? aka have url like full-url-css-file.pagespeed.some-hash.css

Hmm No.

Could it be that you are observing browser prefetching of the original css?

I'm looking at the source code. Also Inspector indicates duplicate CSS rules exist.

prioritize_critical_css works removing the css file link, change it by a css snipet (those used above the fold) and then puy a javascript snipet at the bottom of the page wirh an onload event to load the rewrited css files.
You are viewing 2 css files both w/o any rewrite by pagespeed?
I ask for that because maybe you have a preload hint in the http headers, not in the code. In this case, the browser load these files 2 times, 1 not rewrited by pagespeed (cause pagespeed don´t rewrite link headers) and 1 more time because the css (rewrited by pagespeed) is loaded in the code.
These 2 files are different because in the header link is the original (https://yoursite.com/some-path/file.css) and in the html code  the file is loaded with a different url ( https://yoursite.com/some-path/file.css.ce.pagespeed.HASHCHAIN.css).
Can you share a url to test?

https://winterco.org
^^
I'm pretty sure I see the original stylesheet links.

Is there some form is html caching going on?
I'm curious what happens when cloudflare is taken out of the equation.

Well... you have allmost 2 big things to look in it:
The site has headers to preload some things, so when the html is rewrited by pagespeed you have 2 diferent files with the same content, 1 loaded by the header and other loaded by the html code. These preload headers can come from Cloudflare.

When the 2 files are the same, is loaded only 1 time but in chrome dev tools network tab in the initiator column you can see is loaded by "other"

The other thing to look is Cloudflare. Cloudflare is a proxy-cache approach to do CDN work. This mean that the only User Agent that hit the real server is the UA used by Cloudflare, so some optimizations from pagespeed are missed because it are UA dependent.
You need to configure Cloudflare in a way that the real UA from the final user hit the real server and headers from the real server go to the final user.
For example, in the html request (hhtps://winterco.org) pagespeed set a cache-control header max-age=0, no-cache, this header forbid to store the html in any cache, why? cause the html can be, or not, rewrited by pagespeed.
As a first step to make it work, you can put Cloudflare in by-pass mode, so the request from final users can to to the real server, once you got the server with pagespeed working well, the you enable Clodflare and face the issues that introduces.
If I remember, Cloudflare can be set to respect original headers.

Is there some form is html caching going on?
I'm curious what happens when cloudflare is taken out of the equation.

Yes, some html cache is done. The html is served with cache-control: max-age=3600, must-revalidate

Negative. No cloudflare this time:
root@localhost ~ # curl -vv --insecure --resolve "winterco.org:443:127.0.0.1" https://winterco.org
* Expire in 0 ms for 6 (transfer 0x55d944151f50)
* Added winterco.org:443:127.0.0.1 to DNS cache
* Hostname winterco.org was found in DNS cache
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x55d944151f50)
* Connected to winterco.org (127.0.0.1) port 443 (#0)
...(garbage)...
> GET / HTTP/2
> Host: winterco.org
> User-Agent: curl/7.64.0
> Accept: */*
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
< HTTP/2 200
< server: nginx
< date: Thu, 16 Jul 2020 09:40:51 GMT
< content-type: text/html; charset=UTF-8
< cache-control: max-age=3600, must-revalidate
< vary: Accept-Encoding, Cookie
< hummingbird-cache: Served
< x-content-type-options: nosniff
< x-xss-protection: 1; mode=block;
< x-powered-by: ASP.NET
< x-aspnet-version: 2.0.50727
< x-aspnetmvc-version: 2.0
< x-recruiting: Like hacking? Join us: winterco.org/careers
< x-page-speed: 1.13.35.2-0
< link: </wp-content/themes/creativeily-winterco-mod/style.css?ver=5.4.2>; rel=preload; as=style; nopush
< link: </wp-content/uploads/bws-custom-code/bws-custom-code.css?ver=5.4.2>; rel=preload; as=style; nopush
< link: </wp-content/themes/creativeily-winterco-mod/assets/js/creativeily.js?ver=5.4.2>; rel=preload; as=script; nopush
< link: </wp-content/themes/creativeily-winterco-mod/assets/js/accessibility.js?ver=5.4.2>; rel=preload; as=script; nopush
< link: </wp-includes/js/wp-embed.min.js?ver=5.4.2>; rel=preload; as=script; nopush
<
<!DOCTYPE html>

<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<link rel="profile" href="http://gmpg.org/xfn/11">
<title>凛冬华人联盟 – Winter Coalition</title>
<link rel='dns-prefetch' href='//www.googletagmanager.com'/>
<link rel='dns-prefetch' href='//fonts.googleapis.com'/>
<link rel='dns-prefetch' href='//cdn.jsdelivr.net'/>
<link rel='dns-prefetch' href='//recaptcha.net'/>
<link rel='dns-prefetch' href='//fonts.gstatic.com'/>
<link rel='dns-prefetch' href='//ajax.googleapis.com'/>
<link rel='dns-prefetch' href='//google-analytics.com'/>
<link rel='dns-prefetch' href='//www.google-analytics.com'/>
<link rel='dns-prefetch' href='//ssl.google-analytics.com'/>
<link rel="alternate" type="application/rss+xml" title="凛冬华人联盟 » Feed" href="https://winterco.org/feed/"/>
<link rel="alternate" type="application/rss+xml" title="凛冬华人联盟 » 评论Feed" href="https://winterco.org/comments/feed/"/>
<link rel='stylesheet' id='wp-block-library-css' href='https://cdn.jsdelivr.net/gh/WordPress/WordPress@5.4.2/wp-includes/css/dist/block-library/style.min.css?ver=5.4.2' type='text/css' media='all'/>
<link rel='stylesheet' id='comment_styles-css' href='https://cdn.jsdelivr.net/wp/plugins/wp-discourse/tags/2.0.6/lib/../css/comments.min.css?ver=1594583367' type='text/css' media='all'/>
<link rel='stylesheet' id='creativeily-google-fonts-css' href='https://fonts.googleapis.com/css2?family=Roboto%3Aital%2Cwght%400%2C400%3B0%2C500%3B0%2C700%3B0%2C900%3B1%2C400%3B1%2C500&display=swap&ver=5.4.2' type='text/css' media='all'/>
<link rel='stylesheet' id='dashicons-css' href='https://cdn.jsdelivr.net/gh/WordPress/WordPress@5.4.2/wp-includes/css/dashicons.min.css?ver=5.4.2' type='text/css' media='all'/>
<link rel='stylesheet' id='creativeily-style-css' href='https://winterco.org/wp-content/themes/creativeily-winterco-mod/style.css?ver=5.4.2' type='text/css' media='all'/>
<link rel='stylesheet' id='bws-custom-style-css' href='https://winterco.org/wp-content/uploads/bws-custom-code/bws-custom-code.css?ver=5.4.2' type='text/css' media='all'/>

<link rel='https://api.w.org/' href='https://winterco.org/wp-json/'/>
<link rel="EditURI" type="application/rsd+xml" title="RSD" href="https://winterco.org/xmlrpc.php?rsd"/>
<link rel="wlwmanifest" type="application/wlwmanifest+xml" href="https://winterco.org/wp-includes/wlwmanifest.xml"/>
<meta name="generator" content="WordPress 5.4.2"/>
<meta name="generator" content="Site Kit by Google 1.11.1"/>

<link rel="icon" href="https://winterco.org/wp-content/uploads/2020/07/cropped-11355daf357ecd7cd74ad2c64b3de3e4b15ba35c-32x32.png" sizes="32x32"/>
<link rel="icon" href="https://winterco.org/wp-content/uploads/2020/07/cropped-11355daf357ecd7cd74ad2c64b3de3e4b15ba35c-192x192.png" sizes="192x192"/>
<link rel="apple-touch-icon" href="https://winterco.org/wp-content/uploads/2020/07/cropped-11355daf357ecd7cd74ad2c64b3de3e4b15ba35c-180x180.png"/>
<meta name="msapplication-TileImage" content="https://winterco.org/wp-content/uploads/2020/07/cropped-11355daf357ecd7cd74ad2c64b3de3e4b15ba35c-270x270.png"/>

Skip to content

...(garbage)...

<link rel='stylesheet' id='wp-block-library-css' href='https://cdn.jsdelivr.net/gh/WordPress/WordPress@5.4.2/wp-includes/css/dist/block-library/style.min.css?ver=5.4.2' type='text/css' media='all'/><link rel='stylesheet' id='comment_styles-css' href='https://cdn.jsdelivr.net/wp/plugins/wp-discourse/tags/2.0.6/lib/../css/comments.min.css?ver=1594583367' type='text/css' media='all'/><link rel='stylesheet' id='creativeily-google-fonts-css' href='https://fonts.googleapis.com/css2?family=Roboto%3Aital%2Cwght%400%2C400%3B0%2C500%3B0%2C700%3B0%2C900%3B1%2C400%3B1%2C500&display=swap&ver=5.4.2' type='text/css' media='all'/><link rel='stylesheet' id='dashicons-css' href='https://cdn.jsdelivr.net/gh/WordPress/WordPress@5.4.2/wp-includes/css/dashicons.min.css?ver=5.4.2' type='text/css' media='all'/><link rel='stylesheet' id='creativeily-style-css' href='https://winterco.org/wp-content/themes/creativeily-winterco-mod/style.css?ver=5.4.2' type='text/css' media='all'/><link rel='stylesheet' id='bws-custom-style-css' href='https://winterco.org/wp-content/uploads/bws-custom-code/bws-custom-code.css?ver=5.4.2' type='text/css' media='all'/>

* Connection #0 to host winterco.org left intact

The Cache-Control on the header is likely provided by Hummingbird, a plugin of WordPress and it does not interfere with PageSpeed.
These Link header are provided by hint_preload_subresources I believe.

Note that there is two set of <link>, one in  and the other in . Also  got repeated. DevTools says:

though I have totally no idea why they are all tagged as
    <link rel="stylesheet" href="small.css">

      Hello, world!

And the resource small.css is like this:
  .yellow {background-color: yellow;}
  .big { font-size: 8em; }
  .bold { font-weight: bold; }

We expect PageSpeed to rewrite it into:

      Hello, world!

<link rel="stylesheet" href="small.css">

However, now we are getting this instead:

    <link rel="stylesheet" href="small.css">

      Hello, world!

<link rel="stylesheet" href="small.css">

As far I can see your site is working, pagespeed does their job, css files are loaded once, css abobe the fold is inlined in the html....
And yes, some css rules are set twice, 1 time in the inlined css and 1 more time in the css files.

And using a browser, so Cloudflare is here.

So why is it link css files multiple times? I understand that it extracts a few rules in

source: gharchive/issue

authors: Lofesa oschaaf wfjsw

repo: apache/incubator-pagespeed-ngx

license_type: permissive

license_source: github-api


text:
Update install-sourcecode.html.md.erb

minor typo with 'following'.

Thanks for catching!

source: gharchive/pull-request

repo: apache/incubator-predictionio


text:
MybatisPlus的基类insert方法不能回滚数据

问题如下：
seata（1.30和1.42版本都有）安装配置工作正常后，经测试发现，mybatis-plus 的 BaseMapper 类里的 insert 方法，如果在插入数据时，不指定主键id，会导致插入的数据无法回滚。同时更新的数据是能正常回滚的。
具体测试类看下图的那行注释：
    public void insertOrder(int userId, int goodsId, String goods, int count) {         GoodsOrder goodsOrder = new GoodsOrder();         // goodsOrder.setId(101);   // 必须指定主键id，否则插入的记录不能回滚         goodsOrder.setUserId(userId);         goodsOrder.setGoodsId(goodsId);         goodsOrder.setGoods(goods);         goodsOrder.setCount(count);         goodsOrderMapper.insert(goodsOrder);     }
这是插入后不能回滚的数据证据：
触发回滚：
There was an unexpected error (type=Internal Server Error, status=500). [500] during [GET] to [http://BATIS-SEATA-FEIGN-STOCK/stock/update_stock?goodsId=56&count=101] [StockFeignService#insertOrUpdateStock(int,int)]: [{"timestamp":"2022-04-19T12:54:21.572+0000","status":500,"error":"Internal Server Error","message":"库存下限错误","path":"/stock/update_stock"}]
数据没被回滚，还在：
107	398	56	北欧沙发	101
如下操作可以正常回滚：

如果给实体实例设定id=101（即把该行注释去掉）
或者如果使用 mapper.xml 里的原生SQL语句

问题描述完了，
期待你的回复！谢谢哈！

请提供有效日志证明无法回滚

我也遇到上面的问题，没有指定主键的id时根本不走MySQLUndoLogManager中的insertUndoLog方法

请提供一下驱动版本

我是在整合tkmybatis的时候不插入undo_log。。。

的确存在这个问题。
mybatis-plus 在处理自增不指定id插入时，默认使用0让数据库自己处理。
不清楚是否这个原因？
各位有简单一点的解决方案吗（不改表id自增的情况）？

authors: SoloAlien a364176773 caisf caohdgege ftdmao iloveleeyan

repo: apache/incubator-seata


text:
[Improvement][Config] Print config in origin order

Purpose of this pull request
close #1473
Check list

[ ] Code changed are covered with tests, or it does not need tests for reason:
[ ] If any new Jar binary package adding in you PR, please add License Notice according
New License Guide
[ ] If necessary, please update the documentation to describe the new feature. https://github.com/apache/incubator-seatunnel/tree/dev/docs

you need to add reference to this :
https://github.com/apache/incubator-seatunnel/blob/159eb8423c99f21f951abe1a37753bafa206c4dc/LICENSE#L216

Thanks for your reminder, I added this announces, please help to take a look.

I find many code improve in this PR, It's great to do code improve, If not much we can just use one PR . If code improve change too much, I suggest split it into two PR next time. It's good for code review and PR check. Thanks

@CalvinKirs LGTM

authors: BenJFan ruanwenjun

repo: apache/incubator-seatunnel


text:
[Feature][Connector-V2] Add mongodb connecter sink

Purpose of this pull request

Check list

[x] Code changed are covered with tests, or it does not need tests for reason:
[ ] If any new Jar binary package adding in your PR, please add License Notice according
New License Guide
[x] If necessary, please update the documentation to describe the new feature. https://github.com/apache/incubator-seatunnel/tree/dev/docs

add spark e2e-testcase?

add spark e2e-testcase?

OK, thank you for your reminder. I'll add it later


text:
Refactor and enhance sharding-scaling-core

[ ] Refactor SyncExecutor to SyncExecuteEngine
[ ] Refactor DataSyncTask
[ ] Implement SyncTaskProgress
[ ] Use Callback to report completed sync task

I am working on task one, assignees this to me?

repo: apache/incubator-shardingsphere

license_source: bigquery


text:
Make merge module and execute module independent

Fixes #1864.

Pull Request Test Coverage Report for Build 7170

0 of 9 (0.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.001%) to 20.069%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

sharding-jdbc/sharding-jdbc-core/src/main/java/org/apache/shardingsphere/shardingjdbc/jdbc/core/statement/EncryptPreparedStatement.java
0
9
0.0%

Totals

Change from base Build 7169:
-0.001%

Covered Lines:
8170

Relevant Lines:
40709

💛  - Coveralls

authors: coveralls tristaZero


text:
Fix 4782.

Fixes https://github.com/apache/incubator-shardingsphere/issues/4782

Pull Request Test Coverage Report for Build 10317

0 of 0   changed or added relevant lines in 0 files are covered.
3 unchanged lines in 1 file lost coverage.
Overall coverage decreased (-0.005%) to 59.861%

Files with Coverage Reduction
New Missed Lines
%

sharding-orchestration/sharding-orchestration-core/sharding-orchestration-core-registrycenter/src/main/java/org/apache/shardingsphere/orchestration/core/registrycenter/util/IpUtils.java
3
76.0%

Totals

Change from base Build 1096:
-0.005%

Covered Lines:
12545

Relevant Lines:
20957

💛  - Coveralls


text:
[Question] shenyu-admin

Question
When I restart admin, the original configuration will be lost，why is this？

could you please detail your question, with version, snapshot, procedure and so on, many thanks.

Set spring.profiles.active=mysql, then try it again.

could you please detail your question, with version, snapshot, procedure and so on, many thanks.

could you please detail your question, with version, snapshot, procedure and so on, many thanks.

Set spring.profiles.active=mysql, then try it again.

ok, get it,many thinks

done

authors: AhahaGe KevinClair chariles midnight2104

repo: apache/incubator-shenyu


text:
Fix #1441 add icon files notice

Please answer these questions before submitting pull request

Why submit this pull request?

[x] Bug fix

[ ] New feature provided

[ ] Improve performance

Related issues

Fix #1441

We should not add the ASF License header to the iconfont.svg if the file is just copied from dant.

Yes. @WillemJiang already removed it at UI repository and submodule updated.

authors: WillemJiang hanahmily wu-sheng

repo: apache/incubator-skywalking


text:
[Bug] mvn package failed

Search before asking

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

What happened
git clone code then chose dev branch,open it with idea,then run mvn clean install -Dscala.version=2.11.12 -Dscala.binary.version=2.11 -DskipTests ,then something wrong happens
[ERROR] ## Exception when compiling 61 sources to D:\code\incubator-streampark\streampark-common\target\classes
java.lang.NoSuchMethodError: org.fusesource.jansi.AnsiConsole.wrapOutputStream(Ljava/io/OutputStream;)Ljava/io/OutputStream;
jline.AnsiWindowsTerminal.detectAnsiSupport(AnsiWindowsTerminal.java:57)
jline.AnsiWindowsTerminal.(AnsiWindowsTerminal.java:27)
sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
java.lang.reflect.Constructor.newInstance(Constructor.java:423)
java.lang.Class.newInstance(Class.java:442)
jline.TerminalFactory.getFlavor(TerminalFactory.java:205)
jline.TerminalFactory.create(TerminalFactory.java:96)
jline.TerminalFactory.get(TerminalFactory.java:180)
jline.TerminalFactory.get(TerminalFactory.java:186)
sbt.internal.util.ConsoleAppender$.ansiSupported(ConsoleAppender.scala:292)
sbt.internal.util.ConsoleAppender$.useColorDefault$1(ConsoleAppender.scala:127)
sbt.internal.util.ConsoleAppender$.$anonfun$formatEnabledInEnv$4(ConsoleAppender.scala:143)
scala.runtime.java8.JFunction0$mcZ$sp.apply(JFunction0$mcZ$sp.java:23)
scala.Option.getOrElse(Option.scala:138)
sbt.internal.util.ConsoleAppender$.(ConsoleAppender.scala:143)
sbt.internal.util.ConsoleAppender$.(ConsoleAppender.scala)
sbt.internal.inc.MixedAnalyzingCompiler.compile(MixedAnalyzingCompiler.scala:150)
sbt.internal.inc.IncrementalCompilerImpl.$anonfun$compileInternal$1(IncrementalCompilerImpl.scala:343)
sbt.internal.inc.IncrementalCompilerImpl.$anonfun$compileInternal$1$adapted(IncrementalCompilerImpl.scala:343)
sbt.internal.inc.Incremental$.doCompile(Incremental.scala:120)
sbt.internal.inc.Incremental$.$anonfun$compile$4(Incremental.scala:100)
sbt.internal.inc.IncrementalCommon.recompileClasses(IncrementalCommon.scala:180)
sbt.internal.inc.IncrementalCommon.cycle(IncrementalCommon.scala:98)
sbt.internal.inc.Incremental$.$anonfun$compile$3(Incremental.scala:102)
sbt.internal.inc.Incremental$.manageClassfiles(Incremental.scala:155)
sbt.internal.inc.Incremental$.compile(Incremental.scala:92)
sbt.internal.inc.IncrementalCompile$.apply(Compile.scala:75)
sbt.internal.inc.IncrementalCompilerImpl.compileInternal(IncrementalCompilerImpl.scala:348)
sbt.internal.inc.IncrementalCompilerImpl.$anonfun$compileIncrementally$1(IncrementalCompilerImpl.scala:301)
sbt.internal.inc.IncrementalCompilerImpl.handleCompilationError(IncrementalCompilerImpl.scala:168)
sbt.internal.inc.IncrementalCompilerImpl.compileIncrementally(IncrementalCompilerImpl.scala:248)
sbt.internal.inc.IncrementalCompilerImpl.compile(IncrementalCompilerImpl.scala:74)
sbt_inc.SbtIncrementalCompiler.compile(SbtIncrementalCompiler.java:173)
scala_maven.ScalaCompilerSupport.incrementalCompile(ScalaCompilerSupport.java:297)
scala_maven.ScalaCompilerSupport.compile(ScalaCompilerSupport.java:109)
scala_maven.ScalaCompilerSupport.doExecute(ScalaCompilerSupport.java:91)
scala_maven.ScalaMojoSupport.execute(ScalaMojoSupport.java:554)
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
org.apache.maven.lifecycle.internal.MojoExecutor.doExecute(MojoExecutor.java:301)
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:211)
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:165)
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:157)
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:121)
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56)
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:127)
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:294)
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192)
org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105)
org.apache.maven.cli.MavenCli.execute(MavenCli.java:960)
org.apache.maven.cli.MavenCli.doMain(MavenCli.java:293)
org.apache.maven.cli.MavenCli.main(MavenCli.java:196)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
java.lang.reflect.Method.invoke(Method.java:498)
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:282)
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225)
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406)
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347)
StreamPark Version
git clone the latest code
Java Version
1.8
Flink Version
unkown
Scala Version of Flink
2.11.12
Error Exception
[ERROR] ## Exception when compiling 61 sources to D:\code\incubator-streampark\streampark-common\target\classes
java.lang.NoSuchMethodError: org.fusesource.jansi.AnsiConsole.wrapOutputStream(Ljava/io/OutputStream;)Ljava/io/OutputStream;
jline.AnsiWindowsTerminal.detectAnsiSupport(AnsiWindowsTerminal.java:57)
jline.AnsiWindowsTerminal.<init>(AnsiWindowsTerminal.java:27)
sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
java.lang.reflect.Constructor.newInstance(Constructor.java:423)
java.lang.Class.newInstance(Class.java:442)
jline.TerminalFactory.getFlavor(TerminalFactory.java:205)
jline.TerminalFactory.create(TerminalFactory.java:96)
jline.TerminalFactory.get(TerminalFactory.java:180)
jline.TerminalFactory.get(TerminalFactory.java:186)
sbt.internal.util.ConsoleAppender$.ansiSupported(ConsoleAppender.scala:292)
sbt.internal.util.ConsoleAppender$.useColorDefault$1(ConsoleAppender.scala:127)
sbt.internal.util.ConsoleAppender$.$anonfun$formatEnabledInEnv$4(ConsoleAppender.scala:143)
scala.runtime.java8.JFunction0$mcZ$sp.apply(JFunction0$mcZ$sp.java:23)
scala.Option.getOrElse(Option.scala:138)
sbt.internal.util.ConsoleAppender$.<init>(ConsoleAppender.scala:143)
sbt.internal.util.ConsoleAppender$.<clinit>(ConsoleAppender.scala)
sbt.internal.inc.MixedAnalyzingCompiler.compile(MixedAnalyzingCompiler.scala:150)
sbt.internal.inc.IncrementalCompilerImpl.$anonfun$compileInternal$1(IncrementalCompilerImpl.scala:343)
sbt.internal.inc.IncrementalCompilerImpl.$anonfun$compileInternal$1$adapted(IncrementalCompilerImpl.scala:343)
sbt.internal.inc.Incremental$.doCompile(Incremental.scala:120)
sbt.internal.inc.Incremental$.$anonfun$compile$4(Incremental.scala:100)
sbt.internal.inc.IncrementalCommon.recompileClasses(IncrementalCommon.scala:180)
sbt.internal.inc.IncrementalCommon.cycle(IncrementalCommon.scala:98)
sbt.internal.inc.Incremental$.$anonfun$compile$3(Incremental.scala:102)
sbt.internal.inc.Incremental$.manageClassfiles(Incremental.scala:155)
sbt.internal.inc.Incremental$.compile(Incremental.scala:92)
sbt.internal.inc.IncrementalCompile$.apply(Compile.scala:75)
sbt.internal.inc.IncrementalCompilerImpl.compileInternal(IncrementalCompilerImpl.scala:348)
sbt.internal.inc.IncrementalCompilerImpl.$anonfun$compileIncrementally$1(IncrementalCompilerImpl.scala:301)
sbt.internal.inc.IncrementalCompilerImpl.handleCompilationError(IncrementalCompilerImpl.scala:168)
sbt.internal.inc.IncrementalCompilerImpl.compileIncrementally(IncrementalCompilerImpl.scala:248)
sbt.internal.inc.IncrementalCompilerImpl.compile(IncrementalCompilerImpl.scala:74)
sbt_inc.SbtIncrementalCompiler.compile(SbtIncrementalCompiler.java:173)
scala_maven.ScalaCompilerSupport.incrementalCompile(ScalaCompilerSupport.java:297)
scala_maven.ScalaCompilerSupport.compile(ScalaCompilerSupport.java:109)
scala_maven.ScalaCompilerSupport.doExecute(ScalaCompilerSupport.java:91)
scala_maven.ScalaMojoSupport.execute(ScalaMojoSupport.java:554)
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
org.apache.maven.lifecycle.internal.MojoExecutor.doExecute(MojoExecutor.java:301)
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:211)
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:165)
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:157)
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:121)
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56)
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:127)
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:294)
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192)
org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105)
org.apache.maven.cli.MavenCli.execute(MavenCli.java:960)
org.apache.maven.cli.MavenCli.doMain(MavenCli.java:293)
org.apache.maven.cli.MavenCli.main(MavenCli.java:196)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
java.lang.reflect.Method.invoke(Method.java:498)
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:282)
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225)
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406)
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347)

Screenshots
No response
Are you willing to submit PR?

[ ] Yes I am willing to submit a PR!

Code of Conduct

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

bug fixed

repo: apache/incubator-streampark


text:
[fix] Adding time grains to Table

CATEGORY
Choose one

[x] Bug Fix
[ ] Enhancement (new features, refinement)
[ ] Refactor
[ ] Add tests
[ ] Build / Development Environment
[ ] Documentation

SUMMARY
This PR re-adds the time grain controls back to the Table visualization type as this is needed by the include_time control. Note this is the only visualization type which uses this control (per here).
BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

TEST PLAN
CI.
ADDITIONAL INFORMATION

[ ] Has associated issue:
[ ] Changes UI
[ ] Requires DB Migration.
[ ] Confirm DB Migration upgrade and downgrade tested.
[ ] Introduces new feature or API
[ ] Removes existing feature or API

REVIEWERS
to: @etr2460

Codecov Report

Merging #8825 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #8825   +/-   ##
=======================================
  Coverage   65.88%   65.88%
=======================================
  Files         483      483
  Lines       24178    24178
  Branches     2778     2778
=======================================
  Hits        15930    15930
  Misses       8070     8070
  Partials      178      178

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 ec43609...db85432. Read the comment docs.

authors: codecov-io john-bodley

repo: apache/incubator-superset


text:
[fix] Fix table viz column order

CATEGORY
Choose one

[x] Bug Fix
[ ] Enhancement (new features, refinement)
[ ] Refactor
[ ] Add tests
[ ] Build / Development Environment
[ ] Documentation

SUMMARY
This PR fixes a couple of issues related to the table visualization type. Originally the intent was to ensure that the table column orders adhered to the UI. The PR somewhat morphed to contain:

Updated the validity matrix to ensure that defining percent metrics is not viable when NOT GROUPED BY columns are defined.
Replaced outdated Python filter/maps with list comprehensions and Pandas column operators.
Ensure that the resulting data frame is ordered according to group-by or non-group-by column, metrics, and percent metrics.

BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

TEST PLAN
CI and manual testing.
ADDITIONAL INFORMATION

[ ] Has associated issue:
[ ] Changes UI
[ ] Requires DB Migration.
[ ] Confirm DB Migration upgrade and downgrade tested.
[ ] Introduces new feature or API
[ ] Removes existing feature or API

REVIEWERS
to: @michellethomas @mistercrunch @villebro

Codecov Report

Merging #9122 into master will decrease coverage by <.01%.
The diff coverage is n/a.

@@            Coverage Diff            @@
##           master   #9122      +/-   ##
=========================================
- Coverage    59.1%   59.1%   -0.01%
=========================================
  Files         372     372
  Lines       11920   11922       +2
  Branches     2917    2919       +2
=========================================
+ Hits         7045    7046       +1
- Misses       4693    4694       +1
  Partials      182     182

Impacted Files
Coverage Δ

superset-frontend/src/chart/chartAction.js
43.33% <0%> (+0.09%)
:arrow_up:

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 2913063...a05bafd. Read the comment docs.


text:
[TOPI] Update softmax compute and CPU schedule

This change improves performance for softmax by simplifying the computation and writing a schedule that supports better parallelization.
Compute: Currently, exp(input - max) is computed twice: once in the _compute_expsum stage and once in the _normalize stage. This change adds an extra stage to compute this tensor once. It is then re-used in the _compute_expsum and _normalize stages.
Schedule: Currently, the schedule only parallelizes the _normalize stage of the computation. This change puts all stages of computation under a common root and parallelizes the outer dimensions.
The following results are with a tensor of shape (1,12,128,128) and axis=-1. This simulates the softmax in BERT base. The CPU is Intel Xeon E5-2650, and the Relay target string is llvm -mcpu=core-avx2.

TVM_NUM_THREADS
Latency in ms (master branch)
Latency in ms (new branch)

1
4.7
3.0

2
3.8
1.8

4
3.3
1.0

8
3.1
0.74

16
3.2
0.55

@kevinthesun @vinx13 can you please review and add any other reviewers you think are necessary?

Thank you @soiferj , can you check the CI problem?

Yeah, I'm taking a look at the CI failure now. It seems to be an issue in the CUDA schedule. I will work on it.

The CI issue is fixed.

@kevinthesun feel free to merge the PR given you are managing it

Thank you for contributing!

Another suggestion - https://discuss.tvm.ai/t/softmax-sequence-of-relay-ops/5686

authors: anijain2305 kevinthesun soiferj tqchen

repo: apache/incubator-tvm


text:
[FOLLOWUP] fix: don't recreate base dir if it's already existed

What changes were proposed in this pull request?
optimize the base dir init logic, it now skips recreate base dir if it's already an dir
Why are the changes needed?
handles some corner cases such as the base dir is an mount point root path.
Does this PR introduce any user-facing change? rss shuffle server can use mounted path as base dir directly.
How was this patch tested?
Existing UTs.

Codecov Report

Merging #622 (bc7f285) into branch-0.7 (7f9b561) will increase coverage by 2.30%.
The diff coverage is 100.00%.

@@               Coverage Diff                @@
##             branch-0.7     #622      +/-   ##
================================================
+ Coverage         60.87%   63.17%   +2.30%
+ Complexity         1801     1797       -4
================================================
  Files               214      200      -14
  Lines             12387    10409    -1978
  Branches           1044     1041       -3
================================================
- Hits               7540     6576     -964
+ Misses             4443     3490     -953
+ Partials            404      343      -61

Impacted Files
Coverage Δ

...rg/apache/uniffle/storage/common/LocalStorage.java
51.31% <100.00%> (+2.25%)
:arrow_up:

...e/uniffle/server/storage/SingleStorageManager.java
70.58% <0.00%> (-2.95%)
:arrow_down:

deploy/kubernetes/operator/pkg/utils/rss.go

deploy/kubernetes/operator/pkg/webhook/manager.go

...y/kubernetes/operator/pkg/webhook/inspector/pod.go

...eploy/kubernetes/operator/pkg/utils/coordinator.go

...oy/kubernetes/operator/pkg/utils/shufflerserver.go

...oy/kubernetes/operator/pkg/controller/util/util.go

deploy/kubernetes/operator/pkg/utils/util.go

...bernetes/operator/pkg/controller/controller/rss.go

... and 7 more

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

authors: advancedxy codecov-commenter

repo: apache/incubator-uniffle


text:
Class  common's problem

I use <style src="assets/common.styl" lang="stylus"/>  require class, want class shared，but no good, becasue I view the build dist file, these class all repeat, is not one module pack in.

We will merge 0.11-dev to master when v0.11 released. So this PR will not proceed currently. Thank you.

authors: nicefan sospartan

repo: apache/incubator-weex


text:
[android] android targetSdkVersion 29 ashmem issue

As Google Play warn all apps need update targetSdkVersion to 29 before 2020.10, We must handle this issue, https://github.com/apache/incubator-weex/issues/2706

Successful self-test

Just judging the api level is a problem with Android R.Should judge target sdk version and api level together.
if (g_targetSDKInt >= 29 && device_api_level() == 29)

As Google Play warn all apps need update targetSdkVersion to 29 before 2020.10, We must handle this issue, #2706

Successful self-test

大佬，修改了c文件后要如何打包呢？

targetSdkVersion29的问题解决了吗？我用后面c文件修改后的重新打包aar还是不行

Now that google play has started to execute, can we accelerate the completion of this matter?

targetSdkVersion29的问题解决了吗？我们着急提交包啊，不支持29不让提包

成功的自检

现在项目着急上线，我怎么操作来实现，或者给我联系方式来提问

我用后面c文件修改后的重新打包aar还是不行

targetSdkVersion29的问题解决了吗？我用后面c文件修改后的重新打包aar还是不行

同样不行

成功的自测

确定成功了吗？大佬


text:
[INLONG-7508][Sort] Carry right RowKind when cdc-base sends RowData to sink

Prepare a Pull Request
(Change the title refer to the following example)

Title Example: [INLONG-XYZ][Component] Title of the pull request

(The following XYZ should be replaced by the actual GitHub Issue number)

Fixes #7508

Motivation
Explain here the context, and why you're making that change. What is the problem you're trying to solve?
cdc-base sends RowData to sink, should carry right RowKind

Modifications
Describe the modifications you've done.
AppendMetadataCollector make a new GenericRowData instance, should pass right RowKind.
Verifying this change
(Please pick either of the following options)

[ ] This change is a trivial rework/code cleanup without any test coverage.

[ ] This change is already covered by existing tests, such as:
(please describe tests)

[ ] This change added tests and can be verified as follows:
(example:)

Added integration tests for end-to-end deployment with large payloads (10MB)
Extended integration test for recovery after broker failure

Documentation

Does this pull request introduce a new feature? (yes / no)
If yes, how is the feature documented? (not applicable / docs / JavaDocs / not documented)
If a feature is not applicable for documentation, explain why?
If a feature is not documented yet in this PR, please create a follow-up issue for adding the documentation

Now sink parse rowkind from data when all database migration. So rowkind use INSERT.

Source database has a update operation,  cdc send update type in json data.  Sink connector cannot known whether is Update_Before or Update_After.
The 3rd screenshot shows that sink connector always get update before node null from json data.

When source table has a update operation, cdc send update type in json data. Sink connector cannot known whether is Update_Before or Update_After.
The 3rd screenshot shows that sink connector always get updateBeforeNode null from json data.

@liaorui @EMsnap have a PR issue this problem. https://github.com/apache/inlong/issues/7397

The opType in allmigrate is represented as the parameter TYPE in canal json. maybe you can get the optype from there

Close this PR since PR #7397 has solved this problem.

authors: EMsnap gong liaorui

repo: apache/inlong


text:
[IOTDB-3179] Printing logs when get/getOrCreate Partition in ConfigNode

Currently, we don't know what PartitionTable that ConfigNode returns to DataNode, which is not conducive to development debug. So I have temporarily added logs for getSchemaPartition getOrCreateSchemaPartition getDataPartition, getOrCreateDataPartition  interfaces.

Why not check out a new branch.

authors: CRZbulabula chinausers

repo: apache/iotdb


text:
OAK-9790 - Implement parallel indexing for speeding up oak run indexing command

OAK-9790 - Implement parallel indexing for speeding up oak run indexing command

Since indexing was single threads, which is slow for large repository. In order to improve the indexing performance we need to implement parallel indexing.
The work is cover for both lucene and elastic indexing. In order to support parallel indexing, it need to split the big flat file store file ahead, which add a big overhead, but make parallel index possible and much faster.
Another change together is support the LZ4 compression since which is much faster compare to gzip.

New PR which incorporates the review comments https://github.com/apache/jackrabbit-oak/pull/715

superseded by PR https://github.com/apache/jackrabbit-oak/pull/715

authors: Ewocker amit-jain

repo: apache/jackrabbit-oak


text:
OAK-9966 : Internal code calls Node.isCheckedOut and VersionManager.isCheckedOut

hi @joerghoh , @mreutegg , @reschke , @Joscorbe , i would highly appreciate if you could take a careful look at this PR for the version-mgt implementation.

as outlined in the ticket the implementation calling JCR API (and by doing so resolving the node again) is suboptiomal..... so the goal was to get rid of all JCR calls that create another operation-object inside a JCR call and avoid resolving the node again.
the check for the tree.existing in ReadOnlyVersionManager is IMHO redundant (and not relevant. i added an additional line in the comment illustrating how it could be fixed if really needed and added a test illustrating the mismatch that we had/have. i verified that the test both passed before and after my change)

please pay attention to the following subtle changes and let me know if you see any issue with that:

ItemImpl.getVersionManager no longer calls JCR API on Workspace but the internal variant that returns the impl and does not perform a check if the session is still alive. that is handled in preconditions of the individual JCR calls)
all internal checks for the node being checkedout should now call the internal method taking a nodedelegate without creating a separate operation object

@mreutegg, i haven't seen org.apache.jackrabbit.oak.plugins.document.VersionGCWithSplitTest failing when i ran the build locally. does that sound like being related to my patch?

i haven't seen org.apache.jackrabbit.oak.plugins.document.VersionGCWithSplitTest failing when i ran the build locally. does that sound like being related to my patch?

The test failure is most likely unrelated.

@reschke ..... uuuuhhhhh thanks..... not sure it is justified :-)

authors: anchela mreutegg


text:
KAFKA-12561: don't set timeout for future.get

These tests failed quite often, because of TimeoutException. We cannot get the future result in time. I think the flaky tests tell us that we should not expect the results will return as soon as we expected in jenkins. Like other tests, we don't usually set timeout when future.get, so remove the timeout setting to make this test reliable.
Committer Checklist (excluded from commit message)

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation (including upgrade notes)

@mumrah , @hachikuji , could you review this PR? It failed a lot in recent builds. Thanks.

@mumrah , @hachikuji , could you review this PR? It keeps failing recent builds. Thanks.

@showuon Could you merge trunk to trigger QA again? I'd like to merge it if QA pass :)

kafka.server.ListOffsetsRequestTest.testResponseIncludesLeaderEpoch() is traced by #10389 and ConnectionQuotasTest.testListenerConnectionRateLimitWhenActualRateAboveLimit is unrelated flaky. will merge to trunk

@showuon thanks for this fix!

repo: apache/kafka


text:
KAFKA-13192: Prevent inconsistent broker.id/node.id values

If both broker.id and node.id are set, and they are set inconsistently (e.g.broker.id=0, node.id=1) then currently the value of node.id is used and the broker.id value is left at the original value. The server should detect this inconsistency, throw a ConfigException, and fail to start.  This patch adds the check and a test for it.
Committer Checklist (excluded from commit message)

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation (including upgrade notes)

This PR is likely going to be replaced by https://github.com/apache/kafka/pull/11256.  Will probably eventually close this assuming that other PR gets merged.


text:
MINOR: Reduce log levels for transactions_mixed_versions_test with 3.2 due to bug in that version

https://github.com/apache/kafka/commit/7496e6243410ca851f4b8502270cf4222bd89a2b fixed an error that caused an exception to be thrown on broker startup when debug logs were on. This made it to every version except 3.2.
The Kraft upgrade tests totally turn off debug logs, but I think we only need to remove them for the broken version.

I have not seen it on other versions. I thought I ran the tests, but looks like I didn't. I will update the PR when I see the results.

I ran the transactions_upgrade_test without any changes and everything passed.
I ran the mixed_version_test but due to https://issues.apache.org/jira/browse/KAFKA-17250 :(

I ran the mixed_version_test but it is failing due to https://issues.apache.org/jira/browse/KAFKA-17250 :(

@jolshan Could you please take a look at my previous comment: https://github.com/apache/kafka/pull/16235#discussion_r1672760435?

Looks like the other PR is merged. I will try rerunning the tests now

All the tests pass now. We don't need for 3.1 since it doesn't have this line (I traced back all the components of delta and it eventually gets to a BrokerRegistration):
3.2:
https://github.com/apache/kafka/blob/e4ca066680296ea29d443efb626baecc837083f6/core/src/main/scala/kafka/server/metadata/BrokerMetadataListener.scala#L274
3.1:
https://github.com/apache/kafka/blob/2b57b38f9306ac73f18d94d55c0158530fd444df/core/src/main/scala/kafka/server/metadata/BrokerMetadataListener.scala#L254

I will backport this to 3.9 for consistency before backporting #17067


text:
KAFKA-9846: Filter active tasks for running state in KafkaStreams#allLocalStorePartitionLags()

Added check that only treats running active tasks as having 0 lag
Tasks that are neither restoring, nor running will report 0 as currentoffset position
Fixed LagFetchIntegrationTest to wait till thread/instance reaches RUNNING before checking lag

Committer Checklist (excluded from commit message)

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation (including upgrade notes)

test this please

@guozhangwang So, I still need to add a test case around this specific scenario, tasks stuck in created state.. Seems it needs some engineering to create that scenario. (sophie gave me some pointers, yet to try them)..
if we need to just fix the test issue, I can open a simpler one with just the test fix.. That's probably better?

Opened a simple backport here #8534.. We can focus on that for fixing the test flakiness itself.

Opened a simple backport here #8534.. We can focus on that for fixing the test flakiness itself.

Sounds good, thanks!

Closing this PR as outdated.

authors: guozhangwang mjsax vinothchandar


text:
KAFKA-9885; Evict last members of a group when the maximum allowed is reached

This PR updates the algorithm which limits the number of members within a group (group.max.size) to fix the following two issues:

As described in KAFKA-9885, we found out that multiple members of a group can be evicted if the leader of the consumer offset partition changes before the group is persisted. This happens because the current evection logic always evict the first member rejoining the group.
We also found out that dynamic members, when required to have a known member id, are not always limited. The caveat is that the current logic only considers unknown members and uses the group size, which does not include the so called pending members, to accept or reject a member. In this case, when they rejoins, they are not unknown member anymore and thus could bypass the limit. See testDynamicMembersJoinGroupWithMaxSizeAndRequiredKnownMember for the whole scenario.

This PR extends the tests coverage to cover all the member types.
Committer Checklist (excluded from commit message)

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation (including upgrade notes)

cc @hachikuji @abbccdda

Related to #8437.

ok to test

authors: dajac hachikuji


text:
Fix the envKey in Config.java

fix #10

@iskey can you add a test to validate please?

Thanks, let me take a look.

@iskey can you add a test to validate please?

ok, let me do some tests.

Better to do a mock test. Post two snapshots for contrast for now:
from
to

Sounds good!

If possible try avoiding a mock please, it is like not testing at all at the end.
Using surefire you can force some env var so it is then easy to check it is used or not cases IMHO.

I think we don't need a mock for the test. We can directly test the ConfigService and setting a system property to test.
Actually, I think for this kind of "simple" bug, we can just move forward without test.

If no objection, I will merge this PR.

Guess the regex should be extracted if config service is used at runtime instead of recompiled each time.

@rmannibucau good point, we can have the Pattern compile as static.

@jbonofre agree, no mock is needed, go for merge.

Agree, no mock here. Actually, it is hard to mock without extracting the getEnv as another method.
Let me make the pattern static.

authors: fpapon iskey jbonofre rmannibucau

repo: apache/karaf-minho


text:
18098: KUDU-3197 [tserver] optimal Schema's memory used, using std::s…

create the pr, just for code-review

Thanks for your contribution!
Please submit code review on gerrit, see: https://kudu.apache.org/docs/contributing.html#_contributing_patches_using_gerrit
For draft, you can open a pull request on your own repo.

repo: apache/kudu


text:
Add support of hash field expiration

Search before asking

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

Motivation
Refer to https://github.com/redis/redis/pull/13172, Redis has supported this feature.
Solution
TBD
Are you willing to submit a PR?

[ ] I'm willing to submit a PR!

I'll do this, and will propose a solution later.

This feature was add in Redis 7.4 RC

@git-hulk Hi, I have done some work on this feature before. May i submit a pr for this?

@jjz921024 Thank you!

repo: apache/kvrocks


text:
Fix missing migrating/importing information in the CLUSTER NODES command

In Redis, it will add the migrating/importing slot section
for the source and target node. For the migrating source node,
it will contain the below section:
[{slot_id}->-{target_node_id}]

And for the importing node, it will add:
[{slot_id}-<-{source_node_id}]

In this PR, I also removed the unused import_fd_ field in the imported.


text:
Add index selection pass for KQIR planning

We add a simple index selection algorithm upon KQIR planning part based on a simple cost model.
Also, we introduce range-v3 since it's essential for modern C++ and is a part of C++20.
TODO:

[x] more tests

Ready for review now : )


text:
Bump Iceberg from 1.1.0 to 1.2.0

Why are the changes needed?

Iceberg 1.2.0 release notes: https://iceberg.apache.org/releases/#120-release

How was this patch tested?

[ ] Add some test cases that check the changes thoroughly including negative and positive cases if possible

[ ] Add screenshots for manual tests if appropriate

[x] Run test locally before make a pull request

Will defer this PR until Iceberg announces release notes and changes of 1.2.0 on its official website.

Thanks, merged to master

repo: apache/kyuubi


text:
[feate] Added support for postgresql based on dev-1.4.0

What is the purpose of the change

Added postgresql support for linkis metadata.

Related issues/PRs

Related issues: #4190

Brief change log

Modify MybatisConfigurationFactory.java for support multiple data sources.
Modify linkis-cg-linkismanager.properties, linkis-mg-gateway.properties and linkis-cg-linkismanager.properties  for support multiple data sources.
To better distinguish between different data sources, change the original mapper file path. For example, move resources/mapper/common/contextHistoryMapper.xml to resources/mapper/common/mysql/contextHistoryMapper.xml
Add mapper files for postgresql. For example, resources/mapper/common/postgresql/contextHistoryMapper.xml
Some test classes were added or modified.

How to use postgresql

pom.xml

remove test in postgresql's dependency.

linkis.properties

Add database connection informations.
Add linkis.server.mybatis.pagehelper.dialect=postgresql. The configuration detault value is mysql.

linkis-cg-linkismanager.properties, linkis-mg-gateway.properties and linkis-cg-linkismanager.properties

Select mapper files that postgresql can execute.

If you want to use postgresql in test classes, You should change the properties used by the test class.

Add database connection informations.
Select mapper files that postgresql can execute.
Note: Please use the existing postgresql database to test.

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
[ x] I have explained the changes or the new features added to this PR
[ x] I have added tests corresponding to this change
[ x] I have updated the documentation to reflect this change
[ x] I have verified that this change is backward compatible (If not, please discuss on the Linkis mailing list first)
[ x] If this is a code change: I have written unit tests to fully verify the new behavior.

Please resolve the conflict

ping @peacewong

authors: aiceflower jackxu2011 sjgllgh

repo: apache/linkis


text:
Can we decrease the overhead of skipping?

Description
On top-k queries, Lucene is now competitive with Tantivy/PISA on https://tantivy-search.github.io/bench/, but it's still quite slower on counting queries. This made me want to run a similar experiment as https://github.com/Tony-X/search-benchmark-game/issues/44, though with a few more changes to how skipping works:

Single level of skip lists.
Skip data and impacts are inlined between blocks of postings.
Less overhead:

no separate SkipReader abstraction that gets lazily instantiated: the skipping logic is more lightweight and within the postings/impacts enum logic,
checking whether to skip and decode a new block is now a single check on BlockDocsEnum while it requires two different checks today.

A hacky implementation of this can be found at https://github.com/apache/lucene/compare/main...jpountz:lucene:skip_experiment?expand=1:

It doesn't replace existings skip data, just adds additional skip data and impacts inlined between blocks.
Only BlockDocsEnum and BlockImpactsDocsEnum switched to this new skip data, other impls still use existing skip data. So term queries will see a change, but not phrase queries.

It's quite naive, we could probably do something that is a bit more efficient. Yet results on wikibigall are interesting:
                            TaskQPS baseline      StdDevQPS my_modified_version      StdDev                Pct diff p-value
                    OrHighNotLow      327.87      (7.9%)      183.13      (5.4%)  -44.1% ( -53% -  -33%) 0.000
                    OrHighNotMed      374.44      (6.7%)      242.58      (5.0%)  -35.2% ( -43% -  -25%) 0.000
               HighTermMonthSort     4971.86      (1.6%)     3322.82      (1.1%)  -33.2% ( -35% -  -30%) 0.000
                        HighTerm      480.63      (6.5%)      343.22      (5.2%)  -28.6% ( -37% -  -18%) 0.000
                   OrHighNotHigh      226.71      (7.4%)      169.91      (6.2%)  -25.1% ( -36% -  -12%) 0.000
                         MedTerm      705.95      (5.8%)      617.27      (5.1%)  -12.6% ( -22% -   -1%) 0.000
                   OrNotHighHigh      183.15      (6.7%)      161.14      (6.3%)  -12.0% ( -23% -    1%) 0.000
                 CountOrHighHigh       56.83     (16.6%)       53.32     (10.5%)   -6.2% ( -28% -   25%) 0.160
                      OrHighHigh       73.45      (1.9%)       71.56      (1.3%)   -2.6% (  -5% -    0%) 0.000
                      TermDTSort      259.01      (4.1%)      253.64      (5.8%)   -2.1% ( -11% -    8%) 0.193
            HighTermTitleBDVSort       15.83      (6.0%)       15.60      (4.9%)   -1.4% ( -11% -   10%) 0.417
                     AndHighHigh       71.57      (2.2%)       70.60      (1.8%)   -1.4% (  -5% -    2%) 0.032
                       CountTerm    14081.51      (4.0%)    13918.96      (3.9%)   -1.2% (  -8% -    6%) 0.353
               HighTermTitleSort      112.66      (5.3%)      112.15      (2.4%)   -0.5% (  -7% -    7%) 0.724
                         Prefix3      340.35      (3.4%)      339.24      (2.9%)   -0.3% (  -6% -    6%) 0.745
                        Wildcard      106.77      (3.2%)      106.51      (3.5%)   -0.2% (  -6% -    6%) 0.824
                        PKLookup      282.16      (2.0%)      281.52      (1.3%)   -0.2% (  -3% -    3%) 0.667
                     LowSpanNear       13.84      (2.8%)       13.81      (2.6%)   -0.2% (  -5% -    5%) 0.839
                     CountPhrase        3.19      (8.0%)        3.19      (9.1%)   -0.1% ( -15% -   18%) 0.974
                      HighPhrase       29.89      (2.9%)       29.90      (4.7%)    0.0% (  -7% -    7%) 0.985
                     MedSpanNear        9.92      (2.3%)        9.93      (2.3%)    0.0% (  -4% -    4%) 0.952
                    HighSpanNear        5.37      (3.7%)        5.37      (3.4%)    0.1% (  -6% -    7%) 0.923
                         LowTerm     1154.36      (4.2%)     1155.62      (3.6%)    0.1% (  -7% -    8%) 0.930
                 MedSloppyPhrase       25.88      (2.7%)       25.93      (1.8%)    0.2% (  -4% -    4%) 0.789
                         Respell       59.03      (1.6%)       59.16      (1.6%)    0.2% (  -2% -    3%) 0.661
                       LowPhrase       48.93      (2.4%)       49.10      (4.7%)    0.4% (  -6% -    7%) 0.763
           HighTermDayOfYearSort      437.52      (1.2%)      440.03      (1.7%)    0.6% (  -2% -    3%) 0.227
                  CountOrHighMed      108.93     (11.3%)      109.65      (7.7%)    0.7% ( -16% -   22%) 0.830
                       MedPhrase       26.25      (2.6%)       26.44      (5.1%)    0.7% (  -6% -    8%) 0.580
                HighSloppyPhrase        6.35      (3.5%)        6.40      (2.1%)    0.8% (  -4% -    6%) 0.361
                          Fuzzy2       72.65      (1.1%)       73.27      (1.2%)    0.9% (  -1% -    3%) 0.022
                          Fuzzy1       90.62      (1.1%)       91.49      (1.2%)    1.0% (  -1% -    3%) 0.008
             LowIntervalsOrdered       15.56      (3.6%)       15.74      (3.4%)    1.2% (  -5% -    8%) 0.287
            HighIntervalsOrdered        3.05      (5.0%)        3.10      (5.0%)    1.6% (  -8% -   12%) 0.323
                 LowSloppyPhrase       18.12      (5.2%)       18.41      (2.3%)    1.6% (  -5% -    9%) 0.217
                       OrHighLow      658.61      (2.4%)      670.64      (1.9%)    1.8% (  -2% -    6%) 0.008
             MedIntervalsOrdered       18.21      (4.2%)       18.59      (3.7%)    2.1% (  -5% -   10%) 0.096
                    OrNotHighMed      337.44      (4.1%)      350.80      (4.5%)    4.0% (  -4% -   13%) 0.004
                       OrHighMed      147.53      (2.6%)      153.47      (2.1%)    4.0% (   0% -    8%) 0.000
                          IntNRQ      130.99     (21.2%)      139.01     (21.2%)    6.1% ( -29% -   61%) 0.360
                      AndHighMed      270.68      (2.4%)      291.75      (2.6%)    7.8% (   2% -   13%) 0.000
                      AndHighLow      903.88      (2.2%)     1000.22      (3.1%)   10.7% (   5% -   16%) 0.000
                    OrNotHighLow      793.34      (2.3%)      935.56      (2.1%)   17.9% (  13% -   22%) 0.000
                CountAndHighHigh       43.99      (2.1%)       51.94      (3.3%)   18.1% (  12% -   23%) 0.000
                 CountAndHighMed      129.42      (2.3%)      155.03      (3.4%)   19.8% (  13% -   26%) 0.000

CountAndHighHigh and CountAndHighMed became almost 20% faster! These are the main targets that I was targeting with this change, so it's good to see they are seeing a significant speedup. This confirms that we have some non-negligible overhead for skipping today though it's not easy to tell how much comes from the additional abstractions vs. multiple levels of skip lists.
OrNotHighLow and OrNotHighMed are faster. This is because the bottleneck of these queries is advancing the MUST_NOT clause, which are not scoring. So it's very similar to the speedup we're seeing on the counting queries.
AndHighLow and AndHighMed are 8%-11% faster. Again, I would attribute this to the faster skipping logic since this is about clauses that have different doc frequencies, so the higher frequency clause will need to do a lot of skipping to catch up with the leading clause. Interestingly, the fact that we are storing a single level of impact data doesn't hurt.
AndHighHigh and OrHighHigh are slightly slower (or is it noise?). I could believe that there is a small performance hit on this one due to having a single level of impact data. This forces Lucene to use the maximum score across the entire doc ID space as a score upper bound for the clause that has the higher cost. Maybe it could be enough to compute global impacts to have better performance on these queries by having slightly better score upper bounds for the following clause.
HighTerm, MedTerm, OrHighNotLow, OrHighNotMed, HighTerm, OrHighNotHigh, OrNotHighHigh are slower. This is expected as there are queries that have a single positive clause, which in-turn are queries where the score upper bounds that we compute are very close to the actual produced scores, which in-turn enables these queries to take advantage of the higher levels of impacts to skip more docs at once.
HighTermMonthSort is slower. This is because the sort dynamically introduces a filter that is so selective that the term query can take advantage of skip data on higher levels to skip more docs at once.
CountOrHighHigh is a bit slower because there's a bit more overhead to collect postings lists exhaustively now that skip data and impacts are inlined.
It's not a net win, but this suggests that we have some room for improvement here.

Whoa, very cool @jpountz!  This reminds me of this longstanding issue/paper which also inlined skip data directly in the postings, but maybe was still multi-level?

Fixed by https://github.com/apache/lucene/pull/13585

authors: jpountz mikemccand

repo: apache/lucene


text:
Replace new HashSet<>(Arrays.asList()) with EnumSet.of()

For sets with enum values EnumSet provides a more efficient implementation.
Besides, EnumSet.of() results in a shorter, easier to understand code than new HashSet<>(Arrays.asList()).

When backporting this to Lucene 9.x, it confliced because the sets have different contents in older version. I fixed this.
Nevertheless, the static final constants should be unmodifiable sets, so we should possibly use Java 9+ Set.of() instead of EnumSet.of()(which is modifiable) or wrap the EnumSet with Collections.unmodifiableSet().
Could you open an issue about this?

static final constants should be unmodifiable sets
Could you open an issue about this?

#13055


text:
METRON-1785 Automate deployment of packet capture for development environment

While trying to test #1201 , I fixed some issues with the Ansible install of the components required for testing packet capture.  I added instructions for how to do this in the README.
Testing

Spin-up the development environment and validate that alerts are visible in the Alerts UI and run the Metron Service Check in Ambari.

Follow the instruction in the README, to install and start all of the components for capturing packets.  Ensure that you can search and find these packets using the Alerts UI > PCAP tab.

Pull Request Checklist

[x] Is there a JIRA ticket associated with this PR? If not one needs to be created at Metron Jira.
[x] Does your PR title start with METRON-XXXX where XXXX is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character.
[x] Has your PR been rebased against the latest commit within the target branch (typically master)?
[x] Have you included steps to reproduce the behavior or problem that is being changed or addressed?
[x] Have you included steps or a guide to how the change may be verified and tested manually?
[x] Have you ensured that the full suite of tests and checks have been executed in the root metron folder via:
[x] Have you written or updated unit tests and or integration tests to verify your changes?
[x] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?
[x] Have you verified the basic functionality of the build by building and running locally with Vagrant full-dev environment or the equivalent?

Deployed a full dev , I executed set of instructions as in Docs
vagrant up vagrant --ansible-tags="pcap" provision
#Stopped the Parser, Enrichment, Indexing, and Profiler topologies to free-up resources.
vagrant ssh sudo su - source /etc/default/metron yum -y install wireshark
I see that the pcap-replay and pycapa services not deployed ..
[root@node1 ~]# service pcap-replay start
pcap-replay: unrecognized service
[root@node1 ~]# service pycapa start
pycapa: unrecognized service

Yes, you are right @MohanDV.  Somehow the default tags are interacting badly with the tags that are passed in.  I'll try to figure out what's going on.

authors: MohanDV nickwallen

repo: apache/metron


text:
rptun: remove notify_wait in remoteproc ops

Summary
remove notify_wait in remoteproc ops, rptun implements notify_wait through rpmsg_notify_wait_cb.
Impact
simplify code logic.
Testing
tested in sim vela.

@wyr8899 We should also modify nuttx/openamp/0004-openamp-add-new-ops-notify_wait-support.patch to pass CI.

repo: apache/nuttx


text:
HDDS-4624. Fix set configs in SCMHAConfigration

What changes were proposed in this pull request?
java.lang.IllegalArgumentException: Attempt to get double field "org.apache.hadoop.hdds.scm.ha.SCMHAConfiguration.raftSegmentSize" with illegal data type conversion to long

In reflection, seems that a Double Field cannot be cast to Long at https://github.com/apache/ozone/blob/master/hadoop-hdds/config/src/main/java/org/apache/hadoop/hdds/conf/ConfigurationReflectionUtil.java#L247
What is the link to the Apache JIRA
https://issues.apache.org/jira/browse/HDDS-4624
How was this patch tested?
UT

R: @nandakumar131 @GlenGeng @ChenSammi

+1
LGTM. Thanks for the fix!

authors: GlenGeng amaliujia

repo: apache/ozone


text:
HDDS-5656. Move old objects to delete table on overwriting multipart objects

What changes were proposed in this pull request?
This pull request aims at porting my work in HDDS-5461 ( https://github.com/apache/ozone/pull/2433 ) to multipart-uploaded objects. The change is almost same; on committing multipart objects (moving the OmKeyInfo from multipart table to key table), move the previous version of the key info to delete table.
CC: @bharatviswa504
What is the link to the Apache JIRA
HDDS-5656
How was this patch tested?
Unit tests updated

Hi guys, I'll fix the conflicts, but any updates on this? @bharatviswa504 @ChenSammi

@hanishakoneru Thank you for the review. I think I've addressed all of your comments.

@kuenishi, I still see that we are reading the key from DB twice.
For example, in OMKeyCommitRequest lines#217-224:
      RepeatedOmKeyInfo oldKeyVersionsToDelete = null;
      OmKeyInfo keyToDelete =
          omMetadataManager.getKeyTable(getBucketLayout()).get(dbOzoneKey);
      if (keyToDelete != null && !omBucketInfo.getIsVersionEnabled()) {
        oldKeyVersionsToDelete = getOldVersionsToCleanUp(dbOzoneKey,
            omMetadataManager, omBucketInfo.getIsVersionEnabled(),
            trxnLogIndex, ozoneManager.isRatisEnabled());
      }

dbOzoneKey is read from DB on line#219 and again in getOldVersionsToCleanUp() (OMKeyRequest line#801).
Also, we do not need to do versioning enabled check in getOldVersionsToCleanUp() as it is being checked before that method is called.

@hanishakoneru Thanks for picking up nits which I missed. I updated my pull request.

Both normal objects and multipart objects share the OmKeyInfo#addNewVersion() method to create a new version. So the fix in HDDS-6261 should work for this change, too.

From what I understand, versioning is not supported in Multipart keys currently.
In S3MultipartUploadCompleteRequest#getOmKeyInfo():
      // Already a version exists, so we should add it as a new version.
      // But now as versioning is not supported, just following the commit
      // key approach. When versioning support comes, then we can uncomment
      // below code keyInfo.addNewVersion(locations);

      // As right now versioning is not supported, we can set encryption info
      // at KeyInfo level, but once we start supporting versioning,
      // encryption info needs to be set at KeyLocation level, as each version
      // will have it's own file encryption info.

As such, the bug reported in HDDS-6261 should not effect Multipart keys.
cc. @smengcl @errose28
@kuenishi I will give it a day before committing in case Siyao or Ethan have any other comments. Thanks.

Since keyInfo.addNewVersion(locations) is commented out in the snippet you shared we should be ok here. That was the affected call.

Thanks @errose28. I will commit it now.

Thank you @kuenishi for working on this.

Thank you for the review, too @hanishakoneru

authors: errose28 hanishakoneru kuenishi


text:
HDDS-7442. [Release] Revert "HDDS-7116. Avoid leaking RocksObject from DBProfile (#3673)"

What changes were proposed in this pull request?
As we discussed.  We should revert HDDS-7116 in ozone-1.3.
What is the link to the Apache JIRA
https://issues.apache.org/jira/browse/HDDS-7442

Hi @ChenSammi @duongkame, In this revert, there's a little bit of conflict in one method.
Because HDDS-7116 added try catch to this method, other PR changed this line. There was only one conflict.
I've resolved the conflict, just in case, can you help double-check?


text:
HDDS-8069. [Snapshot] Compaction DAG reconstruction logic potentially crashing OM on startup

What changes were proposed in this pull request?
Problem: As part of jira-HDDS-7873, we added an optimization to early prune out SST files that won't be needed for compaction DAG base snap diff. More details in PR-4235.
Files are removed from back dir but compaction logs don't get updated because those are needed for DAG traversal based diffing. On OM restart, we count number of keys in the file present in compaction log. It is possible that file has been deleted due to above optimization which is causing OM crash.
This change is to log the exception instead throwing exception on OM restart. It will not affect Compaction DAG based snap diff because If file is not present during diff, it will throw the FileNotFoundException.
What is the link to the Apache JIRA
https://issues.apache.org/jira/browse/HDDS-8069
How was this patch tested?
Unit tests.

Thanks @hemantk-12 for the patch.


text:
HDDS-5569. recipe/BotoClient.md translation

What changes were proposed in this pull request?
HDDS-5569. recipe/BotoClient.md translation to Chinese
What is the link to the Apache JIRA
https://issues.apache.org/jira/browse/HDDS-5569
How was this patch tested?
hugo serve

thx for review @smengcl

Thanks @will-sh for the PR.

I think there is a Github glitch that prevents it from marking this PR as Merged. It is already merged in master:
https://github.com/apache/ozone/commit/5d999d2068618b9e1e8ed66188b3ea22dc225d1d
I will leave this PR here for a few hours to see if it fixes itself. If not I will close this manually.

Thanks @will-sh for the translation, @smengcl for the review.

authors: adoroszlai smengcl will-sh


text:
[compaction] support multi  table  AppendOnlyCompactionTask

Purpose

related https://github.com/apache/paimon/issues/2670

Tests

API and Format

Documentation

@leaves12138 PTAL

finished at #2858

repo: apache/paimon