WebSphere Liberty Profile阻止数据源查找

时间：2016-11-08 08:59:22

标签： configuration datasource websphere-liberty

我正在尝试在IBM WebSphere Liberty Profile（16.0.0.3）中配置数据源，这是我到目前为止所做的：

server.xml中 

<authData id="dbuser" password="{xor}blablabla" user="MY_USER"/>

<dataSource id="Oracle" isolationLevel="TRANSACTION_READ_COMMITTED" 
    jdbcDriverRef="OracleDriver" 
    jndiName="EPMS_DS" 
    recoveryAuthDataRef="dbuser" 
    type="javax.sql.ConnectionPoolDataSource">

    <properties.oracle databaseName="DBNAME" portNumber="1521" serverName="SERVERNAME"/>
</dataSource>

<jdbcDriver id="OracleDriver" 
    javax.sql.ConnectionPoolDataSource="oracle.jdbc.pool.OracleConnectionPoolDataSource" 
    libraryRef="shared-library"/>

的web.xml 

<resource-env-ref>
    <description>The Oracle DS</description>
    <resource-env-ref-name>jdbc/OracleDS</resource-env-ref-name>
    <resource-env-ref-type>javax.sql.DataSource</resource-env-ref-type>
</resource-env-ref>

IBM的Web-bnd.xml 

<resource-ref name="jdbc/OracleDS" binding-name="EPMS_DS">
    <authentication-alias name="dbuser" />
</resource-ref>

然而，除了应用程序服务器启动时间超过2分钟之外，我的应用程序似乎还冻结了以下指令：

ctx = new InitialContext();
ctx.lookup("java:comp/env/jdbc/OracleDS");

日志没有显示任何错误，它显示的最后一行是应用程序的调试消息，表明它将进行JNDI查找。

我还在server.xml中尝试了不同的配置，没有<authData>并在数据源上明确定义用户和密码，但结果相同：

<dataSource id="Oracle" isolationLevel="TRANSACTION_READ_COMMITTED" jdbcDriverRef="OracleDriver" jndiName="EPMS_DS" type="javax.sql.ConnectionPoolDataSource">
    <properties.oracle URL="jdbc:oracle:thin:@SERVERNAME:1521:DBNAME" password="{xor}blablabla" user="MY_USER"/>
</dataSource>

遗憾的是，Liberty Profile似乎没有提供测试数据库连接的方法，但似乎所有内容都已正确配置（我可以确保凭据正确，以及服务器名称和端口）。我在这里缺少什么？

编辑＃1

根据njr的建议，我已经执行了一个线程转储，这是一个摘要：

-  waiting on com.ibm.tx.jta.impl.EventSemaphore@737eaefc
-  waiting on com.ibm.ws.objectManager.FileLogOutput$FlushHelper@19d51071
-  waiting on com.ibm.ws.objectManager.FileLogOutput$NotifyHelper@2fa0da91
-  waiting on com.ibm.ws.objectManager.ObjectManagerState$CheckpointHelper@5b0919fc
-  waiting on com.ibm.ws.sib.msgstore.persistence.dispatcher.SpillDispatcher$DispatchingLock@1620db94
   (8 Occorrences, but different instances)
   ...
-  waiting on com.ibm.ws.threading.internal.BoundedBuffer$GetQueueLock@c8a05b6
   (56 Occorrences, but different instances)
   ...
-  waiting on java.lang.Object@4c1d5897
-  waiting on java.lang.ref.Reference$Lock@5448da4c
-  waiting on java.lang.ref.ReferenceQueue$Lock@f91b025
-  waiting on java.util.LinkedList@5b213416
-  waiting on java.util.LinkedList@6cb46e1f
-  waiting on java.util.TaskQueue@f50561c
   (14 Occorrences, but different instances)
   ...
-  waiting on java.util.concurrent.atomic.AtomicReference@5476d077
-  waiting on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@4da17c93
-  waiting on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@513339c6
-  waiting on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@5dc2ae0f
-  waiting on org.eclipse.osgi.framework.eventmgr.EventManager$EventThread@236970be
-  waiting on org.eclipse.osgi.framework.eventmgr.EventManager$EventThread@6dfdd5
-  waiting on org.eclipse.osgi.framework.eventmgr.EventManager$EventThread@72ce4e1c
-  blocked on com.ibm.tx.jta.embeddable.impl.EmbeddableTMHelper@5748c911
-  blocked on com.ibm.tx.jta.embeddable.impl.EmbeddableTMHelper@5748c911

有人可以帮我解释一下吗？

编辑＃2

这是阻塞线程的完整堆栈跟踪：

LargeThreadPool-thread-148 [217] (BLOCKED)
   com.ibm.tx.jta.embeddable.impl.EmbeddableTMHelper.start line: 63
   com.ibm.tx.jta.util.TxTMHelper.start line: 461
   com.ibm.tx.util.TMHelper.start line: 74
   com.ibm.tx.jta.util.TxTMHelper.checkTMState line: 500
   com.ibm.tx.util.TMHelper.checkTMState line: 116
   com.ibm.tx.jta.impl.TranManagerSet.registerResourceInfo line: 270
   com.ibm.ws.transaction.services.TransactionManagerService.registerResourceInfo line: 260
   com.ibm.ejs.j2c.ConnectionManager.registerXAResourceInfo line: 2537
   com.ibm.ejs.j2c.ConnectionManager.<init> line: 509
   com.ibm.ejs.j2c.ConnectionManagerServiceImpl.getConnectionManager line: 407
   com.ibm.ejs.j2c.ConnectionManagerServiceImpl.getConnectionManager line: 54
   com.ibm.ws.jca.cm.AbstractConnectionFactoryService.createResource line: 146
   com.ibm.ws.injectionengine.osgi.internal.IndirectJndiLookupObjectFactory.createResourceWithFilter line: 346
   com.ibm.ws.injectionengine.osgi.internal.IndirectJndiLookupObjectFactory.createResource line: 319
   com.ibm.ws.injectionengine.osgi.internal.IndirectJndiLookupObjectFactory.getObjectInstance line: 133
   com.ibm.ws.injectionengine.osgi.internal.IndirectJndiLookupObjectFactory.getObjectInstance line: 99
   com.ibm.wsspi.injectionengine.InjectionBinding.getInjectionObjectInstance line: 1556
   com.ibm.wsspi.injectionengine.InjectionBinding.getInjectionObject line: 1433
   com.ibm.wsspi.injectionengine.InjectionBinding.getInjectionObject line: 1389
   com.ibm.ws.injectionengine.osgi.internal.naming.InjectionJavaColonHelper.getObjectInstance line: 116
   com.ibm.ws.jndi.url.contexts.javacolon.internal.JavaURLContext.lookup line: 333
   com.ibm.ws.jndi.url.contexts.javacolon.internal.JavaURLContext.lookup line: 371
   org.apache.aries.jndi.DelegateContext.lookup line: 161
   javax.naming.InitialContext.lookup line: 417
   pt.sibs.epms.persistence.utils.EntityManagerFactoryController.jndiLookupUsed line: 264
   pt.sibs.epms.persistence.utils.EntityManagerFactoryController.checkConfiguration line: 115
   pt.sibs.epms.persistence.utils.EntityManagerFactoryController.<init> line: 95
   pt.sibs.epms.persistence.utils.EntityManagerFactoryController.<init> line: 51
   pt.sibs.epms.persistence.utils.EntityManagerFactoryController$SingletonHolder.<clinit> line: 81
   pt.sibs.epms.persistence.utils.EntityManagerFactoryController.getInstance line: 88
   pt.sibs.epms.util.logging.LoggerConfiguration.<clinit> line: 33
   pt.sibs.epms.ecc.renderer.HtmlFormRenderer.<clinit> line: 25
   java.lang.Class.forName0 line: not available [native method]
   java.lang.Class.forName line: 348
   com.ibm.ws.webcontainer.osgi.webapp.WebApp.addClassToHandlesTypesStartupSet line: 1104
   com.ibm.ws.webcontainer.osgi.webapp.WebApp.scanForHandlesTypesClasses line: 1038
   com.ibm.ws.webcontainer.webapp.WebApp.initializeServletContainerInitializers line: 2493
   com.ibm.ws.webcontainer.webapp.WebApp.initialize line: 1037
   com.ibm.ws.webcontainer.webapp.WebApp.initialize line: 6545
   com.ibm.ws.webcontainer.osgi.DynamicVirtualHost.startWebApp line: 466
   com.ibm.ws.webcontainer.osgi.DynamicVirtualHost.createRunnableHandler line: 264
   com.ibm.ws.webcontainer.osgi.DynamicVirtualHost.createRunnableHandler line: 329
   com.ibm.ws.http.internal.VirtualHostImpl.discriminate line: 251
   com.ibm.ws.http.dispatcher.internal.channel.HttpDispatcherLink.ready line: 301
   com.ibm.ws.http.channel.internal.inbound.HttpInboundLink.handleDiscrimination line: 471
   com.ibm.ws.http.channel.internal.inbound.HttpInboundLink.handleNewRequest line: 405
   com.ibm.ws.http.channel.internal.inbound.HttpInboundLink.processRequest line: 285
   com.ibm.ws.http.channel.internal.inbound.HttpICLReadCallback.complete line: 66
   com.ibm.ws.channel.ssl.internal.SSLReadServiceContext$SSLReadCompletedCallback.complete line: 1777
   com.ibm.ws.tcpchannel.internal.WorkQueueManager.requestComplete line: 504
   com.ibm.ws.tcpchannel.internal.WorkQueueManager.attemptIO line: 574
   com.ibm.ws.tcpchannel.internal.WorkQueueManager.workerRun line: 929
   com.ibm.ws.tcpchannel.internal.WorkQueueManager$Worker.run line: 1018
   java.util.concurrent.ThreadPoolExecutor.runWorker line: 1142
   java.util.concurrent.ThreadPoolExecutor$Worker.run line: 617
   java.lang.Thread.run line: 745

第二个帖子：

LargeThreadPool-thread-3 [33] (BLOCKED)
   com.ibm.tx.jta.embeddable.impl.EmbeddableTMHelper.start line: 63
   com.ibm.tx.jta.util.TxTMHelper.start line: 461
   com.ibm.tx.util.TMHelper.start line: 74
   com.ibm.tx.jta.util.TxTMHelper.checkTMState line: 500
   com.ibm.tx.util.TMHelper.checkTMState line: 116
   com.ibm.tx.jta.impl.TranManagerSet.begin line: 167
   com.ibm.ejs.csi.TranStrategy.beginGlobalTx line: 593
   com.ibm.ejs.csi.Required.preInvoke line: 56
   com.ibm.ejs.csi.TransactionControlImpl.preInvoke line: 222
   com.ibm.ejs.container.EJSContainer.preInvokeActivate line: 3176
   com.ibm.ejs.container.EJSContainer.EjbPreInvoke line: 2576
   com.ibm.ejs.container.TimedObjectWrapper.invokeCallback line: 84
   com.ibm.ejs.container.TimerNpRunnable.doWork line: 196
   com.ibm.ejs.container.TimerNpRunnable.run line: 103
   java.util.concurrent.Executors$RunnableAdapter.call line: 511
   java.util.concurrent.FutureTask.run line: 266
   java.util.concurrent.ThreadPoolExecutor.runWorker line: 1142
   java.util.concurrent.ThreadPoolExecutor$Worker.run line: 617
   java.lang.Thread.run line: 745

编辑＃3

正在等待并显然阻塞其他两个线程的线程：

LargeThreadPool-thread-38 [103] (WAITING)
   java.lang.Object.wait line: not available [native method]
   java.lang.Object.wait line: 502
   com.ibm.tx.jta.impl.EventSemaphore.waitEvent line: 71
   com.ibm.tx.jta.impl.RecoveryManager.waitForReplayCompletion line: 1273
   com.ibm.tx.jta.impl.TxRecoveryAgentImpl.initiateRecovery line: 413
   com.ibm.ws.recoverylog.spi.RecoveryDirectorImpl.directInitialization line: 751
   com.ibm.ws.recoverylog.spi.RecoveryDirectorImpl.driveLocalRecovery line: 1240
   com.ibm.ws.recoverylog.spi.RecLogServiceImpl.start line: 125
   com.ibm.tx.jta.embeddable.impl.EmbeddableTMHelper.start line: 130
   com.ibm.tx.jta.util.TxTMHelper.start line: 461
   com.ibm.tx.util.TMHelper.start line: 74
   com.ibm.tx.jta.util.TxTMHelper.checkTMState line: 500
   com.ibm.tx.util.TMHelper.checkTMState line: 116
   com.ibm.tx.jta.impl.TranManagerSet.begin line: 167
   com.ibm.ws.transaction.services.TransactionManagerService.begin line: 281
   com.ibm.ws.concurrent.persistent.internal.PersistentExecutorImpl$PollingTask.run line: 2239

不确定它是否相关，但ffdc显示以下异常：

------Start of DE processing------ = [09-11-2016 14:41:09:006 GMT]
Exception = com.ibm.ws.recoverylog.spi.LogIncompatibleException
Source = com.ibm.ws.recoverylog.spi.LogHandle
probeid = 326
Stack Dump = com.ibm.ws.recoverylog.spi.LogIncompatibleException
    at com.ibm.ws.recoverylog.spi.LogFileHandle.fileOpen(LogFileHandle.java:522)
    at com.ibm.ws.recoverylog.spi.LogHandle.openLog(LogHandle.java:324)
    at com.ibm.ws.recoverylog.spi.MultiScopeRecoveryLog.openLog(MultiScopeRecoveryLog.java:602)at com.ibm.ws.recoverylog.spi.RecoveryLogImpl.openLog(RecoveryLogImpl.java:77)
    at com.ibm.tx.jta.impl.RecoveryManager.run(RecoveryManager.java:1835)
    at java.lang.Thread.run(Thread.java:745)

1 个答案:

答案 0 :(得分：1)

在编辑＃3中，正在等待的线程

com.ibm.tx.jta.impl.RecoveryManager.waitForReplayCompletion

将产生另一个recoveryManager线程，其角色是访问您的文件系统中的事务日志文件。另一个线程应该在向等待线程发出信号之前进行必要的最小量的文件处理，以便它可以继续。你能看到另一个包含

的堆栈的线程吗？

com.ibm.tx.jta.impl.RecoveryManager.run ？

我担心LogIncompatibleException。它表明文件系统上的事务日志文件是 腐败。这不应该导致服务器挂起，我相信你已经遇到了产品缺陷。

如果您需要快速取得进展，在您的方案中删除事务日志文件可能是合适的。 请注意，这是我们仅在交易日志确保时非常谨慎地向客户建议的 分布式事务的完整性。在生产环境中，我们通常建议采取此类行动 仅在IBM Level 3 Service的指导下进行。但在测试/评估方案中，它可以适用。

Liberty事务日志信息存储在/ wlp / usr / servers // tranlog中 目录。如果合适，可以删除tranlog和partnerlog子目录并重新启动服务器。

相关问题
最新问题