2024-10-22 16:27
@山东小木 SseEmitter这个类里的waiting方法最后一行有一句System.out.println("Waiting finished");能不能下次更新发布jfinal的时候，把这句代码注释掉？
2024-10-11 11:13
@小曦 他是通过url请求传递json body，不知道你的那个this.getJson111()函数里是如何获取传递的参数的。如果是你自己通过get方法获取，但你前端是传递json body方式传递，代码里需要在MainConfig的configConstant方法里增加me.setResolveJsonRequest(true);以开启自动解析json body。这个功能需要jfinal5.0.0及更高版本支持。否则，你需要自己getRawData，然后自己解析参数。只是猜测，不一定对。
2024-10-11 11:05
@isddoidnoi 我的系统是使用jwt认证登录，对接的cas单点。如果你用的是jwt，可以私信我，我给你贴点代码。
2024-08-15 13:03
linux基本功还需要提高一下。直接命令行运行，输出是指定到控制台，你只要一关闭终端，就看不到输出了。你可以在启动的时候，把输出从定向到一个文件里，然后你再次登录上服务器，就可以使用tail -f 你的日志文件查看输出信息了。不过这个文件会越来越大，你需要定期清除，具体清除方法百度一下就行了。
2024-07-04 10:35
我知道他的意思，和我的处理方法一样，但有个问题，不同的数据库连接config只能使用自己的一套模板，除非你在动态启动这个数据库连接的时候，把这个共享模板路径加到这个数据库连接里。另外。我最初搞saas也是这么搞的，但后来就遇到这个很大的问题，用户越来越多后，你的起的数据库连接就太多了，这是个很大的问题。后来我的就改成一个业务数据库，但库结构使用租户ID区分了。反正各有优缺点。
2024-07-04 10:26
我就是遇到过这个问题，在configConstant里设置JFinalJson.setDefaultConvertDepth(100);就行了。不过首先确认你使用的是JFinalJson。
2024-05-20 17:29
@hb963724769 生产环境都是客户自建机房，服务器都在他们自己的机房。因为他们都是私网，不允许接入公网。但现在他们的服务器是一个配置很高的物理服务器上创建的虚拟机。如果排查硬盘坏道应该是个很麻烦的事。
2024-05-18 12:41
@杜福忠 我让运维把数据库服务器搬到其他物理机器上试验试验！这种诡异的事情真的很难排查！
2024-05-17 16:40
@杜福忠 @chcode @hb963724769 jdbc链接已经带上rewriteBatchedStatements=true这个参数。主要是生产环境已经在线运行了大半年了，一直都挺好。就4月26号后这个功能突然就卡那了，跟踪执行发现这个batchUpdate需要2分钟多才执行完。为了排查问题，生产环境新间的虚拟机操作系统和安装的mysql配置参数一模一样，也是需要执行2分钟多。但把他们的生产数据库全库备份到我们的开发服务器上，这个功能只需2秒就执行了。现在还在一头雾水中。
2024-05-17 16:27
@hb963724769 jdbc驱动设置的事务隔离级别是2-TRANSACTION_READ_COMMITTED
2024-05-17 16:26
@hb963724769 这些配置都有innodb_buffer_pool_size=4G，innodb_log_file_size=8M（后面又改成32M），innodb_flush_log_at_trx_commit=2，就是上述这个状态。
