CodePlayer

@wenshao 用新版本测试了下，writeBigDecimal 的问题已经解决了，不过又发现了一个类似的 bug。 ```java OutputStreamWriter out = new OutputStreamWriter(new ByteArrayOutputStream(), StandardCharsets.UTF_8); try (CSVWriter writer = CSVWriter.of(out)) { writer.writeValue("1".repeat(65534)); writer.writeComma(); writer.writeString("123"); // java.lang.StringIndexOutOfBoundsException: offset 65535, count 3, length 65536 }...

@wenshao 举一反三，我分析了一下，出 bug 的地方一般可能存在两种情况： 1. 存量部分 + **增量**部分 刚好超过底层数组容量 65536，且没有预检测 2. **增量**部分 自己就超过了 65536。 我先构造一个 **65535** 容量的 Writer buffer，然后依次调用每一个 `write*()` 方法，发现还有如下方法存在类似的问题（此处以 `CSVWriterUTF16` 为例，`CSVWriterUTF8` 同理】）： ```java OutputStreamWriter out = new OutputStreamWriter(new...

> 这个结论，是在数据量仅有issue中描述的几条数据的基础上得来的，还是测试过比较大量的数据，也是这个结果？ > > Is this conclusion based on the data volume being only a few pieces of data described in the issue, or is this the result after testing...

建议看看官方文档：https://maven.apache.org/guides/mini/guide-relocation.html

> OB Version : OB-CE 4.3.1.0 Beta > > 部署在AWS，1-1-1集群，备份到S3，delete_mode=tagging。 看账单发现OB的S3桶一个月WriteObjectTagging调用了1亿多次，平均每天330多万次。 统计每天的备份文件数在12000~13000左右，不明白这么多API调用怎么来的。 > > OB Version: OB-CE 4.3.1.0 Beta > > Deployed in AWS, 1-1-1 cluster, backed up to S3,...

这不是 bug，而是你自己**用法不对**： 1. 你的字段是 `private` 的，且不提供 `get`、`set` 方法，当然不能反序列化。 2. 你使用的注解 `@JsonField("is_cooperate")` 根本就不是 Fastjson 的注解，Fastjson2 的注解是这样的 ```java // 这才是 Fastjson2 的注解 ！ @com.alibaba.fastjson2.annotation.JSONField(name = "is_cooperate") ``` 你把注解修改正确，解决办法如下（选其一即可）： 1. 添加该字段的 get、set 方法...

 这个表有50亿左右的数据，最关键的一个SQL慢查询的执行时间超过了1个小时，CPU占用超过60% 。 最担心的就是，如果是生产环境，时不时的也这么搞一下，那就完蛋了。感觉就像埋了一个定时炸弹一样。 ---  This table has about 5 billion data. The execution time of the most critical slow SQL query exceeds 1 hour, and the CPU usage...

@Young-Cody 我们不仅想知道 日志流之间**分区组**数目的差值不超过1，还想知道每个表组是如何确定自己最终归属到哪个Zone的 ？ 比如有 6 个表组 `A1`、`A2`、`B1`、`B2`、`C1`、`C2`，其中 `A1`、`B1`、`C1` 的性能负载相对较高，我们不希望它们恰好被分配到同一个 Zone。不然的话，即使数量均衡（比如 **A1+B1**、A2+B2、C1+C2），这样分配也不是太理想。 从目前已知的实现来看，如果将分布在多个 Zone 的多个表添加到同一个表组，表组中 `table_id` 最小的表在哪个Zone，整个表组就会优先全部迁移到该 Zone。 --- @Young-Cody Not only do we want to know that the difference...

> java的 Introspector.decapitalize("sCode") 输出的是小写 不会转成大写 @win32fk 那是因为你的字段名是 "sCode"，但是方法名是"getSCode()"。 Java 规范是根据 **getter 方法名**来解析属性名称的，而不是字段名称 ！ 去掉 "get" 前缀，`Introspector.decapitalize("SCode")` 得到的结果就是首字母大写的。 BTW：现在的 Java开发人员 都不需要学习 Java Bean 规范了么 ？

你使用的版本过于陈旧，建议升级到最新版本看看是否有类似的问题。