Qwertyshoe
|
Posted: October 15, 2009 18:03 by Qwertyshoe
|
|
I've set up the registry and the repository to the point that the test cases appear to be passing correctly. The logging, however, seems to not function at all. The server logs throw an Exception that seems to have something to do with a foreign key constraint being violated. I thought at first that it might have had something to do with the schema capitalization errors that I saw with the omar schema but based on the error messages the capitalization looks correct. Here's the text of the Exception: [#|2009-10-15T09:56:00.789-0800|SEVERE|sun-appserver2.1|com.vangent.hieos.xlog.server.XLoggerBean|_ThreadID=20;_ThreadName=p: thread-pool-1; w: 10;_RequestID=83d5fcd0-2393-4a10-a7cb-4108d40b8ef1;|The log message is null. java.sql.BatchUpdateException: Cannot add or update a child row: a foreign key constraint fails (`log`.`soap`, CONSTRAINT `soap_messageid_fkey` FOREIGN KEY (`messageid`) REFERENCES `main` (`messageid`)) at com.mysql.jdbc.StatementImpl.executeBatch(StatementImpl.java:1054) at com.mysql.jdbc.jdbc2.optional.StatementWrapper.executeBatch(StatementWrapper.java:719) at com.vangent.hieos.xlog.server.XLoggerBean.persist(XLoggerBean.java:105) at com.vangent.hieos.xlog.server.XLoggerBean.onMessage(XLoggerBean.java:72) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at com.sun.enterprise.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1011) at com.sun.enterprise.security.SecurityUtil.invoke(SecurityUtil.java:175) at com.sun.ejb.containers.BaseContainer.invokeTargetBeanMethod(BaseContainer.java:2920) at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:4011) at com.sun.ejb.containers.MessageBeanContainer.deliverMessage(MessageBeanContainer.java:1111) at com.sun.ejb.containers.MessageBeanListenerImpl.deliverMessage(MessageBeanListenerImpl.java:74) at com.sun.enterprise.connectors.inflow.MessageEndpointInvocationHandler.invoke(MessageEndpointInvocationHandler.java:179) at $Proxy36.onMessage(Unknown Source) at com.sun.messaging.jms.ra.OnMessageRunner.run(OnMessageRunner.java:258) at com.sun.enterprise.connectors.work.OneWork.doWork(OneWork.java:76) at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:555) |#] Any suggestions on resolving this issue would be appreciated. Thanks. |
Logging Foreign Key Contraint Error
11 posts
Replies: 10 - Last Post: November 04, 2009 06:08
by: Bernie Thuman
by: Bernie Thuman
showing 1 - 11 of 11
|
Bernie Thuman
|
Posted: October 19, 2009 17:23 by Bernie Thuman
|
|
Can you please try to empty the log, restart the server and try again? The script to empty the log can be found under data\log\common\emptylog.sql It looks like some of the other problems you were having may have left the log in an inconsistent state. |
|
Qwertyshoe
|
Posted: October 20, 2009 18:18 by Qwertyshoe
|
|
Went ahead and did as you suggested. It looks like the exception is being thrown not because of inconsistencies, but because nothing is actually making it into the log in the first place. It's totally empty, both before running the empty script and after emptying it and then running some test cases. There are no errors or exceptions thrown during domain start-up, and the only exceptions being thrown during operation are the ones I previously reported about the foreign key constraint. I do see an ERROR that I missed before, though. It's a ClassNotFoundException on: org.freebxml.omar.server.query.CompressContentQueryFilterPlugin The test cases pass, though, so the missing class doesn't seem to be getting in the way of the basic doc submission and retrieval functionality. |
|
Qwertyshoe
|
Posted: October 27, 2009 16:56 by Qwertyshoe
|
|
I'm wondering if maybe this issue has something to do with a bunch of WARNINGS I'm seeing in the server logs that repeat over and over again. The warnings look like they might have something to do with a JMS connection, which as far as I know is only used for the logging. Here is the block of warnings that repeats: [#|2009-10-27T08:49:11.303-0800|WARNING|sun-appserver2.1|javax.jms.Connection.mqjmsra|_ThreadID=17;_ThreadName=Timer-1213;_RequestID=9c6ac311-3841-4f15-b5c9-d127e439ddb0;|MQJMSRA_DC2001: connectionId=1851582627183119104:_destroy():called on a connection that was not closed.|#] [#|2009-10-27T08:49:11.304-0800|WARNING|sun-appserver2.1|javax.jms.Connection.mqjmsra|_ThreadID=17;_ThreadName=Timer-1213;_RequestID=9c6ac311-3841-4f15-b5c9-d127e439ddb0;|MQJMSRA_DC2001: connectionId=1851582627183119616:_destroy():called on a connection that was not closed.|#] [#|2009-10-27T08:49:11.305-0800|WARNING|sun-appserver2.1|javax.jms.Connection.mqjmsra|_ThreadID=17;_ThreadName=Timer-1213;_RequestID=9c6ac311-3841-4f15-b5c9-d127e439ddb0;|MQJMSRA_DC2001: connectionId=1851582627183120128:_destroy():called on a connection that was not closed.|#] [#|2009-10-27T08:49:11.306-0800|WARNING|sun-appserver2.1|javax.jms.Connection.mqjmsra|_ThreadID=17;_ThreadName=Timer-1213;_RequestID=9c6ac311-3841-4f15-b5c9-d127e439ddb0;|MQJMSRA_DC2001: connectionId=1851582627183120384:_destroy():called on a connection that was not closed.|#] [#|2009-10-27T08:49:11.306-0800|WARNING|sun-appserver2.1|javax.jms.Connection.mqjmsra|_ThreadID=17;_ThreadName=Timer-1213;_RequestID=9c6ac311-3841-4f15-b5c9-d127e439ddb0;|MQJMSRA_DC2001: connectionId=1851582627183120640:_destroy():called on a connection that was not closed.|#] [#|2009-10-27T08:49:11.307-0800|WARNING|sun-appserver2.1|javax.jms.Connection.mqjmsra|_ThreadID=17;_ThreadName=Timer-1213;_RequestID=9c6ac311-3841-4f15-b5c9-d127e439ddb0;|MQJMSRA_DC2001: connectionId=1851582627183120896:_destroy():called on a connection that was not closed.|#] [#|2009-10-27T08:49:11.307-0800|WARNING|sun-appserver2.1|javax.jms.Connection.mqjmsra|_ThreadID=17;_ThreadName=Timer-1213;_RequestID=9c6ac311-3841-4f15-b5c9-d127e439ddb0;|MQJMSRA_DC2001: connectionId=1851582627183121152:_destroy():called on a connection that was not closed.|#] [#|2009-10-27T08:49:11.308-0800|WARNING|sun-appserver2.1|javax.jms.Connection.mqjmsra|_ThreadID=17;_ThreadName=Timer-1213;_RequestID=9c6ac311-3841-4f15-b5c9-d127e439ddb0;|MQJMSRA_DC2001: connectionId=1851582627183121664:_destroy():called on a connection that was not closed.|#] [#|2009-10-27T08:49:11.308-0800|WARNING|sun-appserver2.1|javax.resourceadapter.mqjmsra.outbound.connection|_ThreadID=17;_ThreadName=Timer-1213;_RequestID=9c6ac311-3841-4f15-b5c9-d127e439ddb0;|MQJMSRA_MC2001: createConnection API used w/ username, password for Container Auth|#] [#|2009-10-27T08:49:11.309-0800|WARNING|sun-appserver2.1|javax.resourceadapter.mqjmsra.outbound.connection|_ThreadID=17;_ThreadName=Timer-1213;_RequestID=9c6ac311-3841-4f15-b5c9-d127e439ddb0;|MQJMSRA_MC2001: createConnection API used w/ username, password for Container Auth|#] [#|2009-10-27T08:49:11.311-0800|WARNING|sun-appserver2.1|javax.resourceadapter.mqjmsra.outbound.connection|_ThreadID=17;_ThreadName=Timer-1213;_RequestID=9c6ac311-3841-4f15-b5c9-d127e439ddb0;|MQJMSRA_MC2001: createConnection API used w/ username, password for Container Auth|#] [#|2009-10-27T08:49:11.313-0800|WARNING|sun-appserver2.1|javax.resourceadapter.mqjmsra.outbound.connection|_ThreadID=17;_ThreadName=Timer-1213;_RequestID=9c6ac311-3841-4f15-b5c9-d127e439ddb0;|MQJMSRA_MC2001: createConnection API used w/ username, password for Container Auth|#] [#|2009-10-27T08:49:11.313-0800|WARNING|sun-appserver2.1|javax.resourceadapter.mqjmsra.outbound.connection|_ThreadID=17;_ThreadName=Timer-1213;_RequestID=9c6ac311-3841-4f15-b5c9-d127e439ddb0;|MQJMSRA_MC2001: createConnection API used w/ username, password for Container Auth|#] [#|2009-10-27T08:49:11.314-0800|WARNING|sun-appserver2.1|javax.resourceadapter.mqjmsra.outbound.connection|_ThreadID=17;_ThreadName=Timer-1213;_RequestID=9c6ac311-3841-4f15-b5c9-d127e439ddb0;|MQJMSRA_MC2001: createConnection API used w/ username, password for Container Auth|#] [#|2009-10-27T08:49:11.315-0800|WARNING|sun-appserver2.1|javax.resourceadapter.mqjmsra.outbound.connection|_ThreadID=17;_ThreadName=Timer-1213;_RequestID=9c6ac311-3841-4f15-b5c9-d127e439ddb0;|MQJMSRA_MC2001: createConnection API used w/ username, password for Container Auth|#] [#|2009-10-27T08:49:11.317-0800|WARNING|sun-appserver2.1|javax.resourceadapter.mqjmsra.outbound.connection|_ThreadID=17;_ThreadName=Timer-1213;_RequestID=9c6ac311-3841-4f15-b5c9-d127e439ddb0;|MQJMSRA_MC2001: createConnection API used w/ username, password for Container Auth|#] Does this look like anything that might be blocking the log messages? |
|
Bernie Thuman
|
Posted: October 27, 2009 21:50 by Bernie Thuman
|
|
Try this: Option 1: 1) Login to glassfish admin console: http://localhost:4848 2) Navigate to Configuration -> Java Message Service 3) Change from EMBEDDED to LOCAL 4) Restart glassfish Option 2: 1) Undeploy "xlog" 2) Redeploy "xlog" 3) Restart glassfish Let me know how it goes and we can try to help you further. |
|
Qwertyshoe
|
Posted: October 30, 2009 19:14 by Qwertyshoe
|
|
No dice. The server log messages changed when I changed the JMS configuration to LOCAL, but it didn't get rid of the original exception and the logs are still not being populated. I even went so far as to do a fresh source build and install from the svn tree (before I was using binaries from the CONNECT site). I'm still seeing the same behaviour. At this point I figured it might be a good idea to offer some additional details of my execution environment. I'm running on Fedora 11 x64, using GlassFishESB 2.1 as required by CONNECT release 2.2. I have placed HIEOS into a separate domain from the CONNECT stuff, although the libraries that were copied into the global glassfish lib are still there (excluding the ehcache-1.2.3.jar). The new domain uses non-default ports. I would attach the full text of the server logs to this post, but I don't see an attach function... anyway, thanks for your suggestions. |
|
Qwertyshoe
|
Posted: November 03, 2009 19:09 by Qwertyshoe
|
|
Well, I took another step back and got it running on its own instance of glassfish, sharing nothing with the CONNECT components. I'm still seeing the same behaviour with the same exceptions (test cases pass; empty log tables; foreign key constraint exception). This makes me suspect that there's something seriously wrong with the configuration of my installation, so I'm going to try and dig through the code to get a better understanding of what's going on. Could someone provide a brief outline for how the log framework operates? I just want something to get me started in the right direction. Thanks. |
|
anandsastry
|
Posted: November 03, 2009 19:27 by anandsastry
|
| If you are using HIEOS 1.0, that is a part of CONNECT 2.2, logging does not work. Can you please clarify if this is the case and then we can pursue alternatives. |
|
Qwertyshoe
|
Posted: November 03, 2009 20:51 by Qwertyshoe
|
|
O, really? I know the CONNECT installation doc said that the log config option should be set to false, but I wasn't aware that it did not work at all. In any case, I can confirm that when I started I was using the HIEOS 1.0 binaries available from CONNECT. Apparently the logging never worked there. But then, as a measure to figure out where the problem was, I built and deployed the latest svn trunk, and the logging still acted the same. I believe it was revision 148 or thereabouts (a week or so ago), so it seems the problem persists beyond HIEOS 1.0. I guess my question is at what point is the logging expected to work. I'm not certain yet how important the logging functionality will be, but I know I do not want to be stuck using the HIEOS 1.0 binaries released by CONNECT. After some brief tests, it seems the more recent versions of HIEOS are not compatible with CONNECT 2.2 for other reasons (something to do with coded value formats in the DocumentEntryClassCode during a AdhocQueryRequest for a Consent document), but I'd still be interested to know more about the logging roadmap if possible. In addition, I notice in the xconfig file that there are options for setting and enabling an ATNA compatible logging endpoint. I haven't had a chance to test this, but I know it will be important to us eventually. What's the status of this functionality? Anyway, sorry for badgering you guys for what was apparently a known-issue. I'll just turn the logging off and leave it alone for now. |
|
anandsastry
|
Posted: November 03, 2009 22:03 by anandsastry
|
|
HIEOS writes transaction logs asynchronously using a Message driven bean. This component in HIEOS1.0, part of CONNECT 2.2, is undeployable from the Admin Console. Note that this ONLY affects the mentioned distribution, i.e HIEOS 1.0 binaries bundled in with CONNECT 2.2. Matter of fact you could download the source code of HIEOS 1.0 and deploy the MDB from within Netbeans . It seems like you have already gone down the path of downloading HIEOS source and are using it to integrate with CONNECT 2.2. That tells me that the problem lies elsewhere. I will get back to you on how you can send me your log files and we will take it from there. Thank you for your patience. |
|
Bernie Thuman
|
Posted: November 04, 2009 06:08 by Bernie Thuman
|
|
Just to add some clarification regarding potential issues related to your logging problem and NHIN CONNECT .... 1) Internal HIEOS logging may not work in the version on the CONNECT web site for SOAP 1.1 transactions since CONNECT 2.2 did not fully upgrade to support SOAP 1.2 which is what HIEOS supports. HIEOS 1.0 (minor change made by the CONNECT team) disabled the IHE SOAP 1.2 requirement in HIEOS and therefore likely broke logging. 2) We are asking the CONNECT team to fully support SOAP 1.2 versus SOAP 1.1 which will resolve the issue above. 3) We will work to post an NHIN CONNECT FAQ to aid folks like yourself in the near future 4) Failures in logging should not stop HIEOS XDS.b to function properly |
showing 1 - 11 of 11
Replies: 10 - Last Post: November 04, 2009 06:08
by: Bernie Thuman
by: Bernie Thuman
