[JBoss JIRA] (JBTM-2220) "Could not restore timer from" error when building Blacktie C++ hybrid transport
by Amos Feng (JIRA)
[ https://issues.jboss.org/browse/JBTM-2220?page=com.atlassian.jira.plugin.... ]
Amos Feng commented on JBTM-2220:
---------------------------------
I have changed to use the timer with setting the persistence to false by fixing JBTM-2187. So if this issue does not happen again, I think it should be closed.
> "Could not restore timer from" error when building Blacktie C++ hybrid transport
> --------------------------------------------------------------------------------
>
> Key: JBTM-2220
> URL: https://issues.jboss.org/browse/JBTM-2220
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: BlackTie
> Reporter: Gytis Trikleris
> Assignee: Amos Feng
> Priority: Minor
> Fix For: 5.x.y
>
>
> http://172.17.131.2/view/Status/job/narayana/572/PROFILE=BLACKTIE,jdk=jdk...
> {code}
> [31m13:03:49,383 ERROR [org.jboss.as.ejb3] (RequestProcessor-10) WFLYEJB0029: Could not restore timer from /home/hudson/workspace/narayana/PROFILE/BLACKTIE/jdk/jdk7.latest/label/linux32el6/blacktie/wildfly-9.0.0.Alpha1-SNAPSHOT/standalone/data/timer-service-data/blacktie-admin-services-ear-5.0.3.Final-SNAPSHOT.blacktie-admin-services-5.0.3.Final-SNAPSHOT.QueueReaperBean/df0ab14e-af95-4892-8543-258e2a0c5a3f.xml: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[4,5]
> Message: WFLYCTL0133: Missing required attribute(s): next-date
> at org.jboss.as.controller.parsing.ParseUtils.missingRequired(ParseUtils.java:134)
> at org.jboss.as.ejb3.timerservice.persistence.filestore.EjbTimerXmlParser_1_0.parseTimer(EjbTimerXmlParser_1_0.java:146)
> at org.jboss.as.ejb3.timerservice.persistence.filestore.EjbTimerXmlParser_1_0.readElement(EjbTimerXmlParser_1_0.java:112)
> at org.jboss.as.ejb3.timerservice.persistence.filestore.EjbTimerXmlParser_1_0.readElement(EjbTimerXmlParser_1_0.java:86)
> at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110)
> at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69)
> at org.jboss.as.ejb3.timerservice.persistence.filestore.FileTimerPersistence.loadTimersFromFile(FileTimerPersistence.java:339)
> at org.jboss.as.ejb3.timerservice.persistence.filestore.FileTimerPersistence.getTimers(FileTimerPersistence.java:302)
> at org.jboss.as.ejb3.timerservice.persistence.filestore.FileTimerPersistence.access$200(FileTimerPersistence.java:80)
> at org.jboss.as.ejb3.timerservice.persistence.filestore.FileTimerPersistence$PersistTransactionSynchronization.afterCompletion(FileTimerPersistence.java:425)
> at com.arjuna.ats.internal.jta.resources.jts.orbspecific.SynchronizationImple.after_completion(SynchronizationImple.java:105) [narayana-jts-jacorb-5.0.3.Final-SNAPSHOT.jar:5.0.3.Final-SNAPSHOT (revision: 30cb74)]
> at com.arjuna.ArjunaOTS.JTAInterposedSynchronizationPOATie.after_completion(JTAInterposedSynchronizationPOATie.java:58) [narayana-jts-jacorb-5.0.3.Final-SNAPSHOT.jar:5.0.3.Final-SNAPSHOT (revision: 30cb74)]
> at com.arjuna.ArjunaOTS.JTAInterposedSynchronizationPOA._invoke(JTAInterposedSynchronizationPOA.java:51) [narayana-jts-jacorb-5.0.3.Final-SNAPSHOT.jar:5.0.3.Final-SNAPSHOT (revision: 30cb74)]
> at org.jacorb.poa.RequestProcessor.invokeOperation(RequestProcessor.java:306) [jacorb-2.3.2-jbossorg-5.jar:2.3.2-jbossorg-5]
> at org.jacorb.poa.RequestProcessor.process(RequestProcessor.java:626) [jacorb-2.3.2-jbossorg-5.jar:2.3.2-jbossorg-5]
> at org.jacorb.poa.RequestProcessor.run(RequestProcessor.java:769) [jacorb-2.3.2-jbossorg-5.jar:2.3.2-jbossorg-5]
> [0m[31m13:03:49,397 ERROR [org.jboss.as.ejb3] (EJB default - 10) WFLYEJB0029: Could not restore timer from /home/hudson/workspace/narayana/PROFILE/BLACKTIE/jdk/jdk7.latest/label/linux32el6/blacktie/wildfly-9.0.0.Alpha1-SNAPSHOT/standalone/data/timer-service-data/blacktie-admin-services-ear-5.0.3.Final-SNAPSHOT.blacktie-admin-services-5.0.3.Final-SNAPSHOT.QueueReaperBean/df0ab14e-af95-4892-8543-258e2a0c5a3f.xml: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[4,5]
> Message: WFLYCTL0133: Missing required attribute(s): next-date
> at org.jboss.as.controller.parsing.ParseUtils.missingRequired(ParseUtils.java:134) [wildfly-controller-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.ejb3.timerservice.persistence.filestore.EjbTimerXmlParser_1_0.parseTimer(EjbTimerXmlParser_1_0.java:146) [wildfly-ejb3-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.ejb3.timerservice.persistence.filestore.EjbTimerXmlParser_1_0.readElement(EjbTimerXmlParser_1_0.java:112) [wildfly-ejb3-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.ejb3.timerservice.persistence.filestore.EjbTimerXmlParser_1_0.readElement(EjbTimerXmlParser_1_0.java:86) [wildfly-ejb3-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
> at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.as.ejb3.timerservice.persistence.filestore.FileTimerPersistence.loadTimersFromFile(FileTimerPersistence.java:339) [wildfly-ejb3-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.ejb3.timerservice.persistence.filestore.FileTimerPersistence.getTimers(FileTimerPersistence.java:302) [wildfly-ejb3-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.ejb3.timerservice.persistence.filestore.FileTimerPersistence.persistTimer(FileTimerPersistence.java:193) [wildfly-ejb3-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.ejb3.timerservice.persistence.filestore.FileTimerPersistence.persistTimer(FileTimerPersistence.java:175) [wildfly-ejb3-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.ejb3.timerservice.TimerServiceImpl.persistTimer(TimerServiceImpl.java:604) [wildfly-ejb3-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.ejb3.timerservice.task.TimerTask.run(TimerTask.java:185) [wildfly-ejb3-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_51]
> at java.util.concurrent.FutureTask.run(FutureTask.java:262) [rt.jar:1.7.0_51]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> [0m [exec] --28426:1:mallocfr newSuperblock at 0x6B2E2000 (pszB 98288) unsplittable owner VALGRIND/ttaux
> [exec] --28426:1:execonte resizing htab from size 6151 to 12289 (idx 4) Total#ECs=6152
> [exec] --28426:1:mallocfr newSuperblock at 0x6B2FA000 (pszB 147440) unsplittable owner VALGRIND/ttaux
> [exec] --28426:1:mallocfr reclaimSuperblock at 0x6B2E2000 (pszB 98288) unsplittable owner VALGRIND/ttaux
> [exec] --28426:1:mallocfr newSuperblock at 0x6B2E2000 (pszB 65520) owner VALGRIND/demangle
> [exec] --28426:1:mallocfr deferred_reclaimSuperblock at 0x6B2E2000 (pszB 65520) (prev 0x0) owner VALGRIND/demangle
> [exec] --28426:1:mallocfr deferred_reclaimSuperblock at 0x6B2E2000 (pszB 65520) (prev 0x6B2E2000) owner VALGRIND/demangle
> [exec] --28426:1:mallocfr deferred_reclaimSuperblock at 0x6B2E2000 (pszB 65520) (prev 0x6B2E2000) owner VALGRIND/demangle
> [exec] --28426:1:mallocfr deferred_reclaimSuperblock at 0x6B2E2000 (pszB 65520) (prev 0x6B2E2000) owner VALGRIND/demangle
> [exec] --28426:1:hashtabl resizing table `MC_(malloc_list)' from 769 to 1543 (total elems 770)
> [exec] --28426:1:execonte resizing htab from size 12289 to 24593 (idx 5) Total#ECs=12290
> [exec] --28426:1:mallocfr deferred_reclaimSuperblock NULL (prev 0x6B2E2000) owner VALGRIND/demangle
> [exec] --28426:1:mallocfr reclaimSuperblock at 0x6B2E2000 (pszB 65520) owner VALGRIND/demangle
> [exec] --28426:1:mallocfr newSuperblock at 0x6B431000 (pszB 221168) unsplittable owner VALGRIND/ttaux
> [exec] --28426:1:mallocfr reclaimSuperblock at 0x6B2FA000 (pszB 147440) unsplittable owner VALGRIND/ttaux
> [exec] --28426:1:mallocfr newSuperblock at 0x6B8B5000 (pszB 331760) unsplittable owner VALGRIND/ttaux
> [exec] --28426:1:mallocfr reclaimSuperblock at 0x6B431000 (pszB 221168) unsplittable owner VALGRIND/ttaux
> [exec] .2014-07-03 13:03:52,064 [0x4e77a40] INFO (AtmiBrokerLogc :60 ) - TestXAStompConnection::setUp
> [exec] --28426:1:mallocfr newSuperblock at 0x6BA99000 (pszB 1048560) owner VALGRIND/exectxt
> [exec] --28426:1:execonte resizing htab from size 24593 to 49157 (idx 6) Total#ECs=24594
> [exec] --28426:1:hashtabl resizing table `MC_(malloc_list)' from 1543 to 3079 (total elems 1544)
> [exec] --28426:1:hashtabl resizing table `MC_(malloc_list)' from 3079 to 6151 (total elems 3080)
> [exec] --28426:1:signals extending a stack base 0xbee41000 down by 4096
> [exec] --28426:1:signals extending a stack base 0xbee40000 down by 8192
> [exec] --28426:1:mallocfr newSuperblock at 0x6B906000 (pszB 495600) unsplittable owner VALGRIND/ttaux
> [exec] --28426:1:mallocfr reclaimSuperblock at 0x6B8B5000 (pszB 331760) unsplittable owner VALGRIND/ttaux
> [exec] --28426:1:signals extending a stack base 0xbee3e000 down by 4096
> [exec] --28426:1:mallocfr newSuperblock at 0x6B455000 (pszB 65520) owner VALGRIND/ttaux
> [exec] --28426:1:mallocfr newSuperblock at 0x6C154000 (pszB 1048560) owner VALGRIND/exectxt
> [exec] 2014-07-03 13:03:55,885 [0x4e77a40] INFO (AtmiBrokerLogc :60 ) - TestXAStompConnection::test
> [exec] --28426:1:mallocfr newSuperblock at 0x6C254000 (pszB 741360) unsplittable owner VALGRIND/ttaux
> [exec] --28426:1:mallocfr reclaimSuperblock at 0x6B906000 (pszB 495600) unsplittable owner VALGRIND/ttaux
> [exec] --28426:1:mallocfr newSuperblock at 0x6C309000 (pszB 1048560) owner VALGRIND/exectxt
> [exec] --28426:1:execonte resizing htab from size 49157 to 98317 (idx 7) Total#ECs=49158
> [exec] --28426:1:transtab declare sector 0 full (TT loading 64%, TC loading 76%)
> [exec] --28426:1:transtab allocate sector 1
> [exec] --28426:1:aspacem allocated thread stack at 0x6e8db000 size 1064960
> [exec] --28426:1:syswrap- run_a_thread_NORETURN(tid=2): pre-thread_wrapper
> [exec] --28426:1:syswrap- thread_wrapper(tid=2): entry
> [exec] --28426:1:mallocfr newSuperblock at 0x6B8CD000 (pszB 65520) owner VALGRIND/ttaux
> [exec] --28426:1:mallocfr deferred_reclaimSuperblock at 0x6B8CD000 (pszB 65520) (prev 0x0) owner VALGRIND/ttaux
> [exec] 2014-07-03 13:03:57,339 [0x4e77a40] INFO (AtmiBrokerLogc :60 ) - TestXAStompConnection::test sent message
> [exec] 2014-07-03 13:03:57,622 [0x4e77a40] INFO (AtmiBrokerLogc :60 ) - TestXAStompConnection::test sent message
> [exec] --28426:1:mallocfr deferred_reclaimSuperblock NULL (prev 0x6B8CD000) owner VALGRIND/ttaux
> [exec] --28426:1:mallocfr newSuperblock at 0x6E9DF000 (pszB 1048560) owner VALGRIND/exectxt
> [31m13:03:57,909 ERROR [org.jboss.jca.core.connectionmanager.listener.TxConnectionListener] (RequestProcessor-9) IJ000315: Pool HornetQConnectionDefinition has 1 active handles
> [0m [exec] --28426:1:syswrap- thread_wrapper(tid=2): exit
> [exec] --28426:1:syswrap- run_a_thread_NORETURN(tid=2): post-thread_wrapper
> [exec] --28426:1:syswrap- run_a_thread_NORETURN(tid=2): not last one standing
> [exec] 2014-07-03 13:03:59,657 [0x4e77a40] INFO (AtmiBrokerLogc :60 ) - TestXAStompConnection::test starting to receive (rollback)
> [exec] --28426:1:syswrap- run_a_thread_NORETURN(tid=2): pre-thread_wrapper
> [exec] --28426:1:syswrap- thread_wrapper(tid=2): entry
> [exec] 2014-07-03 13:03:59,795 [0x4e77a40] INFO (AtmiBrokerLogc :60 ) - Iterating
> [exec] --28426:1:mallocfr newSuperblock at 0x5C97000 (pszB 4194288) owner CLIENT/client
> [exec] --28426:1:mallocfr newSuperblock at 0x6EADF000 (pszB 1048560) owner VALGRIND/exectxt
> [exec] 2014-07-03 13:04:00,178 [0x4e77a40] INFO (AtmiBrokerLogc :60 ) - TestXAStompConnection::test received message
> [exec] 2014-07-03 13:04:00,471 [0x4e77a40] INFO (AtmiBrokerLogc :60 ) - TestXAStompConnection::test received message
> [31m13:04:00,568 ERROR [org.jboss.jca.core.connectionmanager.listener.TxConnectionListener] (RequestProcessor-10) IJ000315: Pool HornetQConnectionDefinition has 1 active handles
> [0m [exec] --28426:1:syswrap- thread_wrapper(tid=2): exit
> [exec] --28426:1:syswrap- run_a_thread_NORETURN(tid=2): post-thread_wrapper
> [exec] --28426:1:syswrap- run_a_thread_NORETURN(tid=2): not last one standing
> [exec] 2014-07-03 13:04:02,702 [0x4e77a40] INFO (AtmiBrokerLogc :60 ) - TestXAStompConnection::test starting to receive (commit)
> [exec] --28426:1:syswrap- run_a_thread_NORETURN(tid=2): pre-thread_wrapper
> [exec] --28426:1:syswrap- thread_wrapper(tid=2): entry
> [exec] 2014-07-03 13:04:02,842 [0x4e77a40] INFO (AtmiBrokerLogc :60 ) - Iterating
> [exec] --28426:1:mallocfr newSuperblock at 0x6EBDF000 (pszB 1048560) owner VALGRIND/exectxt
> [exec] 2014-07-03 13:04:03,249 [0x4e77a40] INFO (AtmiBrokerLogc :60 ) - TestXAStompConnection::test received message
> [exec] 2014-07-03 13:04:03,552 [0x4e77a40] INFO (AtmiBrokerLogc :60 ) - TestXAStompConnection::test received message
> [31m13:04:03,808 ERROR [org.jboss.jca.core.connectionmanager.listener.TxConnectionListener] (RequestProcessor-10) IJ000315: Pool HornetQConnectionDefinition has 1 active handles
> [0m [exec] --28426:1:syswrap- thread_wrapper(tid=2): exit
> [exec] --28426:1:syswrap- run_a_thread_NORETURN(tid=2): post-thread_wrapper
> [exec] --28426:1:syswrap- run_a_thread_NORETURN(tid=2): not last one standing
> [exec] 2014-07-03 13:04:05,744 [0x4e77a40] INFO (AtmiBrokerLogc :60 ) - Iterated
> [exec] 2014-07-03 13:04:05,748 [0x4e77a40] INFO (AtmiBrokerLogc :60 ) - TestXAStompConnection::tearDown
> [exec] --28426:1:mallocfr newSuperblock at 0x6BBF9000 (pszB 65520) owner VALGRIND/ttaux
> [exec] --28426:1:mallocfr newSuperblock at 0x6ECDF000 (pszB 1048560) owner VALGRIND/exectxt
> [exec] .2014-07-03 13:04:06,082 [0x4e77a40] INFO (AtmiBrokerLogc :60 ) - TestStompConnection::setUp
> [exec] --28426:1:mallocfr newSuperblock at 0x6097000 (pszB 4194288) owner CLIENT/client
> [exec] --28426:1:mallocfr newSuperblock at 0x6EE3B000 (pszB 1048560) owner VALGRIND/exectxt
> [exec] 2014-07-03 13:04:06,575 [0x4e77a40] INFO (AtmiBrokerLogc :60 ) - TestStompConnection::testLibStomp
> [exec] 2014-07-03 13:04:06,621 [0x4e77a40] INFO (AtmiBrokerLogc :60 ) - Iterating (takes about 16 seconds on toms machine)
> [exec] --28426:1:syswrap- run_a_thread_NORETURN(tid=2): pre-thread_wrapper
> [exec] --28426:1:syswrap- thread_wrapper(tid=2): entry
> [exec] --28426:1:mallocfr newSuperblock at 0x6EF63000 (pszB 98288) unsplittable owner VALGRIND/ttaux
> [exec] --28426:1:mallocfr newSuperblock at 0x6EF7F000 (pszB 1048560) owner VALGRIND/exectxt
> [exec] --28426:1:mallocfr newSuperblock at 0x6F0CB000 (pszB 1048560) owner VALGRIND/exectxt
> [exec] --28426:1:mallocfr newSuperblock at 0x6F1D3000 (pszB 1048560) owner VALGRIND/exectxt
> [exec] --28426:1:execonte resizing htab from size 98317 to 196613 (idx 8) Total#ECs=98318
> [exec] --28426:1:mallocfr newSuperblock at 0x6497000 (pszB 4194288) owner CLIENT/client
> [exec] --28426:1:mallocfr newSuperblock at 0x6897000 (pszB 4194288) owner CLIENT/client
> [exec] --28426:1:mallocfr newSuperblock at 0x6C97000 (pszB 4194288) owner CLIENT/client
> [exec] --28426:1:mallocfr newSuperblock at 0x7097000 (pszB 4194288) owner CLIENT/client
> [exec] --28426:1:mallocfr newSuperblock at 0x6F647000 (pszB 4194288) owner VALGRIND/tool
> [exec] --28426:1:mallocfr newSuperblock at 0x7497000 (pszB 4194288) owner CLIENT/client
> [31m13:04:19,537 ERROR [org.jboss.as.ejb3] (RequestProcessor-10) WFLYEJB0029: Could not restore timer from /home/hudson/workspace/narayana/PROFILE/BLACKTIE/jdk/jdk7.latest/label/linux32el6/blacktie/wildfly-9.0.0.Alpha1-SNAPSHOT/standalone/data/timer-service-data/blacktie-admin-services-ear-5.0.3.Final-SNAPSHOT.blacktie-admin-services-5.0.3.Final-SNAPSHOT.QueueReaperBean/900b5478-18ea-42c6-a90e-a06a69bba56e.xml: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[4,5]
> Message: WFLYCTL0133: Missing required attribute(s): next-date
> at org.jboss.as.controller.parsing.ParseUtils.missingRequired(ParseUtils.java:134)
> at org.jboss.as.ejb3.timerservice.persistence.filestore.EjbTimerXmlParser_1_0.parseTimer(EjbTimerXmlParser_1_0.java:146)
> at org.jboss.as.ejb3.timerservice.persistence.filestore.EjbTimerXmlParser_1_0.readElement(EjbTimerXmlParser_1_0.java:112)
> at org.jboss.as.ejb3.timerservice.persistence.filestore.EjbTimerXmlParser_1_0.readElement(EjbTimerXmlParser_1_0.java:86)
> at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110)
> at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69)
> at org.jboss.as.ejb3.timerservice.persistence.filestore.FileTimerPersistence.loadTimersFromFile(FileTimerPersistence.java:339)
> at org.jboss.as.ejb3.timerservice.persistence.filestore.FileTimerPersistence.getTimers(FileTimerPersistence.java:302)
> at org.jboss.as.ejb3.timerservice.persistence.filestore.FileTimerPersistence.access$200(FileTimerPersistence.java:80)
> at org.jboss.as.ejb3.timerservice.persistence.filestore.FileTimerPersistence$PersistTransactionSynchronization.afterCompletion(FileTimerPersistence.java:425)
> at com.arjuna.ats.internal.jta.resources.jts.orbspecific.SynchronizationImple.after_completion(SynchronizationImple.java:105) [narayana-jts-jacorb-5.0.3.Final-SNAPSHOT.jar:5.0.3.Final-SNAPSHOT (revision: 30cb74)]
> at com.arjuna.ArjunaOTS.JTAInterposedSynchronizationPOATie.after_completion(JTAInterposedSynchronizationPOATie.java:58) [narayana-jts-jacorb-5.0.3.Final-SNAPSHOT.jar:5.0.3.Final-SNAPSHOT (revision: 30cb74)]
> at com.arjuna.ArjunaOTS.JTAInterposedSynchronizationPOA._invoke(JTAInterposedSynchronizationPOA.java:51) [narayana-jts-jacorb-5.0.3.Final-SNAPSHOT.jar:5.0.3.Final-SNAPSHOT (revision: 30cb74)]
> at org.jacorb.poa.RequestProcessor.invokeOperation(RequestProcessor.java:306) [jacorb-2.3.2-jbossorg-5.jar:2.3.2-jbossorg-5]
> at org.jacorb.poa.RequestProcessor.process(RequestProcessor.java:626) [jacorb-2.3.2-jbossorg-5.jar:2.3.2-jbossorg-5]
> at org.jacorb.poa.RequestProcessor.run(RequestProcessor.java:769) [jacorb-2.3.2-jbossorg-5.jar:2.3.2-jbossorg-5]
> [0m[31m13:04:19,562 ERROR [org.jboss.as.ejb3] (EJB default - 1) WFLYEJB0029: Could not restore timer from /home/hudson/workspace/narayana/PROFILE/BLACKTIE/jdk/jdk7.latest/label/linux32el6/blacktie/wildfly-9.0.0.Alpha1-SNAPSHOT/standalone/data/timer-service-data/blacktie-admin-services-ear-5.0.3.Final-SNAPSHOT.blacktie-admin-services-5.0.3.Final-SNAPSHOT.QueueReaperBean/900b5478-18ea-42c6-a90e-a06a69bba56e.xml: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[4,5]
> Message: WFLYCTL0133: Missing required attribute(s): next-date
> at org.jboss.as.controller.parsing.ParseUtils.missingRequired(ParseUtils.java:134) [wildfly-controller-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.ejb3.timerservice.persistence.filestore.EjbTimerXmlParser_1_0.parseTimer(EjbTimerXmlParser_1_0.java:146) [wildfly-ejb3-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.ejb3.timerservice.persistence.filestore.EjbTimerXmlParser_1_0.readElement(EjbTimerXmlParser_1_0.java:112) [wildfly-ejb3-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.ejb3.timerservice.persistence.filestore.EjbTimerXmlParser_1_0.readElement(EjbTimerXmlParser_1_0.java:86) [wildfly-ejb3-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
> at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.as.ejb3.timerservice.persistence.filestore.FileTimerPersistence.loadTimersFromFile(FileTimerPersistence.java:339) [wildfly-ejb3-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.ejb3.timerservice.persistence.filestore.FileTimerPersistence.getTimers(FileTimerPersistence.java:302) [wildfly-ejb3-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.ejb3.timerservice.persistence.filestore.FileTimerPersistence.persistTimer(FileTimerPersistence.java:193) [wildfly-ejb3-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.ejb3.timerservice.persistence.filestore.FileTimerPersistence.persistTimer(FileTimerPersistence.java:175) [wildfly-ejb3-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.ejb3.timerservice.TimerServiceImpl.persistTimer(TimerServiceImpl.java:604) [wildfly-ejb3-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.ejb3.timerservice.task.TimerTask.run(TimerTask.java:185) [wildfly-ejb3-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_51]
> at java.util.concurrent.FutureTask.run(FutureTask.java:262) [rt.jar:1.7.0_51]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> [0m [exec] --28426:1:mallocfr newSuperblock at 0x7897000 (pszB 4194288) owner CLIENT/client
> [exec] --28426:1:mallocfr newSuperblock at 0x885F000 (pszB 4194288) owner CLIENT/client
> [exec] --28426:1:mallocfr newSuperblock at 0x8C5F000 (pszB 4194288) owner CLIENT/client
> [exec] --28426:1:mallocfr newSuperblock at 0x905F000 (pszB 4194288) owner CLIENT/client
> [exec] --28426:1:mallocfr newSuperblock at 0x6FF47000 (pszB 4194288) owner VALGRIND/tool
> [exec] 2014-07-03 13:04:46,791 [0x4e77a40] INFO (AtmiBrokerLogc :60 ) - Iterated
> [exec] 2014-07-03 13:04:46,991 [0x4e77a40] INFO (AtmiBrokerLogc :60 ) - TestStompConnection::tearDown
> [exec] --28426:1:syswrap- thread_wrapper(tid=2): exit
> [exec] --28426:1:syswrap- run_a_thread_NORETURN(tid=2): post-thread_wrapper
> [exec] --28426:1:syswrap- run_a_thread_NORETURN(tid=2): not last one standing
> [exec] .2014-07-03 13:04:48,840 [0x4e77a40] INFO (AtmiBrokerLogc :60 ) - TestStompConnection::setUp
> [exec] 2014-07-03 13:04:49,556 [0x4e77a40] INFO (AtmiBrokerLogc :60 ) - TestStompConnection::test
> [31m13:04:49,685 ERROR [org.jboss.as.ejb3] (RequestProcessor-10) WFLYEJB0029: Could not restore timer from /home/hudson/workspace/narayana/PROFILE/BLACKTIE/jdk/jdk7.latest/label/linux32el6/blacktie/wildfly-9.0.0.Alpha1-SNAPSHOT/standalone/data/timer-service-data/blacktie-admin-services-ear-5.0.3.Final-SNAPSHOT.blacktie-admin-services-5.0.3.Final-SNAPSHOT.QueueReaperBean/b539dc9a-3020-4da8-95f3-579978a08c01.xml: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[4,5]
> Message: WFLYCTL0133: Missing required attribute(s): next-date
> at org.jboss.as.controller.parsing.ParseUtils.missingRequired(ParseUtils.java:134)
> at org.jboss.as.ejb3.timerservice.persistence.filestore.EjbTimerXmlParser_1_0.parseTimer(EjbTimerXmlParser_1_0.java:146)
> at org.jboss.as.ejb3.timerservice.persistence.filestore.EjbTimerXmlParser_1_0.readElement(EjbTimerXmlParser_1_0.java:112)
> at org.jboss.as.ejb3.timerservice.persistence.filestore.EjbTimerXmlParser_1_0.readElement(EjbTimerXmlParser_1_0.java:86)
> at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110)
> at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69)
> at org.jboss.as.ejb3.timerservice.persistence.filestore.FileTimerPersistence.loadTimersFromFile(FileTimerPersistence.java:339)
> at org.jboss.as.ejb3.timerservice.persistence.filestore.FileTimerPersistence.getTimers(FileTimerPersistence.java:302)
> at org.jboss.as.ejb3.timerservice.persistence.filestore.FileTimerPersistence.access$200(FileTimerPersistence.java:80)
> at org.jboss.as.ejb3.timerservice.persistence.filestore.FileTimerPersistence$PersistTransactionSynchronization.afterCompletion(FileTimerPersistence.java:425)
> at com.arjuna.ats.internal.jta.resources.jts.orbspecific.SynchronizationImple.after_completion(SynchronizationImple.java:105) [narayana-jts-jacorb-5.0.3.Final-SNAPSHOT.jar:5.0.3.Final-SNAPSHOT (revision: 30cb74)]
> at com.arjuna.ArjunaOTS.JTAInterposedSynchronizationPOATie.after_completion(JTAInterposedSynchronizationPOATie.java:58) [narayana-jts-jacorb-5.0.3.Final-SNAPSHOT.jar:5.0.3.Final-SNAPSHOT (revision: 30cb74)]
> at com.arjuna.ArjunaOTS.JTAInterposedSynchronizationPOA._invoke(JTAInterposedSynchronizationPOA.java:51) [narayana-jts-jacorb-5.0.3.Final-SNAPSHOT.jar:5.0.3.Final-SNAPSHOT (revision: 30cb74)]
> at org.jacorb.poa.RequestProcessor.invokeOperation(RequestProcessor.java:306) [jacorb-2.3.2-jbossorg-5.jar:2.3.2-jbossorg-5]
> at org.jacorb.poa.RequestProcessor.process(RequestProcessor.java:626) [jacorb-2.3.2-jbossorg-5.jar:2.3.2-jbossorg-5]
> at org.jacorb.poa.RequestProcessor.run(RequestProcessor.java:769) [jacorb-2.3.2-jbossorg-5.jar:2.3.2-jbossorg-5]
> [0m[31m13:04:49,706 ERROR [org.jboss.as.ejb3] (EJB default - 2) WFLYEJB0029: Could not restore timer from /home/hudson/workspace/narayana/PROFILE/BLACKTIE/jdk/jdk7.latest/label/linux32el6/blacktie/wildfly-9.0.0.Alpha1-SNAPSHOT/standalone/data/timer-service-data/blacktie-admin-services-ear-5.0.3.Final-SNAPSHOT.blacktie-admin-services-5.0.3.Final-SNAPSHOT.QueueReaperBean/b539dc9a-3020-4da8-95f3-579978a08c01.xml: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[4,5]
> Message: WFLYCTL0133: Missing required attribute(s): next-date
> at org.jboss.as.controller.parsing.ParseUtils.missingRequired(ParseUtils.java:134) [wildfly-controller-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.ejb3.timerservice.persistence.filestore.EjbTimerXmlParser_1_0.parseTimer(EjbTimerXmlParser_1_0.java:146) [wildfly-ejb3-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.ejb3.timerservice.persistence.filestore.EjbTimerXmlParser_1_0.readElement(EjbTimerXmlParser_1_0.java:112) [wildfly-ejb3-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.ejb3.timerservice.persistence.filestore.EjbTimerXmlParser_1_0.readElement(EjbTimerXmlParser_1_0.java:86) [wildfly-ejb3-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
> at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.as.ejb3.timerservice.persistence.filestore.FileTimerPersistence.loadTimersFromFile(FileTimerPersistence.java:339) [wildfly-ejb3-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.ejb3.timerservice.persistence.filestore.FileTimerPersistence.getTimers(FileTimerPersistence.java:302) [wildfly-ejb3-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.ejb3.timerservice.persistence.filestore.FileTimerPersistence.persistTimer(FileTimerPersistence.java:193) [wildfly-ejb3-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.ejb3.timerservice.persistence.filestore.FileTimerPersistence.persistTimer(FileTimerPersistence.java:175) [wildfly-ejb3-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.ejb3.timerservice.TimerServiceImpl.persistTimer(TimerServiceImpl.java:604) [wildfly-ejb3-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.ejb3.timerservice.task.TimerTask.run(TimerTask.java:185) [wildfly-ejb3-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_51]
> at java.util.concurrent.FutureTask.run(FutureTask.java:262) [rt.jar:1.7.0_51]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> [0m [exec] --28426:1:syswrap- run_a_thread_NORETURN(tid=2): pre-thread_wrapper
> [exec] --28426:1:syswrap- thread_wrapper(tid=2): entry
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 5 months
[JBoss JIRA] (JBTM-2288) Deploy/Undeploy BlacktieAdminService MBean throws javax.naming.NameNotFoundException: java:comp/BeanManager
by Amos Feng (JIRA)
[ https://issues.jboss.org/browse/JBTM-2288?page=com.atlassian.jira.plugin.... ]
Amos Feng resolved JBTM-2288.
-----------------------------
Resolution: Done
This issue does not happen with the lastest wildfly build
> Deploy/Undeploy BlacktieAdminService MBean throws javax.naming.NameNotFoundException: java:comp/BeanManager
> -----------------------------------------------------------------------------------------------------------
>
> Key: JBTM-2288
> URL: https://issues.jboss.org/browse/JBTM-2288
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: Application Server Integration, BlackTie
> Reporter: Amos Feng
> Assignee: Amos Feng
> Priority: Minor
> Fix For: 5.0.4
>
>
> When deploy the balcktie admin ear, the wildfly throws NameNotFound Exception when deploying the BlacktiAdminService MBean
> {code}
> 11:39:30,059 INFO [org.jboss.narayana.blacktie.administration.BlacktieAdminService] (MSC service thread 1-8) Admin Server Started
> 11:39:30,060 ERROR [org.jboss.as.weld] (MSC service thread 1-8) WFLYWELD0002: Failed to tear down Weld contexts: javax.naming.NameNotFoundException: java:comp/BeanManager
> at org.jboss.as.naming.InitialContext$DefaultInitialContext.findContext(InitialContext.java:187) [wildfly-naming-9.0.0.Alpha2-SNAPSHOT.jar:9.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.naming.InitialContext$DefaultInitialContext.lookup(InitialContext.java:231) [wildfly-naming-9.0.0.Alpha2-SNAPSHOT.jar:9.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:188) [wildfly-naming-9.0.0.Alpha2-SNAPSHOT.jar:9.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:184) [wildfly-naming-9.0.0.Alpha2-SNAPSHOT.jar:9.0.0.Alpha2-SNAPSHOT]
> at javax.naming.InitialContext.lookup(InitialContext.java:411) [rt.jar:1.7.0_21]
> at javax.naming.InitialContext.lookup(InitialContext.java:411) [rt.jar:1.7.0_21]
> at org.jboss.as.weld.arquillian.WeldContextSetup.teardown(WeldContextSetup.java:108)
> at org.jboss.as.service.AbstractService.invokeLifecycleMethod(AbstractService.java:77) [wildfly-sar-9.0.0.Alpha2-SNAPSHOT.jar:9.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.service.StartStopService.start(StartStopService.java:57) [wildfly-sar-9.0.0.Alpha2-SNAPSHOT.jar:9.0.0.Alpha2-SNAPSHOT]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> 11:39:30,064 ERROR [org.jboss.as.weld] (MSC service thread 1-8) WFLYWELD0002: Failed to tear down Weld contexts: javax.naming.NameNotFoundException: java:comp/BeanManager
> at org.jboss.as.naming.InitialContext$DefaultInitialContext.findContext(InitialContext.java:187)
> at org.jboss.as.naming.InitialContext$DefaultInitialContext.lookup(InitialContext.java:231)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:188)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:184)
> at javax.naming.InitialContext.lookup(InitialContext.java:411) [rt.jar:1.7.0_21]
> at javax.naming.InitialContext.lookup(InitialContext.java:411) [rt.jar:1.7.0_21]
> at org.jboss.as.weld.arquillian.WeldContextSetup.teardown(WeldContextSetup.java:108)
> at org.jboss.as.jmx.MBeanRegistrationService.start(MBeanRegistrationService.java:106) [wildfly-jmx-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 5 months
[JBoss JIRA] (JBTM-2315) A checked CORBA narrow call in ExtendedResourceRecord failed on JDK orb
by Michael Musgrove (JIRA)
[ https://issues.jboss.org/browse/JBTM-2315?page=com.atlassian.jira.plugin.... ]
Michael Musgrove updated JBTM-2315:
-----------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> A checked CORBA narrow call in ExtendedResourceRecord failed on JDK orb
> -----------------------------------------------------------------------
>
> Key: JBTM-2315
> URL: https://issues.jboss.org/browse/JBTM-2315
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: JTS
> Affects Versions: 5.0.3
> Reporter: Michael Musgrove
> Assignee: Michael Musgrove
> Fix For: 5.0.4
>
> Attachments: stacktrace.txt
>
>
> Wildfly recovery testing on the JDK orb blows (see the attached stack trace for details) up in ExtendedResourceRecord when we narrow a resource (using OTSAbstractRecordHelper.narrow (theResource). The reason we don't think it happens with JacORB is that they have an optimization that avoids the remote call for is_a whereas JDK orb does not have the optimisation. I built a version of narayana that replaces the narrow call with an unchecked_narrow and this fixes the recovery issue.
> A little bit of implementation detail: JacORB loads the stub for the object being narrowed and calls its _ids method. If any of those ids match the target type then it avoids the remote call. Our guess is that this local search succeeds (but it's a guess).
> On the other hand, looking at the code for the JBoss repackaging of the OpenJDK ORB (org.jboss.openjdk-orb): it first checks locally (StubAdapter.getTypeIds) and then falls back to doing the RPC call (getClientRequestDispatcher). The stack trace (see attachment) shows that it goes through the latter path.
> After consultation with Mark, our OTS expert, he is of the opinion that the CORBA spec isn't prescriptive about how narrow and is_a are supposed to work. So as long as the right answer is returned, why should we be concerned?
> As a parallel task we should investigate why the local check for the OpenJDK ORB doesn't work. Maybe it's an issue for them to fix?
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 5 months
[JBoss JIRA] (JBTM-2315) A checked CORBA narrow call in ExtendedResourceRecord failed on JDK orb
by Michael Musgrove (JIRA)
[ https://issues.jboss.org/browse/JBTM-2315?page=com.atlassian.jira.plugin.... ]
Michael Musgrove updated JBTM-2315:
-----------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/jbosstm/narayana/pull/790
> A checked CORBA narrow call in ExtendedResourceRecord failed on JDK orb
> -----------------------------------------------------------------------
>
> Key: JBTM-2315
> URL: https://issues.jboss.org/browse/JBTM-2315
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: JTS
> Affects Versions: 5.0.3
> Reporter: Michael Musgrove
> Assignee: Michael Musgrove
> Fix For: 5.0.4
>
> Attachments: stacktrace.txt
>
>
> Wildfly recovery testing on the JDK orb blows (see the attached stack trace for details) up in ExtendedResourceRecord when we narrow a resource (using OTSAbstractRecordHelper.narrow (theResource). The reason we don't think it happens with JacORB is that they have an optimization that avoids the remote call for is_a whereas JDK orb does not have the optimisation. I built a version of narayana that replaces the narrow call with an unchecked_narrow and this fixes the recovery issue.
> A little bit of implementation detail: JacORB loads the stub for the object being narrowed and calls its _ids method. If any of those ids match the target type then it avoids the remote call. Our guess is that this local search succeeds (but it's a guess).
> On the other hand, looking at the code for the JBoss repackaging of the OpenJDK ORB (org.jboss.openjdk-orb): it first checks locally (StubAdapter.getTypeIds) and then falls back to doing the RPC call (getClientRequestDispatcher). The stack trace (see attachment) shows that it goes through the latter path.
> After consultation with Mark, our OTS expert, he is of the opinion that the CORBA spec isn't prescriptive about how narrow and is_a are supposed to work. So as long as the right answer is returned, why should we be concerned?
> As a parallel task we should investigate why the local check for the OpenJDK ORB doesn't work. Maybe it's an issue for them to fix?
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 5 months
[JBoss JIRA] (JBTM-2315) A checked CORBA narrow call in ExtendedResourceRecord failed on JDK orb
by Michael Musgrove (JIRA)
[ https://issues.jboss.org/browse/JBTM-2315?page=com.atlassian.jira.plugin.... ]
Michael Musgrove updated JBTM-2315:
-----------------------------------
Attachment: stacktrace.txt
stack trace
> A checked CORBA narrow call in ExtendedResourceRecord failed on JDK orb
> -----------------------------------------------------------------------
>
> Key: JBTM-2315
> URL: https://issues.jboss.org/browse/JBTM-2315
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: JTS
> Affects Versions: 5.0.3
> Reporter: Michael Musgrove
> Assignee: Michael Musgrove
> Fix For: 5.0.4
>
> Attachments: stacktrace.txt
>
>
> Wildfly recovery testing on the JDK orb blows (see the attached stack trace for details) up in ExtendedResourceRecord when we narrow a resource (using OTSAbstractRecordHelper.narrow (theResource). The reason we don't think it happens with JacORB is that they have an optimization that avoids the remote call for is_a whereas JDK orb does not have the optimisation. I built a version of narayana that replaces the narrow call with an unchecked_narrow and this fixes the recovery issue.
> A little bit of implementation detail: JacORB loads the stub for the object being narrowed and calls its _ids method. If any of those ids match the target type then it avoids the remote call. Our guess is that this local search succeeds (but it's a guess).
> On the other hand, looking at the code for the JBoss repackaging of the OpenJDK ORB (org.jboss.openjdk-orb): it first checks locally (StubAdapter.getTypeIds) and then falls back to doing the RPC call (getClientRequestDispatcher). The stack trace (see attachment) shows that it goes through the latter path.
> After consultation with Mark, our OTS expert, he is of the opinion that the CORBA spec isn't prescriptive about how narrow and is_a are supposed to work. So as long as the right answer is returned, why should we be concerned?
> As a parallel task we should investigate why the local check for the OpenJDK ORB doesn't work. Maybe it's an issue for them to fix?
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 5 months
[JBoss JIRA] (JBTM-2315) A checked CORBA narrow call in ExtendedResourceRecord failed on JDK orb
by Michael Musgrove (JIRA)
[ https://issues.jboss.org/browse/JBTM-2315?page=com.atlassian.jira.plugin.... ]
Michael Musgrove updated JBTM-2315:
-----------------------------------
Comment: was deleted
(was: stack trace)
> A checked CORBA narrow call in ExtendedResourceRecord failed on JDK orb
> -----------------------------------------------------------------------
>
> Key: JBTM-2315
> URL: https://issues.jboss.org/browse/JBTM-2315
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: JTS
> Affects Versions: 5.0.3
> Reporter: Michael Musgrove
> Assignee: Michael Musgrove
> Fix For: 5.0.4
>
> Attachments: stacktrace.txt
>
>
> Wildfly recovery testing on the JDK orb blows (see the attached stack trace for details) up in ExtendedResourceRecord when we narrow a resource (using OTSAbstractRecordHelper.narrow (theResource). The reason we don't think it happens with JacORB is that they have an optimization that avoids the remote call for is_a whereas JDK orb does not have the optimisation. I built a version of narayana that replaces the narrow call with an unchecked_narrow and this fixes the recovery issue.
> A little bit of implementation detail: JacORB loads the stub for the object being narrowed and calls its _ids method. If any of those ids match the target type then it avoids the remote call. Our guess is that this local search succeeds (but it's a guess).
> On the other hand, looking at the code for the JBoss repackaging of the OpenJDK ORB (org.jboss.openjdk-orb): it first checks locally (StubAdapter.getTypeIds) and then falls back to doing the RPC call (getClientRequestDispatcher). The stack trace (see attachment) shows that it goes through the latter path.
> After consultation with Mark, our OTS expert, he is of the opinion that the CORBA spec isn't prescriptive about how narrow and is_a are supposed to work. So as long as the right answer is returned, why should we be concerned?
> As a parallel task we should investigate why the local check for the OpenJDK ORB doesn't work. Maybe it's an issue for them to fix?
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 5 months
[JBoss JIRA] (JBTM-2315) A checked CORBA narrow call in ExtendedResourceRecord failed on JDK orb
by Michael Musgrove (JIRA)
Michael Musgrove created JBTM-2315:
--------------------------------------
Summary: A checked CORBA narrow call in ExtendedResourceRecord failed on JDK orb
Key: JBTM-2315
URL: https://issues.jboss.org/browse/JBTM-2315
Project: JBoss Transaction Manager
Issue Type: Bug
Components: JTS
Affects Versions: 5.0.3
Reporter: Michael Musgrove
Assignee: Michael Musgrove
Fix For: 5.0.4
Wildfly recovery testing on the JDK orb blows (see the attached stack trace for details) up in ExtendedResourceRecord when we narrow a resource (using OTSAbstractRecordHelper.narrow (theResource). The reason we don't think it happens with JacORB is that they have an optimization that avoids the remote call for is_a whereas JDK orb does not have the optimisation. I built a version of narayana that replaces the narrow call with an unchecked_narrow and this fixes the recovery issue.
A little bit of implementation detail: JacORB loads the stub for the object being narrowed and calls its _ids method. If any of those ids match the target type then it avoids the remote call. Our guess is that this local search succeeds (but it's a guess).
On the other hand, looking at the code for the JBoss repackaging of the OpenJDK ORB (org.jboss.openjdk-orb): it first checks locally (StubAdapter.getTypeIds) and then falls back to doing the RPC call (getClientRequestDispatcher). The stack trace (see attachment) shows that it goes through the latter path.
After consultation with Mark, our OTS expert, he is of the opinion that the CORBA spec isn't prescriptive about how narrow and is_a are supposed to work. So as long as the right answer is returned, why should we be concerned?
As a parallel task we should investigate why the local check for the OpenJDK ORB doesn't work. Maybe it's an issue for them to fix?
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 5 months
[JBoss JIRA] (JBTM-1175) Add warning message during recovery if heuristic occurs
by Mark Little (JIRA)
[ https://issues.jboss.org/browse/JBTM-1175?page=com.atlassian.jira.plugin.... ]
Mark Little closed JBTM-1175.
-----------------------------
> Add warning message during recovery if heuristic occurs
> -------------------------------------------------------
>
> Key: JBTM-1175
> URL: https://issues.jboss.org/browse/JBTM-1175
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Components: JTA, JTS, Recovery, Transaction Core
> Affects Versions: 4.16.4
> Reporter: Mark Little
> Assignee: Mark Little
>
> Heuristics during recovery used to be treated via the OTS hooking in various notification mechanisms, e.g., the CORBA notification service. That code is gone and as a result we silently ignore heuristics during recovery. This is not an issue for consistency, because the heuristic resolution tool(s) were always intended to scan the object store and flag all logs that are in a heuristic state. However, it might be nice for admins to have a pro-active indication that a failure has occurred. Need to check all recovery instances for those that are now silent.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 5 months
[JBoss JIRA] (JBTM-1175) Add warning message during recovery if heuristic occurs
by Mark Little (JIRA)
[ https://issues.jboss.org/browse/JBTM-1175?page=com.atlassian.jira.plugin.... ]
Mark Little resolved JBTM-1175.
-------------------------------
Resolution: Done
> Add warning message during recovery if heuristic occurs
> -------------------------------------------------------
>
> Key: JBTM-1175
> URL: https://issues.jboss.org/browse/JBTM-1175
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Components: JTA, JTS, Recovery, Transaction Core
> Affects Versions: 4.16.4
> Reporter: Mark Little
> Assignee: Mark Little
>
> Heuristics during recovery used to be treated via the OTS hooking in various notification mechanisms, e.g., the CORBA notification service. That code is gone and as a result we silently ignore heuristics during recovery. This is not an issue for consistency, because the heuristic resolution tool(s) were always intended to scan the object store and flag all logs that are in a heuristic state. However, it might be nice for admins to have a pro-active indication that a failure has occurred. Need to check all recovery instances for those that are now silent.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 5 months