2020-09-20 17:08
有关分页碰到的所有问题在这里都有的：
https://jfinal.com/doc/5-6
2020-09-20 17:06
OutOfMemoryError 这个异常通常是内存泄漏引起的，通过 JVM 自带的 visualvm 检查哪个地方的内存占用是一直上升的
2020-09-20 17:05
@__ 问题应该是找到了，并不是 Cron4jPulgin 不执行，而是你的项目出现了 OutOfMemoryError 异常，JVM 已经不能正常工作了，定时任务不执行就再正常不过了
2020-09-20 17:00
补充一下，如果用 kill 杀掉进程，使用 -9 参数，无论是不是 daemon 线程，都强制关闭 JVM，这个是操作系统层面的行为，是 JVM 自己也无法控制的
2020-09-20 16:59
线程的关闭其实与 jfinal 无关，纯属 java 的知识范畴
在 java 知识体系中，如果 jvm 关闭的话，线程如果正在执行，并且是 "非daemon" 线程，jvm 会等待这个线程执行完以后再关闭
如果是 daemon 线程，jvm 在关闭的时候会立即关闭，不等待没有执行完的线程
就 jfinal 内部启动的线程来说，都确保了是 daemon 线程，所以，你只需要关心自己开启的线程是什么类型的即可
2020-09-20 16:55
@山东小木 jfinal 社区国庆前后要上 app & coffee，这个才是未来，这个才能形成正向反馈循环，才可持续
以后，尽可能将一切都纳入 app & coffee
2020-09-16 12:02
漏洞扫描工具，如果不扫点东西出来，它自己是很没面子的
专门做这一行业的公司与个人更是没面子。我在 2009 年时做过北科院一个政府项目，做完以后要拿到专门的一个机构去做这类漏洞检测的工作，人家很轻松就能给你弄出一堆报告来
最后，回到你碰到的这个问题，你需要让对方重现问题是发生的过程，然后你才好修复问题
站在 jfinal 的角度，jfinal 唯一向外提供的口子就是你手动添加路由以后开放的 action，所以是不可能发生你碰到的这种事：“似乎可以使用特制的URL读取Web服务器文档目录之外的远程主机上的任意文件”
然后是 undertow，这个我认为概率也不大，如果确实有，你得让对方给出具体的重现方法
2020-09-12 21:59
还有一个解决办法是，先找到以前用过的那些 cookie 的 name，然后用一个 jfinal 的全局拦截器，通过下面的代码删掉那些 cookie:
inv.getController().removeCookie(name);
