Java LOG004:数据已损坏。第12点的日志异常

我从未见过这种错误。我有一个GlassFish应用服务器实例，其中有一个（在此之前）运行良好的应用程序。 它由几个使用JMS进行通信的web应用程序组成。 单例bean中运行有定时计时器任务，它向另一台服务器发出几个REST请求，然后通过JMS发送收到的JSON

在这一点上的某个地方，会发生此异常，并删除所有计时器。问题是，我从未更改过代码中的任何内容，在此之前，应用程序运行良好。REST-API没有改变，任何地方都没有其他异常

我检查了这个错误，但他们只说：

JTS5022日志中出现意外异常[{0}]

解决方案： 这是一个意外的内部错误。请与Sun联系，并提供完整的错误日志消息

[2016-12-13T10:59:00.235+0000][glassfish 4.1][severy][jts.log_error][javax.enterprise.system.core.transaction.com.sun.jts.cotransactions][tid:_ThreadID=450 u ThreadName=u ejb-thread-pool6][timeMillis 1481626740235][levelValue:1000][JTS5022:意外异常[{0}]从log.com.sun.jts.CosTransactions.LogException:LOG004:com.sun.jts.CosTransactions.LogControl.openFile（LogControl.java:541）到com.sun.jts.CosTransactions.log.open（log.java:172）到com.sun.jts.CosTransactions.CoordinatorLog.openLog（CoordinatorLog.java:1161）的点12处的数据损坏.log异常com.sun.jts.CosTransactions.CoordinatorLog.formatLogRecords（CoordinatorLog.java:1040）com.sun.jts.CosTransactions.CoordinatorLog.write（CoordinatorLog.java:534）com.sun.jts.CosTransactions.Transactions.TransactionState.setState（TransactionState.java:732）com.sun.jts.CosTransactions.topCoordinatorog.prepare（TopCoordinator.java:2001）com.sun.jts.CosTransactions.coordinarterm.commit（coordinarterm.java:328）com.sun.jts.CosTransactions.TerminatorImpl.commit（TerminatorImpl.java:231）com.sun.jts.CosTransactions.CurrentImpl.commit（CurrentImpl.java:622）com.sun.jts.jta.TransactionManagerImpl.commit（TransactionManagerImpl.java:331）com.sun.enterprise.transaction.jts.JavaEETransactionManagerJTSDelegate.commitDistributedTransaction（JavaEETransactionManagerJTSDelegate.java:174）com.sun.enterprise.transaction.JavaEETransactionManagerSimplified.commit（JavaEETransactionManagerSimplified.java:859）com.sun.ejb.containers.EJBContainerTransactionManager.completeNewTx（EJBContainerTransactionManager.java:719）在com.sun.ejb.containers.EJBContainerTransactionManager.postInvokeTx（EJBContainerTransactionManager.java:503）在com.sun.ejb.containers.BaseContainer.postInvokeTx（BaseContainer.java:4566）在com.sun.ejb.containers.BaseContainer.postInvoke（BaseContainer.java:2074）上com.sun.ejb.containers.BaseContainer.postInvoke（BaseContainer.java:2044）com.sun.ejb.containers.BaseContainer.callEJBTimeout（BaseContainer.java:4080）com.sun.ejb.containers.EJBTimerService.deliverTimeout（EJBTimerService.java:1199）com.sun.ejb.containers.EJBTimerService.access$000（EJBTimerService.java:89）在com.sun.ejb.containers.EJBTimerService$TaskExpiredWork.run（EJBTimerService.java:1919）在java.util.concurrent.Executors$RunnableAdapter.call（Executors.java:471）在java.util.concurrent.FutureTask.run（FutureTask.java:262）在java.util.concurrent.ThreadPoolExecutor.runWorker（ThreadPoolExecutor.java:1145）上java.lang.Thread.run（Thread.java:745）]处的java.util.concurrent.ThreadPoolExecutor$Worker.run（ThreadPoolExecutor.java:615）

据我所知，有一些日志文件被破坏或其他什么东西。但我甚至没有碰它们，它甚至没有说是哪一个

非常感谢您的建议。

*我的解决方法**

这不是一个真正的解决方案，而是一个变通办法，因为它不能解决问题

原来GlassFish为JMS（可能还有其他）事务保存单独的日志文件。它们与标准日志文件位于同一文件夹中。 就我而言：

<path to domain>/logs/server/tx

并添加属性：

Name:                                    Value:
disable-distributed-transaction-logging  true

---

显然，这种设置主要用于解决问题，但在我的例子中，损坏的日志文件不再是问题，应用程序继续运行（可能更快；）

这似乎是GlassFish处理分布式事务时的一个错误。我建议尝试使用Payara来替代GlassFish，因为它修复了许多模糊的GlassFish错误。@OndrejM感谢您的建议。我不知道Payara。这确实很有趣！

Name:                                    Value:
disable-distributed-transaction-logging  true