在Open Liberty 22.0.0.3中重试交易恢复日志中的SQL操作以及更多的内容

DebugUsery
184 阅读5分钟

Open Liberty 22.0.0.3允许在交易恢复日志中重试SQL操作。这个版本还包括几个重要的错误修复。此外，我们还发布了一个全新的Open Liberty指南，关于用Podman来容器化微服务！在Open Liberty22.0.0.3中：

除了在运行时中添加的新特性和功能外，我们还对指南进行了更新。

查看22.0.0.3中修复的bug列表。

使用22.0.0.3运行您的应用程序

如果您使用的是Maven，这里有坐标：

<dependency>
    <groupId>io.openliberty</groupId>
    <artifactId>openliberty-runtime</artifactId>
    <version>22.0.0.3</version>
    <type>zip</type>
</dependency>

或者使用Gradle：

dependencies {
    libertyRuntime group: 'io.openliberty', name: 'openliberty-runtime', version: '[22.0.0.3,)'
}

或者如果你使用的是Docker：

FROM open-liberty

或者看一下我们的下载页面。

Ask a question on Stack Overflow

允许SQL操作在交易恢复日志中重试

在Liberty中，当你指定使用事务的功能时，事务服务被隐式激活，如jpa-2.0,jdbc-4.0, 和wasJmsServer-1.0 。

当Liberty检测到向其交易恢复日志写入失败时，它会使日志无效，并禁止进一步的全局交易。为了恢复事务性工作，你必须重新启动服务器并重新加载任何应用程序，这在某些情况下可能需要相当长的时间。

在某些情况下，比如恢复日志失败是由瞬时数据库连接错误引起的，这种情况可以通过重试数据库操作来处理，从而避免了关闭服务器和重新加载应用程序的需要。

在Libertyserver.xml 文件中的transaction 配置元素有一个新的属性，可以使这些事务日志SQL操作在RDBMS中重试。它被命名为enableLogRetries ，应该被设置为true ，以启用重试，比如说：

<transaction
dataSourceRef="tranlogDataSource"
recoverOnStartup="true"
waitForRecovery="false"
heuristicRetryInterval="10"
enableLogRetries="true"
/>

默认情况下，新功能是禁用的。

关于在RDBMS中存储事务恢复日志的更多信息，请参阅事务日志管理。

这个版本中修复的值得注意的错误

我们花了一些时间来修复错误。下面的章节描述了在这个版本中解决的一些问题。如果你有兴趣，这里是22.0.0.3中修复的全部bug列表。

  • jsonpContainer-2.0和jsonbContainer-2.0功能不正确地使用默认的提供者

    jsonpContainer-2.0 和jsonbContainer-2.0 功能不正确地使用了默认提供者。这些功能已被更新为包括BELLS功能，并删除了Liberty对JSON-P和JSON-B的默认实现。这允许用户为这些JSON技术包括他们自己的第三方库。

  • @RolesAllowed 拒绝未经认证的用户，当他们映射到一个允许的（EVERYONE）角色时

    以前，特殊主体EVERYONE 与@RolesAllowed 注释在JAX-RS 资源上不能正确工作。当特殊主体EVERYONE 绑定到一个security-role ，未经认证的用户应该被认为是该角色，并且应该能够访问该角色所允许的端点。当未经认证的用户被映射到一个允许的(EVERYONE)角色时，@RolesAllowed 注释会拒绝他们。这个问题后来得到了解决。

  • 当作为分段发送的JWT访问标记以 "Bearer "开头时，JWT入站传播失败

    在22.0.0.2中，当作为分段发送的JWT 以Bearer 开始时，JWT 访问令牌的入站传播失败。Liberty支持接受来自WebSeal 的多个头，其中包括JWT 访问令牌的部分内容。第一个头，Authorization-segments ，例如，表示后面有多少个 "n "段。其余的头信息Authorization-1 到Authorization-n 包含JWT 访问标记。当Authorization-1 以Bearer 开始时，访问令牌不能被正确地解析，以进行入站传播。如果发送JWT段，并且第一个头，Authorization-segments-1 ，以Bearer 开始，它应该像使用Authorization: Bearer 发送JWT时那样被正确处理。

  • OpenID连接。重定向位置中的双URL编码的状态参数

    以前，当从依赖方（RP）接收状态参数时，Liberty似乎返回了双重编码的状态。这个问题似乎发生在处理Liberty页面以授权RP的时候。

    https://www.oauth-login.com/oidc/endpoint/rp/authorize
Payload state: yyyyyyyyyyyyyyyyy

    这导致了一个响应代码302 ：和一个重定向的位置：

    [https://rp.example.com/oauth2callback/openid?code=xxxxxxxx&state=zzzzzzzzzzzzzzzzzz](https://rp.example.com/oauth2callback/openid?code=xxxxxxxx&state=zzzzzzzzzzzzzzzzzz)

    重定向URL中的有效载荷状态现在以与接收时相同的状态返回。

  • 检查点变化后，服务器命令在IBM i上不起作用

    在IBM i上，随着对服务器命令行脚本的改变，在22.0.0.2上带有任何选项的服务器命令失败，并出现了这个错误。

    server: 001-0050 Syntax error on line 1339: token "!" not expected.

    这个问题现在已经解决了。

  • 添加监控过滤器增加了启动时间

    以前，如果启用了mpMetrics-2.3 或更新版本，并且在server.xml 中不包括ThreadPoolStats 的监控过滤器，用户会遇到较慢的启动时间（大约4或5秒）。这个问题现在通过在一个单独的线程中异步加载ThreadPoolStats 相关的MBeans 来解决。因此，它不会影响捆绑程序的顺序启动，从而不会影响服务器的顺序启动。

  • 在嵌入Liberty的产品中，服务器停止会失败

    在22.0.0.1中增加了一个长期运行的线程来收集CPU的统计数据。它被创建为一个非daemon线程。这导致了在嵌入Liberty的产品中停止服务器的问题，并阻止JVM停止，直到所有非daemon线程都退出。服务器应该干净地停止。这个问题通过将CpuInfo 线程作为一个守护进程运行而得到修复。

此版本中的安全漏洞（CVE）修复

CVECVSS评分漏洞评估受影响的版本笔记
CVE-2021-39038

关于过去安全漏洞修复的列表，请参考安全漏洞（CVE）列表。

自上一版本以来新的和更新的指南

随着Open Liberty特性和功能的不断增长，我们将继续在openliberty.io上添加关于这些主题的新指南，以使其尽可能容易地被采用。 现有的指南也会得到更新，以解决任何报告的错误/问题，保持其内容的时效性，并扩大其主题的覆盖范围。

立即获取Open Liberty 22.0.0.3

可通过Maven、Gradle、Docker以及可下载的存档获得。

avatar
文章
阅读
粉丝