在修改表的时候会得到下面的提示，修改表需要删除后重建。 解决办法 在 SQL Server Management Studio 中选择 Tools > Options 然后选择左侧的设计（Designers）下面有一个选项是当对表进行调整的时候，如果需要重建表，操作将会被禁止的选项。     将上面的选项取消选择后，再执行操作就可以了。 发生这个问题的主要原因就是因为在创建表的时候对表进行重建了，在工具的默认情况下，这个操作是禁止的。 https://www.ossez.com/t/sql-server/627

在使用 Azure 的时候发现一个有趣的现象。 每天早上同事们开始开发工作的时候，不管是谁，第一次运行程序的时候都会出现数据库连接错误的提示。 2020-10-30 09:26:39.890 DEBUG 9398 --- [nio-8080-exec-2] com.zaxxer.hikari.pool.HikariPool : HikariPool-Azure - Cannot acquire connection from data source com.microsoft.sqlserver.jdbc.SQLServerException: Database 'sco' on server 'sco-db' is not currently available. Please retry the connection later. If the problem persists, contact customer support, and provide them the session tracing ID of '{C7F5F05C-76C3-41A9-8823-977205A60F4B}'. ClientConnectionId:1cb47252-b3f2-4b69-af0e-7e44994e21b6 at com.microsoft.sqlserver.jdbc.SQLServerException.makeFromDatabaseError(SQLServerException.java:262) 随后随时连接都不会有问题了。 查看过连接池的配置，也是正常的。 原因和解决 经过一段时间的分析后发现，在日志中，提示有重新启动数据库： 在查看日志的时候，也出现了一次连接失败的提示。 然后再出现连接失败的提示后，显示的所有连接都是成功的。 由此可以判断，在 Azure 数据库中是否有一个没有连接将会将数据库设置到休眠状况的配置。 根据官方的链接中有关文档的提示：https://docs.microsoft.com/en-us/azure/azure-sql/database/serverless-tier-overview#autoresuming 确实有一个休眠和恢复的配置。 你也可以取消这个功能。你可以通过下面的路径进行操作，选择 Configure，然后选择 Auto-Pause Delay。 你可以设置休眠时间，或者直接取消。 如果你的条件允许，或者预算比较宽裕的话，建议就直接取消这个功能。   https://www.ossez.com/t/azure-sql-database/625

我们希望给 Discourse 安装一个 sitemap 的插件。 你的 Discourse 需要这个插件吗？实际上是不需要的，这个插件能够帮助你加快索引，但是对 SEO 并不起太大作用。 安装方法 找到插件的 GitHub 地址： https://github.com/discourse/discourse-sitemap 上面的地址是这个项目的地址，在这个项目的地址下，我们可以找到这个插件的地址为： https://github.com/discourse/discourse-sitemap.git     将插件地址的仓库注册 请参考官方的教程，地址为： https://meta.discourse.org/t/install-plugins-in-discourse/19157 你需要修改 Discourse 安装路径下的 app.yml 文件。 依次执行的命令为： cd /var/discourse nano containers/app.yml 对 app.yml 文件来进行编辑。 添加下面一行： - git clone https://github.com/discourse/discourse-sitemap.git     上面的图片显示添加成功后的内容。 重构 在完成上面的配置后，依次执行下面的命令来对你安装的 Discourse 进行重构。 这个重构可能比较消耗时间，你需要耐心等候。 cd /var/discourse ./launcher rebuild app 下面的图片显示 Discourse 正在重构。     后台确认 登录后台后选择 plugin。 如果你能看到你的站点地图插件，就说明已经安装成功了。 你可以点击进去进行设置。     同时你也可以访问下面的链接确定安装已经正确了。 /sitemap.xml /news.xml A Sitemap line in robots.txt     确定站点地图已经生效了。 https://www.ossez.com/t/discourse/624/2

使用下面的方法： logger.debug("Current DateTime in milliseconds - [{}]", new DateTime().getMillis()); 上面的代码输出的内容是： 15:01:51.331 [main] DEBUG c.i.s.c.t.utilities.CodecUtilsTest - Current DateTime in milliseconds - [1603998111331] 获得当前日期时间的毫秒数，这个毫秒数是从 1970-01-01T00:00:00Z 开始计算的。 1970年， Unix正式诞生，在第一版《Unix Programmer’s Manual》中把“1971年11月3日”定义为“自1970年1月1日0时0分0秒以来以1/60秒为单位的时间”。 此后，这个定义由于可定义的时间范围，时区，闰秒等问题被重新定义。 https://www.ossez.com/t/java-datetime-unix/623

假定我们有一个文件位于：src/test/resources/data/azure_storage.json 目录中。 azure_storage.json 为数据文件，我们希望将这个文件中的内容读取到测试类中。 azure_storage.json 数据文件在编译成功后会被拷贝到：target/test-classes/data/azure_storage.json 目录中。     进行读取 在测试类中，我们可以在初始化数据的时候读取数据。 /** * Init Data * @throws IOException */ @BeforeAll public void setUp() throws IOException { ClassLoader loader = Thread.currentThread().getContextClassLoader(); // INIT properties props.load(loader.getResourceAsStream("log4j.properties")); // INIT Azure Storage Test File try { InputStream inputStream = loader.getResourceAsStream(fileName); FileUtils.copyInputStreamToFile(inputStream, azureStorageFile); } catch (IOException e) { logger.error("Init data send to azure error." ,e); } } fileName 使用下面的定义： private String fileName = "data/azure_storage.json"; 需要注意的是 PATH，应该使用的是相对路径。 在数据初始化的时候，我们使用下面的代码： InputStream inputStream = loader.getResourceAsStream(fileName); 先将资源文件中数据读取为 InputStream ，这个时候你的数据已经在内存中了，我们在上面的代码中使用代码 FileUtils.copyInputStreamToFile 来将内存中的数据写到一个临时目录中，然后你就可以对文件进行操作了。 当然你也可以直接使用 InputStream 来进行必要的下一步测试和操作就可以了。 使用这样的配置好处就是在测试的时候，因为不同的人使用的系统是不同的，不同的测试文件路径会导致没有办法进行路径的同步。   https://www.ossez.com/t/java-unit-resources/622

在程序运行到一段时间后，发现上传文件的时候提示： <?xml version="1.0" encoding="UTF-8"?> <Error> <Code>AuthenticationFailed</Code> <Message>Server failed to authenticate the request. Make sure the value of Authorization header is formed correctly including the signature. RequestId:c443ad49-c01e-0083-126e-ad5565000000 Time:2020-10-28T21:10:53.9706211Z</Message> <AuthenticationErrorDetail>Signature not valid in the specified time frame: Start [Wed, 28 Oct 2020 20:43:29 GMT] - Expiry [Wed, 28 Oct 2020 20:45:29 GMT] - Current [Wed, 28 Oct 2020 21:10:53 GMT]</AuthenticationErrorDetail> </Error>     问题原因和解决 出现上面的提示的原因是你的 sasToken 过期了。 在 Azure 存储的时候，如果你生成 sasToken，在这个 token 上面有一个有效期的设置，在默认的时候这个有效期的时间非常短。 你可以设置为更长的时间。       单击上面的链接，修改令牌的有效期后生成新的令牌。 这样就可以保证你的存储不快速过期。     https://www.ossez.com/t/azure/621  

有时候我们需要知道一个文件的大小。 我们可以使用一些方法，比如说将文件读取成 InputStream，然后再使用 available() 获得长度就可以了。 我们也可以使用 FileUtils 来获得。 使用的方法是： FileUtils.sizeOf(localFileCache) localFileCache 中定义的是文件对象。 关于 sizeOf 的使用为：返回指定的文件或者文件夹的大小。如果你的 File 对象为一个文件的话，这个方法将会返回文件的大小。 如果你的 File 对象为一个目录的话，那么上面的方法将会返回这个文件夹的大小。这个文件夹的大小将会包含这个文件夹中所有子文件夹的内容。换句话说，这个方法是进行递归大小查询的。     但是，如果一个文件夹或者子文件夹有安全限制，不允许访问的话，那么这个方法将不会将上面的文件夹的内容进行计算。   https://www.ossez.com/t/java/620

当你完成安装数据库后，通常会迫不及待的进行访问和连接。但是防火墙会给你很大的麻烦，如果你不进行正确的配置的话。不管使用什么工具，可能就是一直连不上。 本文主要帮助你解决这个小问题。 下面的配置需要在 MariaDB 数据库服务器上进行配置。 我们的场景是，假设我们有一个 Web 服务器是部署在 IP 地址 192.168.0.1 上面。我们需要这个 Web 服务器能访问我们的数据库。数据库使用的端口是 3306。 在正常安装情况下，如果你的 firewalld 启动的话，Web 服务器是没有办法进行访问的，因为你的端口和 IP 地址已经被禁止了。 解决办法 可以按照下面的办法进行配置。 在配置之前，我们的流程是配置一个 zone，然后为zone 里面添加 IP 地址和端口，然后重新启动防火墙。 添加 Zone 假设我们需要为我们的 MariaDB 数据库添加一个叫 mariadb_access 的 zone 依次执行下面的命令： # firewall-cmd --new-zone=mariadb_access --permanent # firewall-cmd --reload # firewall-cmd --get-zones 上面的命令执行的是，添加一个叫 mariadb_access 的 zone，将防火墙的配置重新载入，使配置生效，然后检查添加的 zone 是否成功。 如果一切顺利的话，你应该能够看到上面的内容，表示你添加的 zone 成功了。 添加 IP 地址和端口 需要依次执行下面的命令： firewall-cmd --zone=mariadb_access --add-source=192.168.0.1 --permanent firewall-cmd --zone=mariadb_access --add-port=3306/tcp --permanent firewall-cmd --reload 上面命令执行的是，将 IP 地址添加到信任的 zone 中，将端口也添加到信任的 zone 中。 重新载入防火墙，使配置生效。 查看 zone 的配置 使用下面的命令来查看 zone 的配置，确保你的配置生效 firewall-cmd --zone=mariadb_access --list-all 在上面的命令中，你应该可以看到添加的 IP 地址和端口。 使用一条命令 上面的操作步骤是按照添加 Zone 然后添加其他参数的方法来执行的。 你需要分步执行几条命令。 如果你想通过一条命令来完成上面的操作，你可以使用下面的示例： firewall-cmd --permanent –zone=mariadb_access --add-rich-rule='rule family="ipv4" source address="192.168.0.1" port protocol="tcp" port="3306" accept' 请注意，你需要将你实际 Web 服务器的 IP 地址来进行替换。 https://www.ossez.com/t/firewall-cmd-mariadb/619  

更新 CentOS 的时候提示 Jenkins 错误。 Total size: 198 M Is this ok [y/d/N]: y Downloading packages: warning: /var/cache/yum/x86_64/7/jenkins/packages/jenkins-2.249.2-1.1.noarch.rpm: Header V4 RSA/SHA512 Signature, key ID 45f2c3d5: NOKEY Public key for jenkins-2.249.2-1.1.noarch.rpm is not installed 解决办法 可以考虑执行下面的命令： [root@jenkins ~]# wget -O /etc/yum.repos.d/jenkins.repo http://pkg.jenkins.io/redhat-stable/jenkins.repo [root@jenkins ~]# rpm --import http://pkg.jenkins.io/redhat-stable/jenkins.io.key 执行上面的命令后，服务器控制台的输出为： [root@devops-norctx-com ~]# wget -O /etc/yum.repos.d/jenkins.repo http://pkg.jenkins.io/redhat-stable/jenkins.repo --2020-10-28 12:48:31-- http://pkg.jenkins.io/redhat-stable/jenkins.repo Resolving pkg.jenkins.io (pkg.jenkins.io)... 2a04:4e42:31::645, 199.232.38.133 Connecting to pkg.jenkins.io (pkg.jenkins.io)|2a04:4e42:31::645|:80... connected. HTTP request sent, awaiting response... 301 Moved Permanently Location: https://pkg.jenkins.io/redhat-stable/jenkins.repo [following] --2020-10-28 12:48:31-- https://pkg.jenkins.io/redhat-stable/jenkins.repo Connecting to pkg.jenkins.io (pkg.jenkins.io)|2a04:4e42:31::645|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 85 Saving to: ‘/etc/yum.repos.d/jenkins.repo’ 100%[=============================>] 85 --.-K/s in 0s 2020-10-28 12:48:32 (2.79 MB/s) - ‘/etc/yum.repos.d/jenkins.repo’ saved [85/85] [root@devops-norctx-com ~]# rpm --import http://pkg.jenkins.io/redhat-stable/jenkins.io.key [root@devops-norctx-com ~]# 然后再运行更新就不会有问题了。     你的操作系统就能够进行更新了。 https://www.ossez.com/t/jenkins-2-249-2-1-1-noarch-rpm-is-not-installed/618

在 Azure 上传文件的时候遇到了一个下面的异常： java.io.IOException: mark/reset not supported at java.base/java.io.InputStream.reset(InputStream.java:655) at com.azure.storage.common.Utility.lambda$convertStreamToByteBuffer$4(Utility.java:236) at reactor.core.publisher.FluxDefer.subscribe(FluxDefer.java:46) at reactor.core.publisher.Mono.subscribe(Mono.java:4213) 问题解决 当给定的流不支持 mark 和 reset 就会报这个错误。 我们用的代码是： blobClient.upload(inputStream , inputStream.available()); InputStream 是不支持 mark 和 reset 的。 BufferedInputStream继承于FilterInputStream，提供缓冲输入流功能。 缓冲输入流相对于普通输入流的优势是，它提供了一个缓冲数组，每次调用read方法的时候，它首先尝试从缓冲区里读取数据，若读取失败（缓冲区无可读数据），则选择从物理数据源（例如你指定的文件）读取新数据（这里会尝试尽可能读取多的字节）放入到缓冲区中，最后再将缓冲区中的内容部分或全部返回给用户。 由于从缓冲区里读取数据远比直接从物理数据源（譬如文件）读取速度快。 Azure 使用上面的方法来尽量保障数据能够上传到存储中。 解决方案是用 BufferedInputStream 再把原来的流包装一层。 什么时候会出现这种错误呢，当你获得一个 InputStream 流，这个流是不允许读写头来回移动，也就不允许 mark/reset 机制。 所以上面的代码修改为： blobClient.upload(new BufferedInputStream(inputStream) , inputStream.available());     然后再重试，你就会看到文件上传上去了。 登录控制台查看上传的文件。     https://www.ossez.com/t/java-io-ioexception-mark-reset-not-supported/617/2