LOG004：数据已损坏。在第12点记录例外

Question

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

此时某处发生此异常并且所有计时器都被清除。问题是，我从未改变代码中的任何内容，并且应用程序在此之前工作正常。 REST-API没有改变，任何地方都没有其他例外。

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

  

JTS5022来自日志的意外异常[{0}]。

     

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

     

[2016-12-13T10：59：00.235 + 0000] [glassfish 4.1] [SEVERE] [jts.log_error] [javax.enterprise.system.core.transaction.com.sun.jts.CosTransactions] [tid： _ThreadID = 450 _ThreadName = __ ejb-thread-pool6] [timeMillis：1481626740235] [levelValue：1000] [[JTS5022：来自日志的意外异常[{0}]。 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）at com.sun.jts.CosTransactions.CoordinatorLog.formatLogRecords（CoordinatorLog.java:1040）at com.sun.jts.CosTransactions.CoordinatorLog.write（CoordinatorLog.java:534） ）com.sun.jts.CosTransactions.TransactionState.setState（TransactionState.java:732）at com.sun.jts.CosTransactions.TopCoordinator.prepare（TopCoordinator.java:2001）at com.sun.jts.CosTransactions.CoordinatorTerm。 com.sun.jts.CosTransactions.TerminatorImpl.commit（TerminatorImpl.java:231）在com.sun.jts.CosTransactions.CurrentImpl.commit（CurrentImpl.java:622）的com.sun中提交（CoordinatorTerm.java:328） .jts.jta.TransactionManagerImpl.commit（TransactionManagerImpl.java:331）at com.sun.enterprise.transaction.jts.JavaEETransactionManagerJTSDelegate.commitDistributedTransaction（JavaEETransactionMana）位于com.sun.ejb.containers.EJBContainerTransactionManager.completeNewTx（EJBContainerTransactionManager.java:719）的com.sun.enterprise.transaction.JavaEETransactionManagerSimplified.commit（JavaEETransactionManagerSimplified.java:859）com.sun.ejb上的gerJTSDelegate.java:174） .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）at com.sun.ejb.containers.BaseContainer.callEJBTimeout（BaseContainer.java:4080）at com.sun.ejb.containers.EJBTimerService。在com.sun.ejb.containers.EJBTimerService.access $ 000（EJBTimerService.java:89）的com.sun.ejb.containers.EJBTimerService $ TaskExpiredWork.run（EJBTimerService.java:1919）的deliverTimeout（EJBTimerService.java:1199）at 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.util.concurrent.ThreadPoolExecutor $ Worker.run（ThreadPoolExecutor） .java：615）在java.lang.Thread.run（Thread.java:745）]]

我的理解是有一些日志文件损坏或任何东西。但是我甚至都没碰过它们，甚至没有说出哪一个。

我非常感谢任何建议。

Answer 1

*我的解决方法**

这不是一个真正的解决方案，而是一种解决方法，因为它并没有解决问题。

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

<path to domain>/logs/server/tx

我的猜测是那里的某些文件已损坏。现在我无法修复它，但可以关闭GlassFish中的事务日志记录。

在GlassFish管理控制台中，转到

configurations > server-config > Transaction Service 

并添加属性：

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

显然这个设置主要用于tune the performance，但在我的情况下，已损坏的日志文件不再是问题，应用程序继续运行（可能更快;）